Mac dictation not working? Work through this checklist

14 August 2026 · 3 min read · Muteeb Mehraj

Dictation on macOS fails quietly. No error, no dialogue, nothing in a log you can find. Here is the order to check things in, arranged so the most common causes come first.

1. The Globe key is being eaten by macOS

If your trigger is Fn and nothing happens at all, check this before anything else. It is the single most common cause and it has nothing to do with the app.

Go to System Settings, Keyboard, and find Press 🌐 key to. If it is set to Show Emoji & Symbols or Start Dictation, macOS intercepts the keystroke before any application can observe it. Set it to Do Nothing or Change Input Source.

Nothing an app does can work around this. The event never reaches it.

2. Accessibility is granted to the wrong copy

Global hotkeys need the Accessibility permission, and macOS ties that permission to a specific copy of an app, not to its name.

The failure looks absurd: the checkbox is on, and the app still cannot see your keys. It happens when you have more than one copy around, typically the one in Applications plus one still sitting in a mounted disk image. Permission attaches to whichever one was added, and the other stays denied.

Fix it by removing every stale copy first:

ls -d /Volumes/*/*.app 2>/dev/null      # anything running from a DMG?
hdiutil detach /Volumes/YourApp -force  # eject it

Then in System Settings, Privacy & Security, Accessibility, select each existing entry and remove it with the minus button. Add the copy in Applications with plus, and switch it on. Toggling an existing stale entry does not fix it; it has to be removed and re-added.

3. Nothing is granted because a prompt got lost

Permission prompts can be dropped if several are requested at once, or if one appears behind another window. If you never saw a prompt, you may never have answered one.

Check the current state rather than trusting memory. Both Microphone and Accessibility panes are in Privacy & Security. If the app is not listed at all, it never successfully asked.

Reset and let it ask again:

tccutil reset Accessibility com.example.yourapp
tccutil reset Microphone    com.example.yourapp

4. The wrong microphone is selected

If recording works but transcripts come back empty, the app is probably capturing silence.

This is common with audio interfaces. A device may present several input channels while your microphone is only on one of them. An app that mixes all channels down, or picks the wrong one, records near-silence and hands that to the speech model, which correctly returns nothing.

Pick your input device explicitly rather than relying on the system default, and if the app has a microphone test, use it. A level meter that never moves while you talk is the whole diagnosis.

5. You are running the binary from a terminal

Worth knowing because it is counterintuitive and it wastes hours.

If you launch an app's executable directly from a shell to see its log output, macOS attributes permission requests to the responsible process, which becomes your terminal, not the app. Your grant to the app is ignored, and hotkeys stop working, while everything looks correctly configured.

Launch normally with open -a. If you genuinely need the direct-run output, you must also grant Accessibility to Terminal itself.

6. It is working, and the model is still loading

On first run, apps that transcribe locally have to compile their speech model for the Neural Engine. That takes tens of seconds to a few minutes, once, and until it finishes nothing will transcribe.

There is no error because there is no error. If you are within the first couple of minutes of a first launch, wait before debugging anything.

If none of these are it

Distinguish between the audio being wrong and the decode being wrong, because they lead to opposite fixes. If your app shows recording duration alongside the transcript, compare the two: a normal speaking rate is roughly 120 to 150 words per minute. Ninety seconds of audio producing 170 words is a complete transcript. Ninety seconds producing 20 words is not, and that points at decoding rather than capture.

If the duration itself is far shorter than you spoke, the recording stopped early and the speech model is not involved at all.