Does macOS Dictation work inside Terminal or iTerm2?

Inconsistently. Dictation starts fine — the system listens and transcribes — but terminal emulators draw their own character grid instead of using standard macOS text controls, so the accessibility-based insertion path Dictation relies on often has nowhere to put the text. Behavior varies by terminal and macOS version; test it on your own setup before relying on it.

I hold my hotkey in the terminal and nothing happens. Why?

The most under-documented cause is Secure Keyboard Entry. When a terminal has it enabled, macOS enters Secure Event Input state and stops delivering key events to third-party event taps, so any tool triggered by a held hotkey never sees your keypress. It fails silently — no error, no indicator. In Terminal.app, uncheck it in the Terminal menu; in iTerm2 it lives under Preferences → General.

Does voice input work over SSH or inside tmux?

Yes, for tools that deliver text as synthetic keyboard input. They operate at the macOS window layer and type into whatever window has focus — the fact that a remote shell or a tmux pane is running inside that window is invisible to them. Voice entry points built into a specific application generally cannot reach other windows this way.

Can voice input dictate code identifiers like function names?

Treat identifiers as the weak spot of every speech recognizer, not as a solved problem. Voice Doggo uses FunASR SenseVoice, which architecturally has no hotword or custom-vocabulary support, so camelCase names, underscores and abbreviations are exactly where you should expect to correct by hand. The practical workaround is to describe intent in plain language and let your editor or AI tool resolve the symbol.

Does dictating into a terminal require an internet connection?

It depends on the approach. Cloud ASR tools upload audio to a server. macOS Dictation can run locally when Enhanced Dictation is downloaded, though the exact naming and availability varies by macOS version. Tools built on a local model — Voice Doggo runs FunASR SenseVoice on-device — do recognition entirely on your machine and work with the network off.

What permissions does keystroke-injection voice input need, and why?

Two, both under System Settings → Privacy & Security. Accessibility lets the app post synthetic keyboard events on your behalf, which is how the transcript reaches the focused window. Input Monitoring lets it observe the hotkey you hold. These are broad grants, which is a good reason to check whether a given tool uploads your audio before you grant them.

Voice Input in the Mac Terminal (Not the say Command)

Updated 2026-10-19

Search for voice input on the Mac terminal and most of what comes back is about the say command. That is the opposite direction. Three different things get tangled under the same words, so let's separate them first:

say is text-to-speech. It takes a string and reads it aloud. say "build finished" is a notification trick, not an input method.
VoiceOver is a screen reader — an accessibility technology that describes the interface to you. Also output.
Dictation is speech-to-text. You talk, characters appear.

This page is about the third one, in the hardest place on macOS to make it work: a terminal emulator.

Why terminals are hard

macOS Dictation (two taps of a modifier key by default — the exact key depends on your settings) works well in Notes, in Safari text fields, in Slack. In Terminal.app or iTerm2 it frequently does nothing, or inserts text somewhere unexpected, or transcribes and then quietly drops the result.

That is not a bug. It is a consequence of how terminals are built.

Dictation hands its result to the focused text control, going through the macOS accessibility layer. Ordinary apps use NSTextField, NSTextView and friends. The system knows where the insertion point is, what the selection is, and how to replace a range.

Terminal emulators don't participate in that. Terminal, iTerm2, Warp, Alacritty, Ghostty — they draw a character grid themselves and convert keyboard input into a byte stream written to a pseudo-terminal. To the accessibility layer, a terminal looks closer to a canvas than to a text field. There is no standard insertion point to target, so the insertion path has nothing to land on.

Everything running inside that terminal inherits the problem. Vim, a Python REPL, Claude Code, Codex CLI — they consume bytes from the PTY and never touch a graphical text control. The application can't fix this on its own; the gap is one layer below it.

Some tools have added voice entry points of their own. Those are genuinely useful inside the product that ships them, but two structural limits apply regardless of which product you pick: the entry point works inside that product's own UI and not in the terminal tab next to it, and most such features send audio to a server for recognition. Neither limit is about any particular vendor's roadmap — it follows from where the feature sits.

Approaches that actually land text

1. Synthetic keyboard input

Stop trying to insert text and instead type it. The tool transcribes your speech, then posts the result as keyboard events. The terminal receives bytes indistinguishable from you hitting the keys yourself, because at the level that matters, that's what happened.

This is the most reliable route in a terminal specifically because it demands nothing from the application — no accessibility tree, no text control, no plugin. The window just needs focus. The cost is two system permissions (below) and the Secure Keyboard Entry caveat (further below).

