Voice dictation for Claude Code
Claude Code lives in the terminal. There is no chat panel, no sidebar, no buttons — just a prompt where you type what you want, and an agent that goes off and does it. It is a deliberately plain interface, and that plainness turns out to suit voice unusually well. There is exactly one thing you do at that prompt: describe a task in natural language. That is the entire surface, and natural language is what voice is made for.
This post is about dictating to Claude Code: why the conversational style fits speaking, and a workflow that holds up over a full day of real work.
The prompt is a conversation, so talk to it
When you use Claude Code, you are not entering commands in the old Unix sense. You are explaining a goal. "Look at the auth middleware, figure out why expired tokens are not being rejected, and fix it — keep the existing logging." That is not a command line. It is a sentence you would say to a teammate.
Typing it feels slightly wrong, and most people respond by typing less. The prompt shrinks to "fix the token bug," the agent has to guess at the scope, and you spend the next two turns correcting it. The interface invites a conversation and then the keyboard quietly discourages you from having a full one.
Voice removes that discouragement. When you speak a prompt to Claude Code, you naturally give it the shape of an actual instruction: the goal, the relevant files, the constraint, the thing to leave alone. You include all of it because saying three sentences costs you nothing more than saying one. And Claude Code, like any agent, does noticeably better work when the prompt is complete. Fewer corrective turns, less back-and-forth, a faster path to done.
Why the terminal is a fine place for voice
People sometimes assume voice belongs in graphical apps and the terminal is a keyboard-only zone. It is the opposite. The terminal is text, and a dictation tool that inserts text at the cursor works in a terminal exactly as it works anywhere else.
A terminal has a cursor. When Claude Code is waiting for your input, that cursor is sitting in an input prompt. A system-wide dictation tool does not need to know whether that cursor is in a terminal, an editor, or a browser. It inserts the transcribed text where the cursor is. No integration, no plugin, no terminal-specific setup. Your spoken prompt simply appears at the Claude Code prompt, ready to send.
This is how Lispr works. It is a small macOS menu-bar app with no window. You hold the right Option key, speak, release, and the text lands at the cursor in whatever app has focus — including your terminal emulator. It does not have special handling for Claude Code, or for any tool. It treats the terminal as what it is: a place where text goes. That is all it needs to do.
A practical day-to-day workflow
Here is a routine that works once the habit settles in, usually after a day.
- State the task by voice. When the Claude Code prompt is waiting, hold the right Option key and describe what you want in full sentences. Name the files, state the constraint, mention what not to break. Release the key.
- Glance before you send. Dictated text deserves a quick read. Spoken numbers, a misheard filename, a stray word — catch them now. Then press enter.
- Read the agent's plan and respond by voice. Claude Code will often outline what it intends to do. Your reply — "yes, but also update the tests" or "skip the third step, that file is generated" — is conversational. Speak it.
- Type the small, exact things. A precise file path you want to paste, a flag, a single token — typing is fine and often faster for those. Voice is for the sentences, not the symbols.
- Dictate the commit message and PR text afterward. When the work is done and it is time to write history, hold the key and say a full, descriptive message. It is prose, and it belongs to voice.
Across all of this you never switch into a "voice mode." You hold a key when you have something to say, and let go when you are done. The rest of the time your hands rest on the keyboard. The two interleave naturally because the division is natural: the agent wants language, and language is what you speak.
Where voice does not help
Be honest with yourself about the edges. Voice will not type a regular expression for you, and you should not ask it to. It will not reliably dictate a long shell one-liner full of pipes and flags. When the thing you need is dense punctuation, type it.
But that is a small slice of a Claude Code session. The bulk of your input is the prompt, the clarification, the "try again but this way" — all of it prose. We covered the broader version of this split in how to start coding by voice: type the syntax, speak the language. With an agent in the terminal, that split is especially clean, because the agent's entire input channel is language.
What changes after a week
Two things tend to stick. The first is that your prompts to Claude Code get longer and more specific. You stop writing "fix the bug" and start describing the bug, the suspected cause, and the boundary of the change — because describing it out loud is effortless. The agent's results improve in step with that.
The second is that the terminal stops feeling like a keyboard-only place. You speak to Claude Code the way you would think out loud while pairing with someone. The interface was always a conversation. Voice just lets you hold up your end of it without typing every word.
If you also work in a graphical editor, the same idea applies there — see voice dictation for Cursor. And for the wider case for voice in a developer's day, there is voice-to-text for developers.
Try Lispr
Voice to text in any Mac app — hold a key, talk, let go. Free, no account, ~4 MB.
Download for macOS