1. The microphone never crosses the SSH connection
SSH gives you a terminal session on another machine. It carries what you type and what the server prints, not your audio devices. Anthropic states the consequence plainly: Claude Code voice dictation needs “a local microphone” and “does not work in cloud sessions or SSH sessions.” The same documentation describes the errors a remote host produces. SoX reports that it couldn't open an audio capture device on “a headless server or a container,” and after three failures within 10 seconds voice input is paused, which Anthropic attributes to things like “a remote shell with no audio passthrough.”
Installing more audio software on the server doesn't fix this. A server has no access to the microphone on your desk. Either capture and recognize speech locally, or run the voice-enabled program locally.
2. VS Code Remote, Dev Containers, and Codespaces follow the same rule
VS Code's Remote-SSH documentation explains where code runs: extensions run “locally on the UI / client side, or remotely on the SSH host,” and while UI extensions such as themes stay local, most extensions live on the SSH host. Anthropic draws the conclusion for its own extension: Claude Code's voice dictation “is not available in VS Code Remote sessions, including SSH, Dev Containers, and Codespaces, because the microphone is on your local machine and the extension runs on the remote host.”
The VS Code window itself stays local, and so does its integrated terminal panel, even when the shell behind it runs on the server. A dictation app on your computer that types into the focused window can therefore reach a remote terminal inside VS Code, just as it reaches a standalone terminal running ssh.
3. Local dictation types, and SSH just carries the characters
From the remote shell's point of view, dictated text is indistinguishable from typing. Your terminal emulator turns keystrokes or a paste into bytes, ssh sends them, and the program on the other end reads them. That includes tmux or screen on the server: the active pane receives the text the same way.
Pastes get extra protection when the remote program asks for it. The readline manual describes enable-bracketed-paste, on by default, which makes readline insert each paste “as a single string of characters” and prevents it from “executing any editing commands bound to key sequences appearing in the pasted text.” Whether that applies depends on the remote shell's configuration, not your laptop's, so treat every dictated line as unsent until you've read it.
- Check the prompt's hostname before you speak; you may be on production.
- Dictate into an agent prompt or an editor, not into a half-typed command.
- Never dictate a password at an SSH or sudo prompt.
- Read the full line, then decide whether to press Enter.
4. mosh: dictated text appears even on a slow link
Mosh replaces interactive SSH for unreliable networks. Its site describes roaming, support for intermittent connectivity, and “intelligent local echo and line editing of user keystrokes.” On a bad connection, outstanding predictions are underlined so you aren't misled. Mosh logs in through SSH and then talks to mosh-server over UDP, on a port between 60000 and 61000, so a firewall has to allow that. mosh --predict=never turns off the instant echo.
Mosh predicts the echo of keystrokes, so dictated text that arrives as typing can appear before the server confirms it, underlined while it's unconfirmed. On a hotel or train connection, wait for the underlines to clear before you review and send a long prompt, so you're reading what the server actually received.
5. When native voice is still the right call
If Claude Code runs on your own computer, its native /voice works and needs no extra software: hold Space, speak, release, and the transcript lands in the prompt. It requires a Claude.ai sign-in, streams audio to Anthropic's servers for transcription, and isn't available with an API key, Amazon Bedrock, Google Cloud's Agent Platform, or Microsoft Foundry.
Over SSH none of that is an option, so the choice comes down to which local dictation tool to use. Pick one that types into any window, so it works in the terminal app you already use for ssh.
6. IraVoice over SSH: dictation yes, code names from a local repo
IraVoice runs locally on macOS 13+ on Apple silicon, Windows 10 or 11 (64-bit), and Linux (beta) and types into whichever window has focus, so it works in a terminal that is running ssh, in tmux on the far end, over mosh, and in a VS Code window connected to a remote host. The microphone and NVIDIA Parakeet recognition stay on your computer, nothing is installed on the server, and the server receives only the finished text.
Hold the key (Right Command on a Mac, Right Ctrl on Windows, Ctrl+Space on Linux, where IraVoice is in beta), speak the prompt for the remote Claude Code or Codex session, and release. IraVoice doesn't press Enter by default, so you can read the line and check the hostname first.
Code names have a local limit. IraVoice spells file and function names from a Git project on your own computer, never from the remote host. A repository that exists only on the server isn't read, so type rare names yourself or correct them once with the Fix shortcut. IraVoice then learns the corrected word.