Dictation Not Working in iTerm2? Check Secure Keyboard Entry

If dictation works in Notes but not in Terminal or iTerm2, check Secure Keyboard Entry before changing your microphone settings. Secure input can interfere with global shortcuts and automatic paste. It is one possible cause—not proof that every terminal failure has the same explanation.

Ducduc checks secure input before automatic insertion. A completed result can be kept in a copy card and History when paste is blocked. If secure input prevented recording from starting, no transcript was created. This distinction tells you whether to recover text or fix the trigger first.

The terminal documentation and Ducduc source were checked October 17, 2026. This guide does not claim compatibility tests across every terminal, macOS version or SSH configuration.

Start with the symptom

Symptom	Check first
The trigger is silent in every app	Accessibility permission, the configured shortcut and fn conflicts
The orb reacts but no transcript is produced	Recognition language/assets and microphone input
It works elsewhere but fails while a terminal is active	Secure Keyboard Entry and whether the trigger reaches the app
A transcript exists but you get a copy card	The card’s reason: secure input, changed target or unverified insertion

Start with fn shortcut conflicts or language-model setup when those symptoms fit. Do not reinstall the recognizer merely because insertion failed.

What Secure Keyboard Entry does

macOS secure event input restricts keyboard events reaching other processes. Apple’s archived technical note TN2150 describes the system-wide effect; iTerm2’s menu documentation notes that Secure Keyboard Entry may disable global hotkeys in other programs.

Modifier and ordinary-key shortcuts can behave differently under secure input. A bare fn or Command trigger may behave differently from a custom shortcut, but no trigger should be described as guaranteed on every keyboard and macOS version.

Apple documents Terminal’s option in Use secure keyboard entry in Terminal on Mac. Check Terminal → Secure Keyboard Entry, or the corresponding iTerm2 menu item. A password prompt or another app may also be holding secure input; the frontmost terminal is not always the owner.

Check the menu, recover the text, then retest

1. Finish any password or authentication interaction. Focus a normal input; do not test dictation in a password prompt.
2. In Apple Terminal, inspect Terminal → Secure Keyboard Entry. In iTerm2, inspect iTerm2 → Secure Keyboard Entry. A checkmark indicates that terminal’s option is on. Another app may also have enabled secure input.
3. If Ducduc already produced text, use Copy or open Dictation History. Focus the intended input and paste with your own keyboard action. Do not press Enter yet.
4. Test the configured trigger in Notes with an ordinary phrase. If it works there, return to the actual terminal prompt and test once. If it fails everywhere, check Accessibility and the configured key.
5. If secure input appears stuck after authentication ended, save your work and quit/reopen the suspected app when practical. Inspect the menu again. Do not force-quit a session with unsaved terminal work merely to test a shortcut.

You can choose whether to change Secure Keyboard Entry for your workflow, but understand its purpose first: it restricts other apps’ ability to observe typing. Manual recovery lets you use a completed transcript without treating automatic paste as essential. A successful trigger test also does not prove automatic insertion will succeed; they are separate stages.

Native Claude Code /voice records through the terminal’s microphone permission. Ducduc records through its own permission. If /voice reports a microphone error but Ducduc works, use the Claude Code guide; changing Ducduc’s recognition language will not grant the terminal microphone access.

What Ducduc does when paste is unsafe

The current insertion path checks Accessibility access, secure input and the captured target. It checks again before posting the actual paste. Routed AI commands use the guarded paste path too; activating another app is not a bypass around secure input.

Situation	Expected response
Secure input is active	Copy fallback rather than automatic paste
A password field is focused	No automatic insertion into that field
You changed the app, field or known selection	Copy fallback instead of pasting to the old or new unintended target
Read-back shows that a paste did not land	Copy fallback
A field cannot be read back	Delivery cannot always be verified; use History if the text did not appear

Click Copy to place the result on the clipboard. The large card closes and a small Copied toast appears. You choose where to paste it. A copy card is not data loss; do not dictate the same request repeatedly just because the original paste was blocked.

Selected-text voice editing is stricter about replacement: it needs a writable target and a still-valid selection. See voice input for coding tools for the distinction between dictation and AI-command routing.

Confirm whether the cursor is in an agent prompt or a shell

A terminal window can contain a coding-agent composer, an ordinary shell, a REPL or a password prompt. The same pasted sentence means different things in each. This synthetic example is prose for an agent:

Explain why the deployment failed. Inspect the log first; do not deploy again.

In the agent’s input, check that both the request and the no-deploy constraint arrived before sending. At a shell prompt, do not submit that sentence as a command. Exact executable commands, quotes, flags and paths need character-by-character review; a clean-looking transcript is not validation of shell syntax.

For the first delivery test, leave the phrase unsent. Success means it appeared exactly once in the intended input. If the agent composer folds a long paste into a placeholder, consult the destination-input explanation before assuming text was lost.

How clipboard restoration works

Ducduc inserts one block by paste. Its synthetic clipboard operation is serialized so a second operation cannot overwrite a paste already in progress:

1. Validate the target and snapshot clipboard items and types.
2. Put the dictation on the clipboard with a transient marker.
3. Recheck clipboard ownership and the target, then post one ⌘V after a short delay.
4. Restore the snapshot after the consumption window, only while Ducduc still owns that clipboard change.

If you copy something new during that window, your new clipboard content takes priority. A clipboard manager that ignores the transient marker may still record the dictation. A slow target can also consume pasteboard data late; restoring a snapshot is a timer, not proof of insertion.

Clicking Copy is a deliberate lasting copy, so its content is not transient and is not automatically restored over. These limits matter if you dictate confidential text. The privacy/data-flow guide separates clipboard behavior from cloud cleanup.

Does SSH or tmux change the rule?

Ducduc pastes into the local terminal emulator. Where the shell runs does not change the Mac’s secure-input check. A remote sudo or SSH password interaction can affect this only through how the local terminal handles it.

If you need a Mac dictation input layer, try Ducduc with a non-sensitive phrase in Notes, then in your actual terminal. A useful feedback report includes the app and macOS versions, trigger key, whether recording started, and the copy-card message. Omit credentials and private transcript text.