Why does my hold-to-talk hotkey do nothing when Terminal is focused?

The most common cause is Secure Keyboard Entry being enabled in your terminal. When it is on, macOS enters Secure Event Input and stops delivering key events to third-party event taps, so a tool listening for a held hotkey receives nothing — silently, with no error. Terminal.app has the toggle in its Terminal menu; iTerm2 has it under Preferences, General.

Does Secure Keyboard Entry affect every voice input tool?

Yes, for any tool that works by installing a CGEvent tap to watch for a hotkey. This is an OS-level restriction, not a bug in a particular app, and it applies to Voice Doggo as well. Tools that do not read keystrokes — for example a menu bar button you click, or transcribing in another app and pasting — are unaffected.

How do I tell whether Secure Event Input is currently active?

Run `ioreg -l -w 0 | grep SecureInput` in a terminal. If it prints matching entries, some process currently has Secure Event Input active. The `kCGSSessionSecureInputPID` value in the output is the PID of the process holding it, which you can look up with `ps -p `. Behavior and output formatting vary between macOS versions, so treat this as a strong hint rather than a definitive readout.

Why does my dictation tool produce empty results with no error?

Check your system input volume first. In System Settings, Sound, Input, if the input volume slider is near zero the microphone returns near-silence, and most recognizers return an empty string rather than an error. Speak and watch the input level meter move before investigating anything else.

Do I grant microphone permission to the terminal or to the voice tool?

To the voice tool, not the terminal. These are separate TCC grants per application. The terminal only needs microphone access if the recognition process is launched from inside it, in which case macOS may attribute the request to the terminal as the parent process instead.

Is it safe to turn Secure Keyboard Entry off?

It is a tradeoff. Secure Keyboard Entry exists to prevent other processes from reading what you type in a terminal. If you routinely type passwords there, leaving it on and using a transcribe-then-paste workflow is the safer choice.

Mac Dictation Not Working in Terminal — Causes, Ordered by Likelihood

Updated 2026-10-19

If you are here, you have probably already tried killall corespeechd, reset the microphone permission with tccutil, and restarted. Those are the fixes every generic article leads with, and they rarely help in a terminal — because the thing that breaks dictation in Terminal and iTerm2 is usually not the thing that breaks it in Notes or Safari.

This page is ordered by actual cause, most likely first. For each one: how to confirm it is your problem, and what to do about it.

For background on why terminals are structurally different from normal text fields, see voice input in the macOS terminal.

1. Secure Keyboard Entry is on

This is the cause almost nobody documents, and it is the one that matches the symptom "I hold the key and absolutely nothing happens."

Terminal.app has a menu item called Secure Keyboard Entry (under the Terminal menu). iTerm2 has the same setting under Preferences → General. When it is enabled, macOS enters a state called Secure Event Input, and the window server stops delivering key events to third-party event taps.

Every hold-to-talk voice tool works by installing an event tap — a CGEvent tap that watches for your hotkey being pressed and released. Under Secure Event Input, that tap receives nothing while the protected window has focus. There is no error, no permission prompt, no log line. You hold the key, and the tool simply never learns that you held it.

How to confirm:

Open the terminal's menu and look at whether Secure Keyboard Entry is checked.
Or, from any terminal, run:

ioreg -l -w 0 | grep SecureInput

If that prints matching entries, something currently holds Secure Event Input. The kCGSSessionSecureInputPID value in the output is the PID holding it; run ps -p <pid> to see which app that is. The exact field names and output format have shifted across macOS releases, so treat this as a strong hint rather than a guarantee.

Decisive test: click into a plain TextEdit window — not the terminal — and try the same hotkey. If it works there and not in the terminal, you have found it.

How to fix: uncheck the setting, then try again. You do not need to restart the terminal; focus the window again and the tap starts receiving events.

Two things worth knowing. First, Secure Event Input is a session state, not a per-window one — a different app holding it (some password managers and remote desktop clients do, and a crashed app can occasionally leave it stuck) will block your hotkey everywhere until that process releases it or exits. Second, this is an OS-level restriction, not an app bug: it affects every event-tap-based tool equally, including Voice Doggo, which currently does not detect the state or warn you about it. If you hold right Option in a terminal with Secure Keyboard Entry on, nothing will happen, and the app will not tell you why.

The tradeoff is real. Secure Keyboard Entry exists specifically to stop other processes from reading keystrokes in a window where you might type a password or a private key passphrase. If you regularly do that in your terminal, the better answer is to leave it on and dictate somewhere else, then paste. Decide deliberately rather than by default.

2. Voice Control and Dictation are fighting

These are two different macOS features and people conflate them constantly.

