Dictation Not Working in iTerm2? Check Secure Keyboard Entry

You dictate into iTerm2 and the text never lands. With the default fn trigger, the HUD still shows a card — Another app has secure input on. With a custom trigger key, there is nothing at all: no HUD, no sound. In Mail it just works either way. Nothing is broken. Secure Keyboard Entry is doing its job, and dictation apps sit inside its blast radius.

The symptom: dead or half-dead, only while a terminal is in front

Three checks separate this from the other “dictation not working” causes:

Dead everywhere, on a fresh install? That is usually the fn key itself — macOS has it bound to emoji or input switching — or Accessibility was never granted. See fn key conflicts on Mac. Recording starts but nothing comes back? More likely a missing language pack: Mac dictation not working.
Dead only in Terminal, iTerm2 or another terminal, and back the moment you switch apps? Keep reading.
Worked yesterday, dead in every app today, nothing changed? Usually a background app stuck holding secure input. Same mechanism, covered below.

What Secure Keyboard Entry actually does

macOS has a system-wide flag called secure event input. An app raises it when it wants your keystrokes to reach it and nothing else; the intended case is a password field. Terminals expose it as a menu item because a terminal is where you type passphrases and sudo passwords.

Apple’s developer note on the mechanism, TN2150, is explicit about the cost: while any process holds the flag, the system stops delivering keyboard events to every keyboard-intercept process, “whether that process is in the foreground or background” (as of 2026-09-18). Event taps are on that list — but not evenly: “macOS keeps delivering modifier-key events but blocks regular key presses, so holding Fn works” (Wispr Flow).

ListenIn reads its trigger through a system event tap — a bare modifier like fn or Right ⌘ cannot be registered as a normal hotkey, so a tap is the only way to see it. That split decides what you experience: the default fn trigger is a bare modifier, so the tap still sees it — recording starts, and it is the paste that gets blocked. A custom trigger key (F5, or any combo you record yourself) rides the same channel as a normal keystroke, so it goes fully silent under secure input: no HUD, no card, nothing. iTerm2’s own menu documentation undersells the scope: the option “may disable global hotkeys in other programs.”

Note the wording: other programs. Anything that watches the keyboard from outside the focused window is locked out by design — just not all of it equally.

Find the culprit

Three places to look, in order of likelihood.

The terminal’s own menu. Apple’s Terminal User Guide documents the item as Terminal > Secure Keyboard Entry, with a checkmark when it is on. iTerm2 documents its equivalent under the iTerm2 menu with the same name. If it has moved, search the Help menu for “Secure”. Don’t assume it clears the moment you click away: “Terminal’s Secure Keyboard Entry stays active in the background” (Wispr Flow), so unchecking it explicitly is what actually works, not switching apps.

A password prompt. If the key dies only while sudo or ssh is waiting for a password and returns after you press Enter, the terminal may have raised secure input for the prompt and released it afterwards. If so, nothing to fix.

An app that forgot to release it. Apple’s note says a process must call DisableSecureEventInput when done; one that doesn’t blocks every keyboard listener system-wide until it lets go — a browser tab parked on a login form, a password manager, a lock screen that came and went. This is the “dead everywhere” pattern. To find the holder:

ioreg -l -w 0 | grep SecureInput

When something holds secure input, this prints a kCGSSessionSecureInputPID entry with a process ID; ps -p <pid> -o comm= usually names it — though for a background holder, macOS can report whichever app was frontmost instead, so treat the name as a lead, not a verdict. Nothing holding it prints nothing at all (0 lines on a macOS 26 Mac we checked). Quit the suspect app, or switch to it and away again.

Why “just turn it off” is the wrong default

The usual advice is “disable Secure Keyboard Entry”. It works. It also means every process that can watch the keyboard, dictation app included, now sees what you type into the one window meant for secrets. Apple’s guide puts the burden the right way round: before turning the feature on, “make sure other apps don’t require keystrokes from Terminal” (Apple Terminal User Guide). A dictation app does not need your keystrokes. It needs somewhere to put text. Those are different things. (Apple, iTerm2 and Wispr Flow documentation quoted as of 2026-09-18.)

