Offline voice input for Claude Code, including over SSH

Updated 2026-10-19

If you drive Claude Code by describing what you want rather than typing commands, two questions show up quickly and neither has an obvious answer from inside the terminal: where does my audio actually go, and does any of this still work when I'm SSH'd into another box?

Both have documented answers. This page gives them, then covers what an on-device alternative does and doesn't change.

What Claude Code's own dictation does, per Anthropic's docs

Claude Code ships a /voice command for dictating prompts. Anthropic's voice dictation documentation states its requirements plainly, and three of them matter here. Quoting directly, as of October 2026:

Voice dictation streams your recorded audio to Anthropic's servers for transcription. Audio is not processed locally.

A Claude.ai account: the speech-to-text service is only available when you authenticate with one, and is not available when Claude Code is configured to use an Anthropic API key directly, Amazon Bedrock, Google Cloud's Agent Platform, or Microsoft Foundry.

A local microphone: voice dictation does not work in cloud sessions or SSH sessions.

None of this is hidden or surprising — it's on the first screen of the official page, and the feature is good at what it does. The docs also note transcription "is tuned for coding vocabulary" and that "your current project name and git branch name are added as recognition hints automatically," which is a genuine advantage no general-purpose dictation tool has. Organization administrators can also disable it by policy.

The point is just that these are structural boundaries, not bugs. If you fall outside any of the three — your audio can't leave the machine, you authenticate through a cloud provider, or you work over SSH — you need a different mechanism, not a different setting. Requirements shift between versions, so verify against the current docs before concluding anything about your own setup.

Why SSH is a physics problem, not a product flaw

It's worth being precise about this one, because it gets described as a limitation when it's closer to a fact of the setup.

A microphone is a physical device plugged into the machine in front of you. SSH forwards a terminal session — a stream of bytes in and out of a shell on a remote host. It does not forward audio. So any dictation feature that captures and processes audio on the side where the program is running finds nothing to capture, because there's no sound card, no microphone, and frequently no audio stack at all on a remote server.

Anthropic says as much about the VS Code extension, and the reasoning generalizes:

It 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.

That's the whole explanation. Nobody chose it.

Which also tells you what does work: a tool where both the capture and the delivery happen locally. If something records on your Mac, recognizes on your Mac, and then emits the result as keyboard events into whatever window currently has focus, the remote side never has to know. It receives characters on stdin, identical to what it would have received from your fingers. Whether that window holds a local shell, a tmux pane, a mosh session, or an SSH connection three hops deep is simply not visible to the tool — and doesn't need to be.

This is the main structural argument for a system-level dictation tool over an in-app one, and it applies to every CLI you use, not just Claude Code.

What "on-device" actually buys you — and what it doesn't

This is where it's easy to overclaim, so here's the precise version.

What it gets you: the recording never leaves your machine. There's no upload, no third-party speech service in the path, no question about how long raw audio is retained or whether it's used for anything. Recognition works with Wi-Fi off. There's no API key to manage and no account to attach the audio to.

That matters more than it sounds, because raw audio is not the same as your prompt. It contains the sentence you started and abandoned, a colleague talking in the background, the half of a call that was still going. If you're dictating about unreleased work, client data, or an internal codebase, that extra surface is the part people actually worry about. And it's the part that disappears entirely when nothing is transmitted.

What it does not get you: privacy for your Claude Code session. Once the text is in the prompt and you press Enter, it goes to Anthropic exactly as if you had typed it — same model, same network call, same data handling. On-device recognition removes one hop from your pipeline. It does not make an AI coding tool local, and anyone implying otherwise is selling you something.

So the honest framing is narrow: it changes where your voice goes, not where your prompts go. For a lot of teams — particularly those on Bedrock, Vertex, or Foundry, who tend to have the strictest rules about which vendors touch which data — that narrow difference is still the one that decides whether dictation is allowed at all.

Where Voice Doggo fits

Voice Doggo is one implementation of the system-level approach. Hold the right Option key, speak, release — the transcript is delivered as keyboard input to whatever window has focus. Recognition runs locally via FunASR SenseVoice, so no audio is uploaded and it works offline. No API key, no account, free.

Because it operates at the local input layer, it's indifferent to what's in the window: Claude Code, Codex CLI, a plain shell, tmux, an editor, a browser text field, an SSH session. It doesn't integrate with any of them, which is exactly why it doesn't break on any of them.

Setup is two macOS permissions — Accessibility and Input Monitoring — because simulating keystrokes and watching for a hotkey both require them. Those are capable permissions, and it's reasonable to want to know what a tool does with them before granting. In this case the answer is: capture audio on hotkey, recognize locally, type the result. Nothing goes out.

The limits worth knowing before you install

Three, stated plainly.

Apple Silicon only, macOS 13 or later. Intel Macs are not supported.

Secure Keyboard Entry breaks it silently. Terminal and iTerm2 both offer this setting, and with it enabled macOS stops delivering key events to third-party event taps. Voice Doggo's hotkey never arrives, nothing happens, and no error is shown — which reads exactly like a broken app. Turn it off in the Terminal menu, or iTerm2 → Preferences → General. If you need Secure Keyboard Entry on permanently, no hotkey-driven dictation tool will work in that terminal, and dictating elsewhere and pasting is the realistic fallback. More on diagnosing that in dictation not working in terminal.

Identifiers are the weak spot. SenseVoice has no hotword or custom-vocabulary support architecturally, so function names, flags, and paths are where recognition degrades. This is a real gap against Claude Code's own dictation, which the docs say is tuned for coding vocabulary and seeded with your project and branch names.

The last one shapes how you should actually use voice here. Dictate intent and structure; type or complete the symbols. "Split out the function that handles the login callback, then update the three callers and add a test" transcribes well and gives the model plenty to work with. Reading handleAuthCallback aloud character by character does not, and typing it is faster anyway. For paths, type @ and let the CLI complete.

One habit worth keeping regardless of tool: don't auto-submit. Speak, glance at the text, then press Enter. Recognition errors are normal and a prompt is forgiving of them — but a shell command isn't, and anything already executed can't be recalled.

Choosing between them

If you're signed in with a Claude.ai account, working locally, and comfortable with audio being transcribed server-side, the built-in feature is the better-integrated choice and the code-vocabulary tuning is worth having. Use it.

The system-level approach is for the cases it structurally can't cover: audio that can't leave the machine, a cloud-provider auth setup, or a terminal that's SSH'd somewhere else. Those are also the cases where no setting will help, which is the whole reason this page exists.

For the broader picture of why terminals are the hardest place on macOS to get dictation working at all — and why built-in macOS dictation often fails there specifically — see voice input in the macOS terminal.