macOS Accessibility Permission: What It Grants and How to Audit It

A Mac app asks for "Accessibility" access, macOS sends you to System Settings, and you have to decide with no real information. The name does not help: this permission has nothing to do with the accessibility features you turn on for yourself. It is the permission that lets one app read and control other apps.

It is the most powerful permission a normal Mac app can hold, and plenty of ordinary apps genuinely need it. This guide covers what it grants, how it differs from the permissions it is often confused with, how to audit what you have already given away, and how to decide before you grant it again.

What the permission actually grants

An app with Accessibility access can, across your whole Mac:

• Read the interface of other apps through the macOS Accessibility API: window titles, button labels, and the text inside text fields, including text you have not saved or sent.
• Send input to other apps, synthesising keystrokes, clicks, and scrolls, as though you had typed or clicked them.
• Watch keyboard events system-wide, which is the same capability a keylogger needs.

It is granted per app, but it is not scoped to one target app or one window. Once an app is trusted, it can read from and type into anything on screen.

What it does not grant, despite the assumption:

• It does not give access to your files. That is Full Disk Access.
• It does not capture what is on screen as an image. That is Screen Recording.
• It does not give access to the camera, the microphone, your contacts, or your location. Each of those is its own permission.

The honest summary: Accessibility gives an app the ability to do anything you could do with a keyboard and mouse, and to see the text of what you are working on. Whether that is fine depends entirely on the app.

The five permissions people mix up

All five live in System Settings → Privacy & Security, and they grant different things:

• Accessibility: read other apps' interfaces and send input to them. Window managers, text tools, automation apps.
• Input Monitoring: receive keyboard and mouse events globally, without the ability to control other apps. Used by key remappers and some hotkey tools.
• Screen Recording: capture the pixels on screen, including windows belonging to other apps. Used by screenshot tools, video calls, and screen sharing.
• Automation: control one named app through Apple Events. Granted per pair, so "Shortcuts wants to control Mail" is a separate decision from "Shortcuts wants to control Finder".
• Full Disk Access: read protected locations such as Mail, Messages, Safari data, Time Machine backups, and other apps' containers.

Automation is the narrowest of the five, because it names both sides. Accessibility and Full Disk Access are the broadest.

Which apps legitimately need it

These categories cannot do their core job without it:

• Window managers (Rectangle, Magnet, Amethyst) move and resize other apps' windows.
• Clipboard managers and text expanders insert text into whatever app has focus.
• Writing and grammar tools read the text field you are typing in and put a replacement back.
• Automation tools (Keyboard Maestro, Hammerspoon, BetterTouchTool, Raycast, Alfred) exist to drive other apps.
• Remote support and screen sharing need the remote side to click things.
• Assistive technology: screen readers, switch control, voice control.

Categories that should make you stop and ask why:

• A note-taking app, a wallpaper app, a photo editor, a "system cleaner", or a free VPN that asks for Accessibility during setup.
• Any app that asks for it before you have used a single feature, and cannot tell you which feature needs it.
• Any app where the answer to "what does this permission do here?" is not in its documentation.

How to audit what you have already granted

Do this once. Most people find at least one entry they no longer recognise.

1. Open System Settings → Privacy & Security → Accessibility.
2. Read the list. Every app with the toggle on can read and control everything on your Mac.
3. Turn off anything you do not recognise, no longer use, or cannot justify. Most apps notice immediately; some need to be quit and reopened.
4. Use the − button to remove an entry entirely rather than only switching it off. The app will have to ask again.
5. Repeat for Screen Recording, Input Monitoring, and Full Disk Access in the same panel.

To revoke from the command line, tccutil reset Accessibility com.example.appbundleid clears one app's decision and makes macOS ask again next time. Leaving off the bundle identifier resets every app, which is a blunt but effective way to start over.

The permission decisions themselves are stored in a system database that is protected by System Integrity Protection. You cannot usefully edit it by hand, and you should not try. Use System Settings or tccutil.

