What the Accessibility permission actually allows on macOS
The dialog says an app wants to control your computer. That is technically true and badly misleading. Here is the real scope.
Somewhere in the first ten minutes of using a new Mac utility you will meet a dialog saying the app wants permission to control your computer. It is worded to make you stop, which is correct, and it is vague enough that most people either refuse everything or approve everything.
Both are wrong. Accessibility is a genuinely powerful grant with a specific, knowable scope.
What it grants
The Accessibility API exists so that assistive technology — screen readers, switch control, dictation, automation — can inspect and drive the interface of other applications. An app holding this permission can:
- Enumerate open windows and read their position, size and title
- Move and resize those windows
- Read the accessibility tree of other apps: the roles, labels and values of controls
- Send synthetic interface events, effectively driving another app's UI
The last two are the reason for caution. An application with this grant could, in principle, read the visible text of controls in another app or operate its interface programmatically.
What it does not grant
| Capability | Permission that actually controls it |
|---|---|
| Reading your documents | Full Disk Access, plus per-folder prompts |
| Seeing your screen | Screen Recording, with its own indicator |
| Logging everything you type | Input Monitoring |
| Using the camera or microphone | Camera, Microphone |
| Talking to the network | No permission gates this at all — which is the point of outbound filtering |
That last row is worth sitting with. macOS gates screen, disk, camera and input behind explicit consent. It does not gate network access. Any application can talk to any server without asking, which is the entire reason this site exists.
Which apps legitimately need it
| Category | Needs it? | Why |
|---|---|---|
| Window managers | Yes | Moving another app's window is impossible without it |
| Text expanders, clipboard tools | Yes | They insert text into other apps |
| Launchers and automation | Yes | They drive other applications by design |
| Screenshot and annotation tools | Sometimes | Often want Screen Recording instead; be suspicious if they ask for both |
| Conferencing apps | Only for remote control | Revoke it if you never let others drive your Mac |
| Media players, note apps, browsers | No | Treat a request as a red flag |
A worked example: window managers
Window managers are the clearest case of a category that cannot function without the grant, and therefore a useful test of how to evaluate one.
Take Rectangle, the common default on macOS. It needs Accessibility because there is no other way to set another application's window frame. The questions worth asking are the ones you would ask of anything in this position:
- Can you read the source? It is open source under an MIT licence, so the question "does it make network connections" is answerable by reading rather than trusting.
- Can you verify the binary? It is signed and notarised;
codesign -dv --verbose=4andspctl -a -vvconfirm the shipped app matches the developer identity. - Does its behaviour match its description? This is where your own outbound monitor earns its place. Point it at the app and watch. An update check is expected; anything else is not.
- Does it hold only the permissions it needs? It should appear in Accessibility and nowhere else. If a window manager turns up in Screen Recording or Full Disk Access, that is a question worth asking loudly.
That four-step test works for any utility in any category. Applied to a window manager, it passes cleanly, which is why the category is a reasonable place to spend the grant.
Popular free Mac utilities are heavily impersonated. Mirror sites and download aggregators repackage legitimate apps with an installer carrying something else. Install from the developer's own site, the project's releases page, or a package manager — never from a search result that merely looks official. More on this in vetting free Mac utilities.
Auditing the list
System Settings → Privacy & Security → Accessibility. Quarterly, ten minutes:
- Remove anything you no longer use. Grants outlive the software that requested them.
- Remove anything you cannot explain. If you do not remember why it is there, it does not need to be there.
- Check for duplicates from old versions, which is also the usual cause of a grant that appears enabled but does not work.
- Cross-reference against Screen Recording and Input Monitoring. An app in all three is doing something that deserves an explanation.
On managed Macs
Work machines often control this list by policy, and an MDM profile can pre-approve specific applications. If a utility you need is blocked, the route is to ask your administrators rather than to look for a workaround — the workarounds are worse than the inconvenience.
Frequently asked questions
Is it safe to give an app Accessibility permission?
It depends entirely on the app. The permission allows reading and driving other applications' interfaces, so grant it only to software whose provenance you have verified and whose category genuinely requires it.
Can an app with Accessibility permission see my screen?
No. Screen capture requires the separate Screen Recording permission, which has its own system indicator.
Why does a window manager need Accessibility access?
macOS only allows an application to read and set another application's window position and size through the Accessibility API. Without the grant, window shortcuts do nothing.
Does macOS ask permission before an app uses the network?
No. Unlike disk, camera, microphone and screen access, network access is not gated by a permission prompt. That gap is what outbound firewalls address.