Dictation (System Settings → Keyboard → Dictation) transcribes speech into the focused text field. Voice Control (System Settings → Accessibility → Voice Control) is a full hands-free interface: it interprets what you say as commands — "click Save", "scroll down" — and only enters text in its dictation mode.

With Voice Control enabled, spoken input can be captured as a command instead of reaching the text layer, and the two features compete for the microphone. Symptoms are inconsistent: text appears sometimes, or appears as a transcribed command name, or the recognition indicator shows but nothing lands.

How to confirm: check whether Voice Control is on in Accessibility settings. If you did not turn it on deliberately, it may have been enabled by an accessibility shortcut (triple-press of the side or Touch ID button on some configurations).

How to fix: turn one of them off. If you want command-and-control, keep Voice Control and drop system Dictation. If you want text, the reverse. Running both is a recipe for intermittent, hard-to-reproduce failures.

3. Microphone permission is on the wrong app

macOS grants microphone access per application, through TCC. The grant your voice tool needs is its own — not your terminal's.

The confusing case is when the recognition process is launched from a shell. If you start a dictation script from inside iTerm2, macOS may attribute the microphone request to iTerm2 as the parent process, and prompt for (or silently deny) that app instead of the one you were thinking of. A packaged app launched from Finder asks for its own grant; the same binary run from a terminal may not.

How to confirm: System Settings → Privacy & Security → Microphone. Look for both your voice tool and your terminal in the list and note which are enabled. If your tool is not listed at all, it has never successfully requested access — which usually means it never got as far as trying.

How to fix: enable the toggle for the tool itself. If the entry is missing, quit the app, run tccutil reset Microphone <bundle-id>, and launch it again so the prompt reappears. Reset the specific bundle ID — a blanket tccutil reset Microphone revokes every app on the machine.

4. Input volume is near zero

This one is unglamorous and catches people repeatedly: recognition returns an empty string, no error, no crash, and you go hunting through permissions for an hour.

If the system input volume is at or near zero, the microphone delivers near-silence. Recognizers do not treat silence as a failure — they treat it as "nothing was said" and return an empty result. The tool reports success with no text, which looks exactly like a broken model.

How to confirm: System Settings → Sound → Input. Select your microphone and speak normally while watching the input level meter. If the bars barely move, or the Input volume slider sits near the left end, that is your cause.

How to fix: raise the input volume and re-test. Also confirm the correct input device is selected — plugging in headphones, joining a video call, or connecting a Bluetooth device can switch the default input to something that is not pointed at your face. Some conferencing apps change the input volume while running and do not restore it afterward.

5. Accessibility or Input Monitoring is missing, or stale after an update

Tools that inject text as keystrokes need two grants under System Settings → Privacy & Security:

Accessibility — to post keyboard events on your behalf
Input Monitoring — to observe the hotkey you are holding

Missing either one produces a partial failure that is easy to misread. Without Input Monitoring, the hotkey does nothing (which looks exactly like the Secure Keyboard Entry symptom). Without Accessibility, recognition runs fine but no text appears in the window.

The subtler version: the grant can go stale after the app updates. TCC ties the grant to the app's code signature and location. After a version bump — especially if the app was replaced in place, moved between /Applications and ~/Applications, or restored from a backup — the row can still appear toggled on in System Settings while the system no longer honors it. The UI says yes; the behavior says no.

How to confirm: toggle the entry off and back on, then quit and relaunch the app. If that fixes it, the grant was stale.

How to fix: remove the entry entirely with the − button, relaunch the app, and let it request access again so a fresh grant is written. Dragging the app into the list by hand sometimes registers the wrong path; letting the app ask is more reliable.

6. The generic fixes, last

These are what every other page leads with. They are worth trying — after the five above, not before:

killall corespeechd — restarts the system speech daemon. Relevant if system Dictation stopped working everywhere, not just in your terminal.
Toggle Dictation off and on in System Settings → Keyboard, which re-registers the service.
Restart. This genuinely helps with a stuck Secure Event Input state, which is why "restarting fixed it" shows up so often in threads about this problem — the reboot cleared cause #1 without anyone realizing that was the cause.
Check for a pending macOS update. Dictation-related regressions have shipped and been fixed in point releases before.

If none of it works

Fall back to the workflow that does not depend on event taps at all: dictate into a plain text field in another app, then paste into the terminal. Clumsy, but it sidesteps Secure Keyboard Entry, Accessibility grants, and injection entirely — and if you keep Secure Keyboard Entry on for good reason, it is the only approach that is both safe and reliable.

One habit worth keeping regardless of which tool you settle on: separate "finish speaking" from "press Return". Recognition makes mistakes, and a command in a terminal cannot be taken back once it runs.