Guide
Voice input for Claude Code
Claude Code has voice input built in. This guide covers what the /voice command reaches, what it does not, and how one hold-to-talk hotkey covers the rest — the terminal, Cursor, and the browser.
Start with the fact that settles the first question: Claude Code has shipped a native /voice command since March 2026. Inside a Claude Code session it is the built-in way to speak a prompt instead of typing it, it needs no other software, and nothing on this page replaces it.
What /voice cannot do is follow you out of the session, because it is a feature of Claude Code rather than of your Mac. The shell command you run before the agent starts, the commit message after its diff lands, the pull request description, the review comment in a browser tab, the prompt in Cursor’s chat pane — none of those are Claude Code prompts, so none of them can hear /voice.
A system-wide dictation layer is the complement, not the replacement: one hotkey that behaves the same way in each of those places, the Claude Code prompt included. The rest of this page is the setup, app by app.
One hotkey, held while you speak
Voicecape runs in the menu bar. You hold a key — the default on macOS is fn, and you can change it — speak, and let go; the recognised text is inserted at your cursor in whatever app has focus. Holding rather than toggling is deliberate: letting go is the off switch, so dictation cannot be left running by accident. A press-once-to-start mode exists in Settings for longer passages.
Recognition runs on the Mac, against a model that ships inside the app: five languages — English, Korean, Spanish, Japanese and Chinese — from one model, mixed freely within a sentence. Prompts to a coding agent are prose, and prose is what dictation is good at: you describe the change, the constraint and the context the way you would say it to a colleague, at speaking speed.
In the terminal
Claude Code lives in a terminal, and a terminal prompt is a text field like any other. Put the cursor in it — the Claude Code prompt, a plain shell, an SSH session — hold the key, say what you want, release. The text lands where the cursor was, and you press Enter yourself, so nothing runs on the strength of a misheard word.
The same key covers what surrounds the session: the git commit after you accept a diff, the paragraph a human has to put on top of the agent’s work. And if you write commit messages in a terminal editor where a stray paste in normal mode would be destructive, an insertion setting stops one step earlier and leaves the text on the clipboard for you to place.
In Cursor
Cursor is an Electron app, and Electron text fields advertise themselves as writable through the accessibility API without reliably applying the write — so Voicecape does not trust that route there. Insertion goes through the clipboard instead: your text is placed on it, a paste keystroke is sent, and your previous clipboard — images and rich text included — is restored once the paste is observed to land. None of this is configured per app; the path is picked per field.
In practice the same hold-speak-release works in the chat pane, in an inline edit box and in the editor itself. Whether to dictate into the editor is a separate question — code is still better typed, and that boundary is below.
In the browser
A good share of the writing around a coding agent happens in a browser: the pull request description, the review comment that explains why rather than what, the issue that started the whole thing. Browser text fields take the same clipboard path as Cursor, for the same reason — and the clipboard write is marked local to this Mac, so a sentence you just dictated is not pushed through Universal Clipboard to your other devices on its way into a review comment.
A personal dictionary for the words your codebase is made of
A general speech model knows English; it does not know your stack. Say useEffect, kubectl or PostgreSQL to an unprimed recogniser and you tend to get the nearest ordinary English words instead. This is the failure the personal dictionary exists for.
Add the identifiers you actually say — framework names, service names, the CLI tools in your muscle memory, the colleague in half your review comments — and each entry is handed to the recogniser as a vocabulary hint before the session. An entry biases the decoder toward that spelling without constraining it, and can carry a reading for the case where the spelling is a poor guide to how it sounds. Entries are stored on the Mac, per language, and ten to fifteen of them covers most working vocabularies — they are exactly the words you were going to fix by hand anyway.
Exact Clean for the prompt, Verbatim for the error message
Two cleanup modes, both rule-based and both local. Exact Clean is the default: it removes unambiguous fillers and collapses an accidental doubled function word, and it stops there — your wording, order and emphasis survive, which matters for a prompt, because the hedges and qualifiers you say out loud are instructions to the agent. Verbatim leaves the words entirely alone, and is the right mode when you are quoting something that must survive character for character: an error string, a config value, a command someone should run.
What stays typed
Dictating code itself is still a bad idea — the punctuation density and the unpronounceable structure that make it one are unchanged by anything above, and dictation for developers walks that boundary honestly. The split that works is the one this page has been describing: code and commands by hand; prose — prompts, commit messages, reviews, replies — by voice. Which apps take which insertion path is mapped in typing with your voice in any app, and the 14-day trial is the full app. Two neighbouring surfaces have their own pages: dictating prompts into a browser chat box, and writing issues an agent can act on.