Voice dictation on Linux leaks rec recorder processes until audio degrades and transcription returns empty.

Environment

• Claude Code v2.1.221 (native CLI, interactive session)
• Linux devcontainer (Debian-based) on WSL2 / Windows 11
• Audio: WSLg PulseAudio forwarded into the container (PULSE_SERVER=unix:/run/host/wslg/PulseServer)
• Recorder backend: sox rec fallback (arecord not installed)
• Voice dictation enabled, both hold and tap modes affected

Summary

Voice dictations frequently leave their rec recorder process running after they end — primarily when a capture fails or retries (a clean successful dictation was observed to terminate its recorder). Failed/retried captures spawn several recorders per dictation without killing the previous one.
Leaked recorders accumulate, keep PulseAudio client connections open and stop draining their streams, which degrades the shared audio stack until transcriptions come back empty and eventually the PulseAudio daemon dies.

Observed behavior

After a few dictations across 3 concurrent sessions, 10 leaked recorders were alive (minutes after the dictations ended):

  PID  PPID STAT     ELAPSED COMMAND
41103 33161 Sl+        13:15 rec -q --buffer 1024 -t raw -r 16000 -e signed -b 16 -c 1 -
41256 33161 Sl+        13:13 rec -q --buffer 1024 -t raw -r 16000 -e signed -b 16 -c 1 -
41298 33161 Sl+        13:12 rec -q --buffer 1024 -t raw -r 16000 -e signed -b 16 -c 1 -
41358 33161 Sl+        13:10 rec -q --buffer 1024 -t raw -r 16000 -e signed -b 16 -c 1 -
42368 33161 Sl+        13:03 rec -q --buffer 1024 -t raw -r 16000 -e signed -b 16 -c 1 -
43233 33161 Sl+        12:52 rec -q --buffer 1024 -t raw -r 16000 -e signed -b 16 -c 1 -
43461 33161 Sl+        12:48 rec -q --buffer 1024 -t raw -r 16000 -e signed -b 16 -c 1 -
45910  3200 Sl+        12:19 rec -q --buffer 1024 -t raw -r 16000 -e signed -b 16 -c 1 -
69666 48453 Sl+        05:36 rec -q --buffer 1024 -t raw -r 16000 -e signed -b 16 -c 1 -
69851 48453 Sl+        05:27 rec -q --buffer 1024 -t raw -r 16000 -e signed -b 16 -c 1 -

One heavily loaded (restored, large-context) session spawned 7 recorders within 28 seconds during a single dictation attempt — the retry loop respawns rec without killing the previous one. v2.1.217 changelog says unbounded retry was fixed; the process leak part was not.

All 10 held established connections to the PulseAudio socket (ss -xp + /proc/*/fd inode mapping confirmed every connection belonged to a rec process). While leaked recorders were alive, the WSLg PulseAudio log filled with:

W: [rdp-source] asyncq.c: q overrun, queuing locally   (x11)

Impact (progression)

1. Dictation transcribes only the first words, then produces empty results ("empty words") — parallel independent capture of the same PulseAudio source shows clean continuous speech, so the audio reaching the system is fine and gets lost in the voice pipeline.
2. With more accumulation, the WSLg rdp-source stream dies: recordings return pure digital silence (max amplitude exactly 0.000000).
3. Eventually the WSLg PulseAudio daemon dies entirely (Connection refused on the socket) and voice mode reports no microphone. Only wsl --shutdown recovers from this stage.

Steps to reproduce

1. Linux/WSL2 environment with PulseAudio and sox rec as the recorder backend.
2. Enable voice dictation, dictate a few phrases (hold or tap mode).
3. ps -C rec — recorders from finished dictations are still running.
4. Keep dictating across long-lived sessions; watch PulseAudio log for q overrun and transcriptions degrade to empty.

Expected behavior

The recorder process is terminated when a dictation ends (and before a retry spawns a new one). At most one live recorder per session.

Workaround

pkill -x rec (while no dictation is active) immediately restores clean audio without restarting WSL, unless the PulseAudio daemon has already died.