So the question for a dictation app is not “how do I make you work with it off”. It is “what do you do when it is on”.

What a dictation app should do instead

Not paste. Secure input exists to keep other processes’ keyboard events out of the terminal, and a synthesized ⌘V from a dictation app is exactly that. An app that claims a clean way through is either defeating a security control or overstating.

ListenIn does the boring thing. Before a dictation paste it asks macOS whether secure input is on. If it is, there is no paste; the HUD shows a card reading Another app has secure input on · click to copy. Click it, the text is on your clipboard, and you press ⌘V yourself — the terminal handling its own keystroke, which secure input has never blocked. The check runs for dictation and Ask Anything. AI commands sent to the front app get the same check but the generic card, Couldn’t auto-insert · Click to copy. A command routed to another app skips it: that app is activated first, then pasted into (see voice coding).

The same rule covers the neighbouring cases, for dictation:

Situation	What you see
The focused control is a password field	Can’t paste into a password field · click to copy
Accessibility permission was never granted	Turn on Accessibility to paste at your cursor · click to copy
Paste went out and the field still reads back unchanged	Couldn’t auto-insert · Click to copy

Ask Anything shares the Accessibility and read-back rows but has no password-field card: it only pastes into a field macOS reports as writable, so a password field falls through to the generic Couldn’t auto-insert card.

fn always reaches ListenIn, so you always get a card at paste time. A custom, non-modifier trigger never reaches ListenIn under secure input — silence instead. Silence on fn means something else: go back to “Find the culprit.”

Pasting into terminals: the clipboard snapshot and where it stops

ListenIn inserts by pasting, not typing keystrokes. A paste lands as one block; the terminal’s own paste handling decides what to do with it, and your clipboard is involved every time. Exactly what happens (short version on the security page):

Snapshot the clipboard: every item and every data type on it, not only plain text.
Write the dictation as plain text, flagged with the transient-type convention (org.nspasteboard.TransientType) so clipboard managers that honour it skip the entry.
Post ⌘V about 0.12 s later.
About 0.9 s later, restore the snapshot — only if the clipboard’s change counter has not moved. If you copied something yourself in that second, your copy stands and the restore is skipped.

Where it stops:

It is a timer, not a handshake. macOS gives no signal that the target app has finished reading the pasteboard. The window was lengthened from 0.4 s to 0.9 s after large pastes into remote desktops and VMs were read late; a slower target means the restore wins and old clipboard content lands. Rare on a local terminal, but possible.
During the window, the dictation is your clipboard. A clipboard manager that ignores the transient flag will record it.
A copy card is a real copy. When you click a card, the text is meant to stay on your clipboard, so it is neither flagged transient nor restored over.

One terminal wrinkle, for dictation: most terminals do not expose a standard editable text element to Accessibility, so ListenIn cannot always confirm in advance that the cursor is in something pasteable. It pastes anyway when Accessibility is granted and secure input is off, then reads the field back. If the field can be read back and still shows the old contents a couple of seconds later, you get the Couldn’t auto-insert · Click to copy card. If ListenIn cannot read the field at all — most terminals — it stays quiet. The text is in History either way. Ask Anything is stricter and typically shows the copy card up front instead of guessing.

Scope notes: tmux, SSH, VS Code Remote

Not separately tested for this article; this is what the mechanism implies, not a test report.

tmux. ListenIn pastes into the terminal emulator; tmux sees the pasted text as ordinary terminal input. Secure input is a property of the local terminal app, not of tmux.
SSH. The remote shell never touches macOS secure input. A remote password prompt blocks your trigger only if your local terminal raises the flag for it (see “A password prompt” above).
VS Code Remote. The integrated terminal is a local Electron text area, so pasting behaves as in local VS Code and the remote end doesn’t participate. Electron’s Accessibility read-back can lag, one reason the copy card waits rather than firing on the first failed check.

If one of these behaves differently for you, that is a report we want; the FAQ covers the general Mac setup.

Keep Secure Keyboard Entry on; voice typing into a terminal is only safe while the protection stays on. When the key goes dead, find who holds the flag. Expect your dictation app to hand you the text rather than argue with the protection. That is how ListenIn’s Mac dictation is built, and why the copy card exists.