1. Why a Linux program in WSL can't simply open your microphone
The microphone belongs to Windows. WSLg's README describes how Linux reaches it: a containerized system distribution runs the WSLg X server, a Wayland server, and a PulseAudio server, and WSLGd connects them to Windows by launching mstsc.exe, the Remote Desktop client, in silent mode. For microphone input, a PulseAudio source plugin moves audio samples between the Windows host and Linux over that RDP connection. WSLg preconfigures DISPLAY, WAYLAND_DISPLAY, and PULSE_SERVER in your distribution so that programs find these servers.
Programs that speak PulseAudio can therefore record. Programs that open a sound card directly through ALSA can't: Claude Code's troubleshooting notes that there is no /dev/snd device in WSL, so the ALSA backend has nothing to open. Speech tools that work on a Linux laptop can fail inside WSL for exactly this reason.
2. Confirm WSL 2 and WSLg before debugging audio
Microsoft says Linux GUI apps, and with them WSLg, work only with WSL 2 and “will not work with a Linux distribution configured for WSL 1.” They require Windows 10 Build 19044 or later, or Windows 11. WSLg's README recommends the Microsoft Store version of WSL, which carries the newest WSL and WSLg on both Windows 10 and 11.
Microsoft's basic-commands page lists the checks. wsl --list --verbose shows each distribution and whether it runs WSL 1 or WSL 2. wsl --set-version followed by the distribution name and 2 converts it. wsl --version reports the WSL components. After wsl --update, which Microsoft says to run from an elevated prompt, wsl --shutdown restarts WSL so the update takes effect.
- In PowerShell, run wsl --list --verbose and check the VERSION column.
- Convert a WSL 1 distribution with wsl --set-version <name> 2.
- Run wsl --update, then wsl --shutdown, and reopen the shell.
- Inside Linux, echo $PULSE_SERVER should print the socket that WSLg set.
3. Claude Code /voice inside WSL2: the exact fixes
Anthropic lists WSLg as a requirement when Claude Code runs in WSL, included with WSL2 from the Microsoft Store on Windows 10 or 11. If WSLg isn't available, for example on WSL1, the docs say to run Claude Code in native Windows instead. Native voice also needs a Claude.ai account, and it streams audio to Anthropic's servers for transcription.
The WSL-specific error is “Voice mode could not find a working audio recorder in WSL.” Anthropic's fix is sudo apt install sox libsox-fmt-pulse. Installing sox alone pulls in only the ALSA backend, which can't record in WSL because there is no /dev/snd. If recording starts but captures silence, the docs point to the Windows input device under Settings → System → Sound → Input.
4. Dictate from the Windows side instead
Windows Terminal is a Windows program, even when the tab runs Ubuntu. Anything that types or pastes into that window works the same in a WSL tab as in PowerShell: Windows key + H voice typing, voice access, or a dictation app. Linux receives characters, so neither WSLg, PulseAudio, nor SoX is involved, and the same method works in WSL 1.
Paste-based tools need one thing from you: keep Windows Terminal's paste binding. Windows Terminal issue #322 has tracked WSL paste problems since 2018, and a July 2026 comment there describes a dictation tool whose simulated Ctrl+V vanished. The user had unbound Ctrl+V in Terminal, so the key reached bash, where readline's vi mode treats Ctrl+V as quoted-insert. The tool reported success, and nothing appeared. Leave Ctrl+V (or Ctrl+Shift+V) bound to paste, or use a tool that types characters.
5. Where your project lives changes what Windows tools can see
Microsoft's file-system guidance recommends keeping project files in the Linux file system, for example /home/<user name>/Project, when you work from a Linux command line, because that's fastest. Files under /mnt/c are the Windows drive mounted into Linux. Keep project files on the Windows side when you work from PowerShell or Command Prompt.
For voice tools, the split matters in a specific way. Typing into the WSL tab needs only the Windows Terminal window, so dictation works wherever the files live. Project-aware features of a Windows app are different, because they have to find your repository and the program working in it from the Windows side. Section 6 explains what that means for IraVoice's code names.
6. IraVoice with WSL: dictation works, code names may not
IraVoice runs on Windows 10 and 11 (64-bit) as a normal Windows app. It doesn't need WSLg, PulseAudio, or SoX, because the microphone and NVIDIA Parakeet recognition both stay on Windows. Hold Right Ctrl in the Windows Terminal tab where bash or zsh is running in WSL, speak, and release. IraVoice pastes the words with Ctrl+V, so Linux sees ordinary input, and it doesn't press Enter unless you turn on auto submit.
Don't count on code names inside WSL. IraVoice spells names from the Git project the focused app is working in, and the Linux processes inside WSL aren't visible to the Windows app, so a repository you work on inside WSL may not be found. Dictation itself works. If you run Claude Code or Codex natively in PowerShell on a repository stored on the Windows side, you're in Windows Terminal and PowerShell, which IraVoice recognizes for code names.
It's also an option when Claude Code's native voice doesn't fit: native voice streams audio to Anthropic and isn't available when Claude Code uses an API key. IraVoice recognizes speech on the PC and works offline after the one-time model download.