How to decide before you say yes

Five checks, in order of how much they tell you:

1. Does the core feature need it? A window manager does. A wallpaper app does not. If you cannot name the feature, do not grant it.
2. Is the app notarised and signed? Run spctl -a -vv /Applications/TheApp.app in Terminal. You want accepted and source=Notarized Developer ID. Notarisation means Apple scanned the build for known malware and the developer's identity is on record. That does not make the app trustworthy, only that someone identifiable is accountable for it.
3. Is the developer identifiable? A real company or a named person, a support address that works, and a privacy policy that describes this specific app rather than a generic template.
4. Does the app say what it reads and where that goes? An app that reads your text should tell you whether that text leaves your machine, where it is sent, and whether it is stored.
5. Can you grant it late? Install first, use the app without the permission, and grant it only when you hit the feature that needs it. Many apps ask on first launch out of convenience, not necessity.

You can also limit the blast radius: grant the permission, use the app for a week, then open the Accessibility list again and remove anything that turned out not to matter.

When an app is in the list but still does not work

This is the most common Accessibility problem, and it is almost always a stale entry rather than a bug in the app. macOS ties the permission to the app's signature, so replacing or moving the app can leave an entry that looks correct and does nothing.

Fix it in this order:

1. Quit the app.
2. In System Settings → Privacy & Security → Accessibility, select the app and remove it with −. Removing is the step that matters; toggling off and on again usually is not enough.
3. Reopen the app and let it ask again, or add it with + from the Applications folder.
4. If the app appears twice in the list, remove both entries and add it once.
5. If it still fails, run tccutil reset Accessibility com.example.appbundleid, then relaunch.

Apps that were moved out of /Applications, restored from a backup, or updated outside the App Store are the usual causes.

What BlinkWrite uses these permissions for

BlinkWrite is one of the apps that asks, so here is the specific answer rather than a general one.

Accessibility is how it reads the text around your cursor, meaning the draft you are writing and the conversation or document around it, and how it puts a suggestion into your text after you press Tab. Without it there is nothing to read and no way to apply a suggestion.

Screen Recording is how it reads on-screen text in apps that do not publish their text through the Accessibility API. The screen images are used to read that text and stay on your Mac.

What happens to the text: personal information is detected and masked on your Mac before anything is sent, and the masking code is open source. The masked draft and context pass through BlinkWrite to an external LLM provider over encrypted connections. Production API response storage is disabled, but provider abuse-monitoring retention applies. BlinkWrite does not use production writing for training. Privacy & security sets out exactly what is sent and what stays local.

You can pause BlinkWrite for one app or for the whole system from the menu bar at any time, and Settings → General → Uninstall BlinkWrite removes the app together with its Accessibility and Screen Recording permissions, its local model, and your settings. The setup guide covers granting the permissions, and troubleshooting covers the stale-entry case above.

Common questions

Is granting Accessibility permission safe?

The permission is not safe or unsafe by itself. It is broad, so the risk is entirely about which app holds it. Granting it to a notarised app from an identifiable developer whose main feature requires it is a normal thing to do. Granting it to an app that cannot explain why it needs it is not.

Can an app with Accessibility access read my passwords?

It can read text in fields it is allowed to inspect and it can observe keyboard events, so treat it as capable of seeing what you type. Password managers mark their own fields as secure, and macOS hides secure text entry from event taps, but the sensible assumption is that this permission covers anything you type in a normal field.

Does the permission let an app watch me when it is closed?

No. The app has to be running to use it. A quit app has no access, and an app you have paused or removed from the list has none either.

Why does macOS keep asking after an update?

Because the permission is bound to the app's code signature. A rebuilt or re-signed app can look like a different app to macOS. Remove the old entry with − and grant it once to the new version.

Where do I check what I have granted?

System Settings → Privacy & Security, then Accessibility, Screen Recording, Input Monitoring, Automation, and Full Disk Access in turn. It is worth doing twice a year.