"In a text field, a wrong paste is embarrassing. In a terminal, a wrong paste runs."
Why Terminals Are Special
Dictating into Terminal, iTerm, a VS Code or Cursor integrated terminal, or a coding-agent CLI like Codex or Claude Code is a first-class use case — Dad lives in those all day. But a terminal is not a generic text field. Text pasted there can execute. A big hidden paste block you can't read before it runs is hostile at best and dangerous at worst. So Firekeeper gives terminals their own insertion profile with different rules from a Mail compose window.
The Terminal Profile Rules
Detect the target as a terminal (by bundle id — Terminal, iTerm2, Ghostty, editor-embedded terminals, agent CLIs) and switch behavior:
- Short single-line dictation: paste normally.
- Long or multi-line dictation: keep it visible and editable — a preview overlay with an explicit "send to terminal," or slow/line-by-line insertion, or bracketed-paste-aware insertion if the target supports it.
- Never auto-press Enter after a long terminal dictation unless the user explicitly spoke "press enter" and enabled that behavior.
The Enter rule is the load-bearing one: a dictation that auto-executes is a dictation that can run a command you didn't finish thinking about.
Generic text field: paste text -> done
Terminal profile: detect terminal
-> short? paste
-> long? preview / chunk / bracketed-paste, stay editable
-> Enter ONLY if spoken "press enter" AND enabled
Respecting the Working Loop
The deeper idea is respect for the user's actual workflow. A developer dictating a long prompt into a coding agent wants to see and edit it before sending — that's how the tool fits their loop instead of fighting it. Wispr Flow figured this out; Firekeeper treats it as a design requirement, not a nice-to-have. The terminal profile is what turns "I can dictate" into "I can dictate into my actual dev environment safely."