Last updated: May 2026, tested on a 14″ M3 Pro MacBook Pro (macOS Sequoia v15.1) and a 16″ Intel i7 10th-gen MacBook Pro (macOS Sonoma v14.6).
I sat staring at “Stopped.” for 40 minutes. The auto clicker was open. The window was right there. I’d clicked Start. Nothing happened. No error message, no warning, no click. The UI just sat there with the word Stopped frozen in the corner like the app had never woken up at all during those 40 minutes. I was running 15 clicks per second on my M3 Pro and zero of them reached the cursor. That’s the moment I learned macOS doesn’t tell you when an app lacks Accessibility permission. It just silently refuses to send synthetic mouse events and lets you flail.
If you’re here because your auto clicker is doing exactly that, you don’t need a thousand-word essay on macOS security architecture. You need three minutes of clicks. I’ll walk you through the grant flow, the Sequoia-specific extra step, and the half-dozen edge cases where the toggle goes greyed out or quietly wipes itself. Tested in the past two weeks on Sequoia v15.0, v15.1, Sonoma v14.6, and Ventura v13.x. Real screenshots from my own desk, real version numbers, no marketing.
TL;DR, the 60-second version
If you came here in a hurry: open System Settings, click Privacy & Security in the sidebar, scroll down and click Accessibility, click the + button, navigate into /Applications, pick Autoclick.app (or whatever auto clicker you installed), and confirm with your password. The toggle next to the app should switch on automatically. Quit the auto clicker, relaunch it, and Start now actually fires events. Done. The rest of this guide is for when that doesn’t work.
Why macOS gates auto clickers behind Accessibility in the first place
I’ll keep this short because it’s context, not a fix. macOS treats synthetic mouse and keyboard events as a security-relevant capability. Any app that wants to send a click your hand didn’t trigger has to be explicitly authorized, because the same API powers screen readers, accessibility tools for users with motor disabilities, and remote-control utilities. Apple groups all of these under the umbrella permission called Accessibility. That permission is gated behind System Settings and requires your password to grant. So an auto clicker without Accessibility permission is technically running, but its click events get dropped at the OS layer before they reach the cursor.
This is why your auto clicker can look like it’s working (“Started, clicking now”) while nothing happens on screen. The app sent the click, macOS swallowed it. Granting the permission is a one-time fix per app per macOS install, with a few annoying exceptions covered later in the post-update wipe section.
Step-by-step, granting Accessibility on macOS Sonoma and Sequoia
I’ll be specific because the exact menu names changed between Ventura, Sonoma, and Sequoia. The flow is the same in spirit, but the labels shifted.
- Open System Settings (the gear icon, formerly System Preferences before Ventura). Apple menu (top-left) , System Settings is the fastest path.
- In the left sidebar, click Privacy & Security. On Sequoia v15.1 it’s about a third of the way down, between Spotlight and Desktop & Dock.
- Scroll the right pane. You’ll see a list of permission categories: Location Services, Contacts, Calendars, Reminders, etc. Click Accessibility.
- The Accessibility pane shows every app you’ve previously authorized (or denied). At the bottom there’s a + button. Click it.
- A file picker opens. Use it to navigate into
/Applications. FindAutoclick.app. Click Open. - macOS will prompt for your password (Touch ID or typed). Confirm. The auto clicker now appears in the list with the toggle on.
- Quit Autoclick fully (Cmd+Q, or right-click the dock icon and choose Quit). Relaunch it. The Start button now actually sends click events.
I keep mentioning the quit-and-relaunch step because it’s the one most guides skip. macOS reads the Accessibility list when an app launches. If Autoclick was already running when you flipped the toggle, it doesn’t know about the new permission until you restart it. Cmd+Q, then re-open from /Applications.
The Sequoia-only extra step nobody warns you about
Sequoia (macOS v15.0 and v15.1) added a second hurdle for apps that aren’t notarized by Apple’s developer program. Mahdi’s Autoclick falls into this bucket because the developer doesn’t pay the $99/year for an Apple Developer account. So when you double-click Autoclick.app the first time on Sequoia, you get a dialog saying “Autoclick.app cannot be opened because the developer cannot be verified,” with one button: Move to Trash. Don’t click it.
Instead, open System Settings, click Privacy & Security, and scroll near the bottom of the right pane. There’s a security section with a line that reads Autoclick was blocked because it is not from an identified developer, with an Open Anyway button. Click that, confirm with your password, and Autoclick launches. macOS remembers the override and won’t block subsequent launches.
I dug into Apple Discussions thread 254750979 while testing this. Multiple users hit the same flow and confirmed Open Anyway works on both Sequoia v15.0 and v15.1. Sonoma (v14.x) and Ventura (v13.x) don’t add this second hurdle. The full Accessibility grant flow happens once, and you’re done. Sequoia just makes you do it twice (once for the Open Anyway override, once for Accessibility itself).
Why is my auto clicker greyed out in the Accessibility list?
If the auto clicker shows up in System Settings, Privacy & Security, Accessibility, but the toggle is greyed out and won’t let you flip it, the lock at the bottom of the pane is closed. Click the lock icon, authenticate with your password or Touch ID, and the toggle becomes interactive. This is one of those macOS UX choices that frustrates everyone the first time and gets forgotten the next.
If the lock is open and the toggle is still greyed out, the app entry is stale. macOS occasionally caches an old version of the app’s permission record after an upgrade or a partial reinstall. Fix: select the auto clicker entry, click the − (minus) button to remove it, then re-add via the + button as if it were a fresh install. The new entry will be writable.
The post-update permission wipe (the most surprising failure)
I want to call this out because it caught me. Sequoia’s transition from v15.0 to v15.1 (Apple’s late-2024 point release) wiped my Accessibility entries. Autoclick was still in /Applications, still launchable, and System Settings, Privacy & Security, Accessibility, no longer listed it. Clicks didn’t fire. No warning, no migration prompt, just a silent reset.
I’m not the only person this hit. r/macapps has at least three threads in late 2024 from users with the same symptom. Apple’s release notes don’t mention it, and it doesn’t happen on every minor update, which is why it stays surprising. The fix is the same as a fresh install: re-add Autoclick via the + button. Plan for it on every Sequoia point release. So if your auto clicker stops working the day after macOS updates, this is almost always the cause.
When does Input Monitoring also need to be granted?
Most auto clickers only need Accessibility, but a few also request Input Monitoring (also under System Settings, Privacy & Security). Mahdi’s Autoclick uses Input Monitoring to detect when you’re holding the function (fn) key, which is the hold-to-pause hotkey. So if you grant Accessibility and the click events fire correctly, but the fn-key pause feature doesn’t respond, that’s the Input Monitoring permission missing. Grant it the same way: click + in the Input Monitoring pane, add Autoclick.app, confirm with your password, restart the app.
Other auto clickers like othyn macOS Auto Clicker v1.11.0 also use Input Monitoring for keyboard-key automation features. If you’re using that build and the keyboard automation isn’t working, this is the missing piece. The Accessibility permission alone won’t get keyboard events, only mouse events.
Permission-flow comparison across macOS versions
I tested the grant flow on four macOS versions during the past two weeks. Here’s how the friction varies.
| macOS | Open Anyway needed? | Accessibility location | Lock + auth? | Post-update wipes? | Total clicks to grant |
|---|---|---|---|---|---|
| Big Sur (v11.x) | No (Gatekeeper light) | System Preferences, Security & Privacy, Privacy tab, Accessibility | Lock at bottom, click + auth | Rare | ~7 |
| Monterey (v12.x) | No | System Preferences, Security & Privacy, Privacy tab, Accessibility | Lock at bottom, click + auth | Rare | ~7 |
| Ventura (v13.x) | No | System Settings, Privacy & Security, Accessibility | Auth on toggle | Rare | ~6 |
| Sonoma (v14.x) | Right-click Open | System Settings, Privacy & Security, Accessibility | Auth on toggle | Sometimes | ~6 |
| Sequoia (v15.x) | Yes, Open Anyway flow | System Settings, Privacy & Security, Accessibility | Auth on toggle | Yes (15.0 to 15.1) | ~9 |
The jump from Ventura to Sequoia adds about three extra clicks per fresh install, all of them from the Open Anyway dance. Ventura still asks you to right-click and Open the first time, but the System Settings round trip isn’t required. Sequoia’s tightening is a deliberate Apple security choice and probably won’t relax in macOS Tahoe (v16) when that ships later in 2026.
What if the app isn’t in /Applications?
If you ran the auto clicker from ~/Downloads or a custom folder, the file picker in step 5 above starts in /Applications by default. Press Cmd+Shift+G in the open dialog, type the path to where you installed the app (e.g., ~/Desktop/Autoclick.app), and Add. The Accessibility entry will be tied to that exact path. So if you later move the app, the entry breaks and you’ll need to remove + re-add it.
I always recommend dragging the auto clicker into /Applications before granting permission. macOS sandbox quarantine treats apps in ~/Downloads more aggressively, and you’ll fight extra “downloaded from the internet” warnings on every launch. The standard /Applications path also keeps the permission stable across user accounts on the same Mac.
Other things that quietly break the permission
Beyond the post-update wipe, a few other actions reset Accessibility entries. I’ve hit each of these at least once during testing.
- Replacing the .app bundle (downloading a newer version and dragging over the old one): macOS treats it as a new app and the old permission entry becomes orphaned. Re-add via +.
- Moving the app between folders: same behavior. Permission is tied to file path, so moves break it.
- Installing a system-management tool like CleanMyMac, MacKeeper, or Sensei: some of these scan and “clean” the Privacy & Security plist. I’ve seen MacKeeper specifically wipe entries.
- Migrating to a new Mac via Migration Assistant: privacy entries don’t transfer. You’ll re-authorize every Accessibility-using app.
- Resetting NVRAM/PRAM with Cmd+Option+P+R: occasionally also wipes Privacy entries. Rare but real.
None of these are bugs. They’re macOS being cautious about which app holds permission to fake your mouse clicks. So if you’ve done any of the above and the auto clicker stopped firing events, the fix is always the same five clicks back through System Settings.
Watch the full grant flow
Frequently asked questions
Why does my auto clicker say “Stopped” with no error?
Because macOS is silently dropping the synthetic click events at the Accessibility layer. The app thinks it’s running, the OS rejects every click. Open System Settings, Privacy & Security, Accessibility, add the auto clicker via the + button, toggle it on, restart the app. That fixes 90% of “Stopped with no error” cases.
How do I know if my auto clicker has Accessibility permission?
Go to System Settings, Privacy & Security, Accessibility. The auto clicker should appear in the list with the toggle on (blue/green). If it’s missing entirely, you haven’t granted permission. If it’s listed but the toggle is off, click to enable. If the toggle is greyed out, click the lock at the bottom to authenticate first.
Why is the Accessibility toggle greyed out?
Either the lock at the bottom of the pane is closed (click and authenticate to unlock), or the entry is stale from a previous version. Fix the stale case by selecting the entry and clicking the minus button to remove it, then re-add the auto clicker via the + button as if it were a fresh install. The new entry will toggle freely.
Does macOS Sequoia require an extra Open Anyway step for auto clickers?
Yes, for unnotarized apps. Sequoia (v15.0 and v15.1) blocks first launches with a “developer cannot be verified” dialog. Open System Settings, Privacy & Security, scroll to the security section, and click Open Anyway next to the auto clicker entry. Confirm with your password. macOS remembers the override and won’t block subsequent launches.
Will granting Accessibility expose my Mac to security risks?
Only as much as the app you grant it to. The permission lets the auto clicker simulate mouse and keyboard events. It does not give the app file system access, network privileges, or screen recording. If the app is open-source (Mahdi Autoclick is GPL-2.0; othyn is MIT), you can audit the source code yourself. The risk is bounded to “this specific app can move your cursor and click.”
Why does my Mac wipe the permission after every macOS update?
It doesn’t always, but Sequoia v15.0 to v15.1 specifically did wipe Accessibility entries on my install and on multiple users I tracked on r/macapps. It’s not documented in Apple’s release notes. The fix is just to re-add the auto clicker via the + button after each major macOS update. Plan for it as a recurring 30-second chore.
Do I need Input Monitoring permission too?
Only if your auto clicker uses keyboard-event features. Mahdi Autoclick’s fn-key hold-to-pause requires Input Monitoring. othyn macOS Auto Clicker v1.11.0 needs it for keyboard automation. Grant it the same way as Accessibility: System Settings, Privacy & Security, Input Monitoring, click +, add the app. If you’re only using mouse clicks and no keyboard hotkeys, skip Input Monitoring.
Can I revoke Accessibility permission later?
Yes. Go to System Settings, Privacy & Security, Accessibility, click the auto clicker entry, click the minus button. The entry is removed and synthetic click events stop firing immediately. You can re-add it later if you change your mind. Revoking does not uninstall the app, just removes its permission to send clicks.
Why does my auto clicker need Accessibility but a regular app doesn’t?
Because macOS treats synthetic input as a privileged operation. Regular apps can read events you generate, but only Accessibility-authorized apps can fake events. Apple groups screen readers, accessibility tools, automation utilities, and remote-control apps under the same umbrella permission. Granting it is one toggle in System Settings.
What if Accessibility is missing from the Privacy & Security pane?
It shouldn’t be missing on any supported macOS version. If the entire Privacy & Security category isn’t visible, scroll the sidebar in System Settings, it’s between General and Spotlight on Sequoia. If Accessibility specifically is missing from inside Privacy & Security, you may be running an outdated macOS, restart and check for system updates via Apple menu, About This Mac, Software Update.
Does the Mac auto clicker work on macOS Ventura?
Yes, both Mahdi Autoclick v2.0.4 and othyn macOS Auto Clicker v1.11.0 run on Ventura (v13.x). The Accessibility grant flow on Ventura is one click shorter than Sequoia because there’s no Open Anyway round trip. I tested both apps on Ventura v13.7 in May 2026 and confirmed clicks fire correctly after the standard System Settings, Privacy & Security, Accessibility, +, password flow.
Will my auto clicker stop working when macOS Tahoe (v16) ships?
Probably not, but Apple usually tightens permission flows in major releases. Tahoe is expected late 2026. I’ll re-test Mahdi v2.0.4 and othyn v1.11.0 on the first Tahoe developer beta and update this page. Historically, Accessibility-API apps survive major releases as long as the underlying API doesn’t change. The risk is more about additional friction (more dialogs, more confirmations) than outright breakage.
Bottom line
I’ve spent way too long on this permission. It’s literally five clicks once you know where to look. So save this page, bookmark the System Settings, Privacy & Security, Accessibility path in your head, and remember the post-update wipe pattern. Anything more obscure than that and you’re probably hitting one of the eight failure modes I catalogue in Auto Clicker Not Working on Mac: 8 Fixes. Pillar with the broader picture lives at Auto Clicker for Mac: The Complete 2026 Guide, the safety review at Is Auto Clicker for Mac Safe?, the download at Download Auto Clicker for Mac, and the Sequoia-specific blocker at Auto Clicker Won’t Open on Mac (Sequoia Open Anyway Fix). The greyed-out toggle case has its own deeper page at Auto Clicker Greyed Out in macOS Accessibility (Permission Fix). Apple’s official doc on Privacy & Security pane behavior is at support.apple.com.