macOS permissions for dictation
Microphone, Accessibility and Input Monitoring: what each is for, why macOS asks separately, and what to do when one looks granted but nothing happens.
A dictation app on macOS needs three separate permissions, and they are separate because they allow three genuinely different things: hearing you, putting text into another app’s window, and noticing a key you pressed while another app was in front.
The trouble is that they fail quietly. A permission can be denied and produce silence rather than an error, listed as granted while every call behind it fails, or genuinely granted and still unusable until the app has been restarted. Those look identical from the outside, which is why granting something and seeing nothing happen is such a common way to get stuck.
Microphone
Without this there is no audio and no recording can start. It is also the one permission an app can genuinely prompt for from inside itself, which Voicecape does at the moment you press Allow rather than on launch. Onboarding states the reason plainly: the microphone is needed to hear you, and the audio is processed on the device rather than uploaded.
What matters here is the difference between never asked and denied. Before you have answered, the in-app prompt works. Once you have said no, macOS will not show it again for that app, so a button offering to ask again would do nothing at all, and from that point System Settings is the only route.
Accessibility, or typing into other apps
Accessibility lets one app read and modify another app’s interface. For dictation it is what makes text appear at your cursor instead of leaving you to paste it, and it is also what lets the app see what kind of field you are focused on.
No app can prompt for this one. The system call that looks like a request only opens the Accessibility settings window, and a human has to move the toggle. That holds whether you have never been asked or previously refused, so both states lead to the same place, and any interface offering an Allow button for Accessibility is offering a button that cannot work.
Not having it has a quieter second effect. Voicecape refuses to record while a password field is focused, and that guard is deliberately fail-closed: an unreadable focused element counts as secure. Without Accessibility trust the focused element cannot be read, so the guard fires and nothing records. The app is being correctly conservative, and what you experience is a shortcut that appears to do nothing.
Input Monitoring, or the shortcut key
A global shortcut, one that works while another app is in front, means watching key events system-wide, and macOS treats that as its own permission. This catches people out constantly: grant Accessibility alone and insertion starts working, so everything looks right, while the shortcut stays completely dead.
Unlike Accessibility, an app can ask for this one, and asking does something valuable beyond showing a prompt: the request registers the app in the Input Monitoring list automatically. Without it the app never appears there, and you would have to press the plus button and find it in your Applications folder by hand, which is where people abandon setup. The asked-once rule still applies, so after a refusal the prompt never returns.
The permission macOS reads only at launch
This is the trap worth knowing before you meet it. Input Monitoring is read when an app starts. Grant it while the app is already running and the system now records it as granted, the app can see that it is granted, and the event tap the shortcut depends on still will not come up.
Nothing is broken and there is nothing to diagnose. The app retries registering the shortcut whenever its window regains focus, since you may have just been in System Settings, and when that retry fails with both permissions present it says so outright: one restart and the shortcut is live, because macOS only reads this permission when an app starts. Setup continues from where it was.
If you take one thing from this article, take that one. After switching on Input Monitoring, quit and reopen the app before concluding the shortcut is broken.
Granted on the list, attached to a different copy
There is a stranger state, and macOS gives no error for it. The trust check returns true, the app sits in the Accessibility list with its checkbox on, and every accessibility call fails.
It happens when the entry refers to a different copy of the app than the one running: after the app has been moved, replaced by an update, re-signed, or launched from somewhere other than where the list expects. The permission is attached to the binary rather than the name, so macOS keeps answering yes while refusing the calls.
Calling that granted would put a green check beside a feature that can never work, and calling it denied would tell you to switch on something you already switched on. So it is its own state with its own instruction, and the action is labelled as fixing the permission rather than granting it: remove the entry and add it again. That fix is worth carrying to other apps too, since toggling the existing entry off and on does not clear it.
The exact path in System Settings
- Open System Settings from the Apple menu.
- Go to Privacy and Security in the sidebar.
- Microphone, Accessibility and Input Monitoring are three separate rows in that pane. Open each one you need and switch the app on there.
- If the app is not listed at all, use the plus button to add it from your Applications folder, or trigger the in-app request that registers it for you.
The app can open each pane directly, which is what the Open settings buttons in onboarding do. Those pane identifiers are exact strings and an unrecognised one silently opens nothing, so navigating by hand reaches the same place.
A diagnostic sequence for granted it and nothing happens
Work through these in order. Each rules out a category, and the later checks only make sense once the earlier ones are clear.
- Name the symptom precisely. The shortcut does nothing, or the shortcut works and no text arrives, or the text lands on your clipboard instead of in the window. Those are three different permissions, and treating them as one problem is what turns ten minutes into an afternoon.
- Switch back to the app after changing anything, since it re-reads the system and re-plans when its window regains focus. A stale green check usually means it has not looked yet.
- If you just switched on Input Monitoring, quit and reopen the app, because no amount of retrying inside a running app changes what was read at launch.
- If Accessibility is on and the app still says it cannot type into other apps, remove its entry from the Accessibility list and add it again. That is the different-copy case.
- If nothing records at all and the status mentions a password field, check what is actually focused. An unreadable focus counts as secure, which usually points at missing Accessibility rather than at a password box.
- On a managed or work Mac, check whether the row is greyed out. Where a device policy controls the setting, the app says the choice is locked by the device rather than pretending you can fix it.
What the app does not ask for
The macOS build asks for those three and nothing else. There is no screen recording request, no full disk access, and no contacts or files or calendar.
There is also nothing to download on first run. The speech model ships inside the app bundle, so setup is permissions and a shortcut rather than a progress bar, and the app works with the network off entirely. What does reach a server is itemised separately, and the broader question is in does dictation software send your voice to the cloud.
Why three switches rather than one
A single combined prompt would be more convenient, and it would also mean the app you allowed to hear you was simultaneously allowed to read every window on your screen and watch every key you press. The split is what makes each grant describable in one honest sentence.
Each maps to one visible capability. Microphone means the app can hear you. Accessibility means the transcript lands at your cursor rather than on your clipboard, which is the mechanism described in typing with your voice in any app. Input Monitoring means the key you press starts a dictation instead of doing nothing.