Dictation That Survives the Terminal

There's a complaint that comes up again and again from developers who try dictation tools — any of them, including Wispr Flow and Superwhisper users — and it has a very specific shape. The tool works beautifully in the demo. It works in Notes, in Slack, in the browser. Then you focus a terminal, dictate a sentence, and either nothing appears, or something appears that isn't what you said, or half of it appears and the other half is now mysteriously in your clipboard. Sometimes it works on Monday and fails on Wednesday. Sometimes it works locally and dies the moment you SSH into a box.

The pattern is consistent enough that I don't think it's a bug in any one product. It's a consequence of how the category inserts text — and it fails in exactly the places a developer lives.

That matters more now than it did two years ago. If you drive Claude Code by voice — the workflow I described in driving Claude Code with your voice — then the terminal isn't one app among many. It's the app. It's where your prompts land, where your agents wait for redirects, where the whole parallel-lane thing either works or doesn't. A dictation tool that's flaky in terminals is, for a vibecoder, flaky at its only job.

Why does paste break exactly where developers live?

Here's the category-level mechanic. Most dictation tools insert text the same way: they put your transcribed sentence on the system clipboard, then synthesize a Cmd+V keystroke at the focused app. It's a sensible default — pasting is instant, it works in nearly every GUI text field, and it needed almost no per-app engineering.

The problem is everything that assumption quietly depends on.

It depends on the focused app treating Cmd+V as "paste." Terminals often don't — many use Cmd+V for something else or nothing at all, tmux and vim have their own ideas about what paste means, and a remote SSH session may interpret a burst of pasted text in ways the local machine can't predict. Bracketed paste, copy-mode, insert-mode versus normal-mode: the terminal world is full of states where a synthetic paste lands wrong or lands nowhere.

It depends on the clipboard being available and unguarded. Clipboard managers rewrite it. Password managers deliberately clear or protect it — a security feature that turns "paste my dictation" into "paste nothing," silently. And even when everything works, the tool just overwrote whatever you had copied. The commit SHA you were carrying between windows is gone, replaced by your own sentence. For someone juggling several lanes, that's not a papercut; the clipboard was doing a job.

And it depends — this is the one that surprises people — on your keyboard layout. When a tool falls back to simulating keystrokes, the naive way is to send key codes: the physical key positions. Key codes map to characters through your layout. On QWERTY, the code for "V" produces a V. On Dvorak, that same physical position is a different letter. So a tool that simulates scancodes on a Dvorak, AZERTY, or Colemak layout produces text that looks like it went through a substitution cipher. Users report gibberish and assume the speech recognition failed. It didn't — the speech was perfect, the insertion scrambled it.

None of this is malice or laziness on anyone's part. Clipboard-paste is the right default for the 90% case. It's just that developers spend their day in the other 10%.

What "type it instead" actually means

Keebye has a setting called insert_mode with two values: paste, which is the default, and type.

Type mode doesn't paste. On macOS it uses CGEventKeyboardSetUnicodeString — an API that attaches the actual Unicode text to a synthetic key event. The character is carried in the event itself, not looked up through your keyboard layout. That makes it layout-independent by construction: Dvorak, AZERTY, Colemak, whatever you type on, the text that arrives is the text that was transcribed, because there was never a scancode-to-character translation to get wrong.

The second property of type mode is the one terminal users care about: it never touches the clipboard. Zero clipboard operations on that code path. Your clipboard contents stay yours — the SHA survives, the password manager has nothing to guard against, the clipboard manager has nothing to log.

And because terminals and remote sessions can choke on text arriving faster than any human types, type mode paces itself deliberately: text goes in as 16-character chunks with a 4-millisecond gap between chunks. Fast enough that a sentence lands in well under a second; measured enough that a tmux pane over SSH receives it as keystrokes it can keep up with, not a blob it has to interpret.

Paste mode is still there, and still the default, because it's genuinely faster for big blocks of text in normal GUI apps — a three-paragraph Slack message arrives as one paste rather than a stream of chunks. Even paste mode got the layout lesson, though: the synthetic Cmd+V uses the physical V keycode, so paste itself doesn't break on non-QWERTY layouts the way character-lookup approaches can.

The practical setup for agent work is simple: flip insert_mode to type, focus the terminal running Claude Code, hold the key, say the redirect, release. The prompt arrives the way keystrokes would, because as far as the terminal can tell, that's what they are.

The honest limits

Type mode is slower than paste for long text — that's arithmetic, not a defect. Chunked keystrokes with pacing gaps take longer than a single paste event, and if you're dictating several paragraphs into a document, paste mode will feel snappier. This is exactly why paste remains the default and type mode is something you opt into in settings; the right mode depends on where your text is going.

Some applications rate-limit or filter synthetic input, usually for security reasons, and no insertion strategy fully escapes that — an app that refuses synthetic events refuses them from every dictation tool.

And to be plain about what this article is and isn't claiming: the paste-breaks-in-terminals complaint is a pattern across the dictation category, not a defect unique to any competitor. Other tools have their own answers and their own strengths — we wrote honest comparisons at Keebye vs Superwhisper and Keebye vs Wispr Flow, including where each of them might fit you better.

Insertion is the unglamorous half of dictation

Speech recognition gets all the attention — model names, accuracy claims, language counts. But a dictation tool has two jobs: hear you correctly, and then get the text to where your cursor is without losing or mangling it. The second job sounds trivial and is where the category quietly fails developers, because the second job is easy in TextEdit and hard in a tmux pane on a remote box under a Dvorak layout.

If your prompts land in terminals — and if you're driving coding agents, they do — insertion isn't a footnote. It's the difference between a tool you demo and a tool you use. Related failure modes have the same flavor, by the way: the first word of a dictation getting eaten by mic cold-start is another category-wide complaint with a mechanical explanation, and we wrote that one up in why dictation apps eat your first word.

Keebye is in early access for macOS — Keebye is where to start. If your dictation has ever vanished somewhere between your mouth and a terminal, type mode is the setting to try first.