Voice Doggo takes this route: hold right Option, speak, release, and the transcript is typed into whatever window has focus. Terminals, SSH sessions, editors and browser text boxes are all the same case. Recognition runs on-device with FunASR SenseVoice — no network, no API key. Apple Silicon, macOS 13 or later.

2. Voice features built into an editor or terminal

Several editors and terminals ship voice input in their own chat panels or command surfaces. If your dictation happens inside that one surface, this is the least setup for the best integration — the feature knows the app's context in a way an external tool never will.

The limit is scope, not quality. It covers the surface it was built for. A different CLI in the next tab, a browser text box, a remote shell — those are outside it.

3. Transcribe somewhere else, then paste

Dictate into Notes or any text editor using whatever dictation you already have, then copy and paste into the terminal. Clumsy, zero setup, zero permissions, and entirely adequate if this is an occasional need rather than a daily workflow. It's also the fallback worth remembering when Secure Keyboard Entry has to stay on.

4. Roll your own

Wire up whisper.cpp (or a cloud ASR API) behind a hotkey: record on keydown, transcribe on keyup, deliver the text with pbcopy plus a paste keystroke, or by driving an event-posting helper. Hammerspoon, skhd or a small Swift binary all work as the trigger layer.

Maximum control, and the model is yours to choose and swap. What you're signing up for is the delivery layer — the same keystroke-injection and permission problems described above, except now you maintain them — plus model download size, latency tuning, and key management if you go the cloud route.

How the options compare

Approach	Works in terminal	Audio leaves machine	Setup cost
macOS Dictation	Unreliable — no standard text control to target	Depends on version and settings	None
Keystroke-injection tool	Yes, any focused window	Depends on the tool; on-device options exist	Two permission grants
In-app voice feature	Only inside that app's own surface	Usually yes	Minimal
Transcribe and paste	Yes, via clipboard	Depends on the dictation you use	None
Self-built (whisper.cpp etc.)	Yes, if you build the delivery layer	Your choice	High

If your center of gravity is the terminal — writing prompts for a CLI agent, composing long commands, taking notes inside an SSH session — the keystroke-injection row is the only one that doesn't make you leave the window.

The permissions, and why they're broad

Any tool that types for you needs two grants under System Settings → Privacy & Security:

Accessibility — permission to post keyboard events on your behalf. This is how the transcript reaches the focused window.
Input Monitoring — permission to observe which keys you're holding, so the hotkey can trigger at all.

Together these are, in effect, "may act as a keyboard and may watch the keyboard." That is a lot of trust. It's worth one minute of diligence on any candidate: does it upload audio, is the data flow documented, is the recognition local? A fully on-device tool materially narrows the question — the audio never leaves the machine, so the remaining risk is confined to the binary you're running.

Secure Keyboard Entry: the silent failure

This is the terminal-specific trap, and it is nasty precisely because there is no error message. You hold the key. Nothing happens. No alert, no indicator, no log line. The natural conclusion is that the tool is broken.

Terminal.app has a Secure Keyboard Entry item in its Terminal menu. With it enabled, macOS enters Secure Event Input state and stops delivering key events to third-party event taps. The mechanism is doing its job: it prevents other processes from observing passwords you type into a terminal.

The side effect is that every hotkey-driven tool goes deaf while that terminal has focus. Hold right Option, get nothing.

How to check and fix:

Terminal.app → Terminal menu → look for a checkmark next to Secure Keyboard Entry.
Uncheck it and try again.
iTerm2 has the same setting under Preferences → General. Other terminals may expose it elsewhere or not at all — check your terminal's own settings if neither location applies.

The trade-off is real. Turning it off means other processes can, in principle, observe what you type in that terminal. If you routinely type passwords directly into a shell rather than using a password manager or SSH keys, leaving it on is the safer call — and in that case the transcribe-and-paste route is your fallback.

This limit applies to every tool that depends on an event tap. Voice Doggo is no exception, and it does not currently warn you about it. If holding the key does nothing in a terminal, check this switch first.

A workflow worth keeping

Once it's set up, the rhythm that holds up over time looks like this:

# start a CLI agent in the terminal
$ claude

# cursor on the input line — hold right Option and talk
> "split the auth middleware into two functions,
>  one commit per file, then run the tests"

# release, read what landed, then press Return

Keep finishing the sentence and pressing Return as two separate acts. Recognition will get things wrong — identifiers and acronyms most of all — and a command in a terminal cannot be un-executed. The half-second of reading is the whole safety margin.

This page covers the general problem. Two specific situations have their own pages:

You held the key and nothing happened, with every permission granted — that is almost always Secure Keyboard Entry. Causes, ordered by likelihood
Dictating to Claude Code, and wondering where the audio goes — including why /voice does not work over SSH. On-device vs server-side transcription