Why your dictation tool stops working over SSH
It works in Mail. It works in Slack. You SSH into a server, start talking, and nothing arrives.
This is one of the more confusing failures in dictation software, because nothing errors. The tool says it heard you. The transcript is right there in its own window. It just never reaches the place your cursor is blinking.
The cause is not the network and it is not the remote machine. It is the method your dictation tool uses to hand text to an app - and once you know which method it uses, you can predict this failure instead of running into it.
Four ways a Mac app can put text somewhere
Every dictation tool picks one of these. They behave identically in a Notes window and diverge completely everywhere else.
- Accessibility APIs. The tool asks macOS for the focused text field and sets its value directly. Fast and exact - when there is a text field to find.
- App-specific integrations. A plugin or extension for one editor or one browser. Perfect inside that app, nonexistent outside it.
- Its own window, then you copy. The transcript lands in the tool and you paste it yourself. Never breaks, always costs you two extra steps.
- Synthesized keystrokes. The tool posts real key events to the system, the same events a keyboard produces. Whatever has focus receives them.
Why the terminal is the case that breaks them
A terminal running an SSH session is not a text field. It is a screen buffer being drawn by a program on another computer. There is no macOS text control holding your half-typed command, because your half-typed command does not live on your Mac at all - it lives in a shell process on the remote host, and your terminal is showing you a picture of it.
So the first method has nothing to write into. The accessibility API can see a terminal window; it cannot find a value to set, because the thing you think of as the input line is characters painted on a grid. Tools built this way tend to fail silently here rather than complain, which is why the experience is "it just did nothing".
The second method fails for the more obvious reason: nobody ships an SSH plugin. And the third does not fail so much as make you do the work, which gets old fast when the whole point was to talk instead of type.
Synthesized keystrokes are the one that survives, and it is worth being precise about why. Your terminal is already in the business of taking keystrokes and shipping them down the SSH connection - that is its entire job. It cannot tell whether a key event came from your fingers or from software, because at the level it reads them there is no difference. The remote shell receives ordinary typing.
The same reason it works in the other awkward places
Once the mechanism is keystrokes, a whole category of "does it support X" questions stops being interesting. A remote desktop session, a virtual machine, a Citrix window, a game, an Electron app with a custom text editor, a browser canvas - none of them expose a tidy macOS text field, and all of them accept keys.
This is the practical test to apply to any dictation tool before you commit to it: open a terminal, SSH somewhere, and talk. It takes ten seconds and it tells you which of the four methods you bought. It is also why MightyMouse types your words at the system cursor, into any app rather than hooking into apps one at a time.
The tradeoff, honestly
Keystroke delivery is not free of downsides, and the main one is that it is literal. Text arrives as typing, so anything with an opinion about typing gets a say - an editor with autocomplete may complete a word mid-sentence, a vim buffer in normal mode will interpret your sentence as commands rather than insert it, and a shell with a bracketed-paste-dependent prompt may handle a long block differently than a real paste.
None of these are dealbreakers, and all of them are avoidable once you know: be in insert mode before you talk, the same as you would be before you typed. Which is the general shape of this - keystroke delivery behaves exactly like a very fast typist, including in the places a very fast typist would also cause trouble.
For the specifics of running the transcription itself on your own machine rather than sending audio out, see dictating anywhere on your Mac without the cloud.
Dictation that works in your terminal too.
Free local transcription, into any Mac app. No card to try it.
Common questions
Why does my dictation work in Chrome but not in my terminal?
Chrome exposes real text fields that macOS accessibility APIs can write into. A terminal showing an SSH session does not - the line you are typing lives on the remote machine, and your terminal is drawing a picture of it. A tool that writes into text fields has nothing to write into; a tool that sends keystrokes works in both.
Does dictation over SSH send my words to the remote server?
Your words arrive at the remote shell as keystrokes, exactly as if you had typed them - so yes, whatever you dictate into a remote session goes to that machine, the same as typing does. Where the audio was transcribed is a separate question, and that depends on whether your tool transcribes locally or in the cloud.
Will it work in vim or a full-screen editor?
Yes, with the same caveat that applies to typing: be in insert mode first. Keystroke delivery is literal, so a sentence sent to vim in normal mode is read as commands rather than text.
If your terminal is where you actually work: MightyMouse dictates into any Mac app, SSH sessions included, with the transcription running free on your own machine.