Which Apps Have Accessibility Permission on Your Mac (and What That Means)

Accessibility is the deepest permission on macOS. It was originally built so screen readers and switch controls could drive the UI for users who couldn’t use a mouse. But over the years, every kind of automation tool — text expanders, window managers, clipboard managers, password autofillers — started requesting it because it’s the only way to read and control other apps’ interfaces. If you’ve ever used a Mac for more than a few months, you’ve probably granted Accessibility to half a dozen apps and forgotten about it.

Here’s what that toggle actually does, why it matters, and how to clean up the list.

What Accessibility permission grants

When an app has Accessibility on, it can:

• Read the contents of other apps’ windows (text fields, menu items, button labels)
• Send keystrokes and mouse clicks to other apps
• Move, resize, and position windows
• Read clipboard contents (in some workflows)
• Trigger menu items and toolbar buttons in any other app

It does not let an app:

• Read files directly from disk
• Use your camera, mic, or photos library
• Access network traffic

The reason this permission is sensitive is the keystroke part. An app with Accessibility on can simulate typing — including typing into password fields. It can also read what’s in those fields if the field doesn’t explicitly mark itself as secure. Most do, but not all.

The legitimate uses

These apps genuinely need Accessibility to work:

• Window managers — Rectangle, Magnet, Moom, Raycast (window features), Loop, Yabai
• Text expanders — TextExpander, Espanso, aText
• Clipboard managers — Maccy, Paste, Alfred clipboard, Raycast clipboard history
• Launchers and automation tools — Alfred, Raycast, BetterTouchTool, Hammerspoon, Keyboard Maestro
• Screen readers — VoiceOver helpers (Apple’s own), some third-party reading aids
• Remote desktop — TeamViewer, AnyDesk, Chrome Remote Desktop need it to send input
• Password managers — 1Password, Bitwarden, Dashlane (for autofill outside browsers)

If you use any of these, the toggle being on is correct.

Finding the list

Open System Settings → Privacy & Security → Accessibility. The list is sorted alphabetically. Each entry has a toggle.

Anything not in the categories above deserves a closer look. A music player, a video editor, a graphics tool, a chat app — none of those need Accessibility under normal use. The exception is meeting tools that grant click-through for screen sharing (Zoom sometimes asks; Teams does on some versions).

Audit your permissions in one screenSweep shows every app’s permissions on one page. Revoke in one click. Get Sweep free →

Why the list keeps growing

Three reasons:

1. Trials you forgot. You tried a window manager for an afternoon and switched to another. The first one’s toggle is still on.
2. Updates that added the request. An app you’ve used for years released a feature that now needs Accessibility. The new prompt got dismissed in a hurry.
3. Uninstalls that didn’t fully clean up. Drag-to-Trash leaves the entry in the privacy list. The toggle stays on for an app that no longer exists.

The third one is the weirdest. Open Accessibility on most multi-year-old Macs and you’ll find at least one entry where the icon is greyed out and the path points to something that no longer exists. macOS won’t always remove these automatically.

How to revoke

Toggle off the entries you don’t want. macOS may prompt the app to quit. For ghost entries (apps that no longer exist), select the row and press the minus button at the bottom of the list. You may need to authenticate with Touch ID or your password.

If you get an error like “the item couldn’t be removed because it’s in use,” check Activity Monitor for a still-running process and quit it.

What’s the actual risk?

Accessibility permission isn’t a vulnerability on its own. The apps you grant it to are still subject to the same code-signing, notarization, and sandboxing rules as anything else on macOS. Apple verifies the developer’s identity, scans for known issues, and rejects unsigned binaries unless you’ve explicitly bypassed Gatekeeper.

The risk is more pedestrian:

• An app you trusted at one point may not be the same app anymore — developers sell projects, change hands, or get acquired.
• A malicious update could go through if signed correctly, though Apple’s notarization makes this harder than it used to be.
• A perfectly legitimate app could have a bug that exposes data to other processes.

The mitigation is also pedestrian: only grant Accessibility when you actively need it, and audit the list every few months.

See what your apps actually accessSweep surfaces every camera, mic, file, and location permission on your Mac. Download Sweep free →

How macOS protects password fields

When an app draws a password field, macOS marks the field as “secure input.” Apps with Accessibility can’t read the contents of secure input fields, even though they can read everything else around them. This is what stops a clipboard manager from accidentally capturing your password.

The protection is real but imperfect. If a developer forgets to mark a field as secure, anything with Accessibility can read it. Most browsers, system dialogs, and password managers handle this correctly. Older third-party apps sometimes don’t. That’s the failure mode worth knowing about — it’s why entering passwords into custom forms in obscure apps is a worse idea than entering them into Safari.

Sandbox containers and Accessibility

Apps from the Mac App Store are sandboxed by default. Their files live in ~/Library/Containers/<bundle-id>/Data/. Even with Accessibility on, a sandboxed app has limited reach into other parts of the filesystem.

Apps distributed outside the App Store can request the sandbox entitlement but aren’t required to. A non-sandboxed app with Accessibility has more reach by default. The path most window managers take is non-sandboxed, because the App Store sandbox is too restrictive for what they need to do.

You can check if an app is sandboxed by running:

codesign -dvvv --entitlements - /Applications/AppName.app 2>&1 | grep sandbox

If you see com.apple.security.app-sandbox returning [Bool] true, it’s sandboxed.

The “automation” overlap

Accessibility and Automation are different permissions. Automation (in Privacy & Security → Automation) is what lets one app send AppleScript or scripting events to another. Accessibility is what lets an app simulate clicks and keystrokes.

Many automation tools use both. Keyboard Maestro, for example, can drive an app via Accessibility (clicking buttons) or via Automation (sending scripting events). The two get conflated, but they’re separately revocable.

Audit walkthrough

Spend ten minutes once a quarter:

1. Open System Settings → Privacy & Security → Accessibility
2. For every entry: ask “do I actively use this app’s automation features?”
3. Toggle off anything where the answer is no
4. Click the minus button on any greyed-out ghost entries
5. While you’re there, check Input Monitoring, Screen Recording, and Automation in the same panel — these often go together

This catches roughly 80% of “permission sprawl” problems. The remaining 20% — Files & Folders, Full Disk Access, Camera, Microphone — live in different sub-panels.

Skip System Settings — see it all at onceSweep collapses the privacy maze into one screen. Try Sweep free →

Accessibility is the most powerful single toggle in macOS privacy. Most users never look at the list after the day they granted it. Five minutes of cleanup makes a real difference, and the apps you actually use will reprompt if they need it back.