a small utility is asking to control your computer

why the accessibility permission was built for screen readers

the Accessibility API exists so assistive software can operate a Mac on someone's behalf. a screen reader has to describe any window in any app, find the buttons in it and press them — otherwise it is useless in software it has never seen.

there is no way to build that narrowly: an interface that can operate every app is, by construction, an interface that can operate every app. so a utility that moves your window or pastes into the app you were in asks for exactly what a screen reader asks for. there is one door.

that is why macOS refuses to let an app grant it to itself. no in-app prompt turns it on: you open System Settings → Privacy & Security → Accessibility and flip the switch yourself. the friction is the feature, tightened since Mavericks.

window management is the clearest case of a tool that cannot exist without it: window manager

what accessibility permission actually grants

• reading the interface of other apps: window titles, positions, sizes, the contents of controls.
• moving, resizing and raising windows the app does not own.
• posting synthetic keystrokes and clicks — that is, acting as if you had typed or clicked.

and by combination, reading text out of another app's fields. so: an app with this permission can do anything you could do at the keyboard, and see most of what you can see. not a reason to refuse it — a reason to grant it deliberately, to software you have reason to trust.

accessibility, input monitoring and screen recording are three different panels

what each panel says it does

these three get confused constantly, and the quickest way to keep them apart is the line macOS prints atop each panel. on 26.6.2: Accessibility says «allow the applications below to control your computer». Input Monitoring says «monitor input from your keyboard even while using other applications». the third says «record the content of your screen and audio» — and in the sidebar it is no longer «Screen Recording» but «Screen & System Audio Recording», which is why older instructions send you hunting for a panel that is gone.

Apple documents all three panels in the macOS user guide: allow accessibility apps to access your Mac

the third draws the most suspicion, because macOS re-asks for it periodically instead of granting it once — Apple policy since Sequoia, kept in macOS 26, not the app doing something new.

why that prompt keeps returning, and what it re-confirms: the screen recording permission that keeps coming back

one of the three asks for your admin password

the three are not guarded equally. Input Monitoring is flagged as requiring an administrator in the system's own service list, and Accessibility is not. an Accessibility switch you just flip; an Input Monitoring one stops and asks who you are. Apple treats global keystroke capture as the more dangerous of the two.

a second asymmetry runs the same way: for the other two panels macOS warns that a change lands only «until it is quit», and offers to quit the app. Accessibility carries no such warning — it is checked live, so revoking it bites while the app runs.

the third panel asked for honestly — reading text off screen needs the pixels, and only while you frame the area: text recognition

who already has it, and how to take it away

the panel that grants the permission is the only place that reports it, and its list is not of apps you said yes to. macOS words the empty state «applications that have requested access to control your computer will appear here»: everything that ever asked is there, on or off. a row switched off is a declined request doing its job, not a leftover to clean up.

revoking is that switch the other way: the app keeps running, whatever needed the permission goes quiet.

and it is the only place: no command prints the answer. the consent database is unreadable even to the account that owns it, so opening it from the Terminal returns «authorization denied».

clipboard tools are the other thing that goes quiet the moment it is revoked: clipboard history

Howard Oakley on how these controls work, and why there is no command line to them: eclecticlight.co, permissions, privacy and TCC

why the switch can be on and the permission still dead

this is the commonest way the panel misleads, and it follows from the mechanism. the grant belongs not to an app's name but to that copy of it — its signature and where it sits on disk. move the app from Downloads into Applications after granting, and the row still shows the old name with the switch on, while the app now running matches nothing and is refused.

so the fix is the minus button: remove the stale row, let the app ask again from where it now lives. it is also why permissions survive one update and not another: a new signing identity is a new app to this list.

Brett Terpstra on the same failure mode, from the developer's side: the fickle macOS accessibility permissions

why sandboxed Mac apps cannot use it

this explains a pattern you have probably noticed: a whole class of Mac utilities is missing from the App Store, or is there doing less. the reason is not review. Apple's own App Sandbox page lists «use of accessibility APIs in assistive apps» among the activities the system forbids a sandboxed app, and the same page calls the sandbox «a requirement for distributing your app on the App Store». note the wording: what the sandbox rules out is reaching into other apps, which is the whole job of a window manager. granting the permission by hand does not help — the block is in the sandbox, not the consent panel.

the forbidden activities, from Apple: developer.apple.com, protecting user data with App Sandbox

what each of the two distribution routes actually guarantees, and which is safer for what: the App Store version versus the one from the site

how to decide when a Mac app asks for it

• does the feature you want actually require it? a window manager cannot move windows without Accessibility. a note-taking app asking for it should be explaining itself.
• which permission is it, exactly? an app that wants Input Monitoring when you expected Accessibility is doing something other than what you assumed.
• does it ask when you first use the feature, or at launch for everything? the second pattern is worth being slow about, as is an unknown author with no source you can read.

hold an app to the opposite case too: some features that look like they need broad access do not, when a narrower system API exists. hop's colour picker uses macOS's own loupe, which hands back one colour, so it asks for no screen recording at all. an eyedropper that wants to record your display is asking for more than the job requires.

where it is needed, the answer to «what for» should be short and checkable. in hop's case Accessibility covers three things and stops: pasting into the app underneath, moving windows, the keyboard lock. screen recording is asked by text recognition, screenshots and the loupe and blur on the drawing layer.

the picker, and what it does with the colours once it has them: color picker

and the other side of that permission — pasting back into whatever you were in: find something you copied earlier

frequently asked questions

is it safe to give an app accessibility permission?

it depends entirely on the app. the permission itself is broad — reading other apps' interfaces and sending input on your behalf — so the question is whether you trust the software, not whether the permission is dangerous in the abstract.

why can't the app just turn it on itself?

macOS deliberately requires a manual switch in System Settings. an app can open the panel for you and explain what it needs, but it cannot grant itself the permission.

what is the difference between accessibility and input monitoring?

Accessibility lets an app read and operate other apps' interfaces and send synthetic input. Input Monitoring lets it observe your keystrokes globally, and unlike Accessibility it asks for an administrator password before you can switch it on.

how do i see which apps have accessibility permission?

System Settings → Privacy & Security → Accessibility lists every app that has ever requested it, switched on or off. there is no command that prints the same answer — the consent database cannot be read directly, even by your own account.

can i take the permission away later?

yes, in the same panel. the app keeps running and the features that needed it stop working. unlike screen recording and input monitoring, Accessibility is checked live, so you do not have to quit the app for the change to land.

i turned the switch on and the app still says it has no permission. why?

the grant is tied to that copy of the app — its signature and its location — not to its name. if the app moved or was replaced, the row in the panel points at the old copy. remove the row with the minus button and let the app ask again.

why do so many Mac utilities avoid the App Store?

the sandbox, which the App Store requires in almost every case, forbids reaching into other apps to control them — Apple lists «use of accessibility APIs in assistive apps» among the activities it makes impossible. a window manager, a text expander or a hotkey tool cannot be sandboxed and still function, so they are distributed from their own sites instead.