Auto Clicker Won’t Open on Mac (Sequoia & Sonoma Open Anyway Fix, 2026)
60-second answer. Try to open the auto clicker once so macOS records the block. Then open System Settings > Privacy & Security, scroll past Location Services and FileVault to the Security section near the bottom, find the line that names the blocked app, and click Open Anyway. Authenticate with Touch ID or your password. A second confirmation dialog appears with another Open Anyway button (this second click is new in Sequoia 15.0+ and is the step most guides miss). Click it. The app launches and the override is remembered for future runs.
Why Won’t My Auto Clicker Open on macOS?
I’ll keep it short. The Mahdi Bchatnia Autoclick binary is GPL-2.0 open-source, archived in 2022, and it isn’t notarized by Apple. Notarization costs the developer $99/year through the Apple Developer Program (an annual fee), and the project hasn’t paid since archiving. So Gatekeeper refuses the first run and shows the “cannot be verified” dialog. This isn’t a malware warning. It’s a “we can’t confirm who built this” warning.
I’ll explain what’s happening because it sounds scarier than it is. Gatekeeper checks two things on every fresh launch: code signature (does the binary have a valid Apple Developer signature?) and notarization ticket (has Apple scanned this exact build for known malware?). The Autoclick binary fails check one because the developer doesn’t have a paid cert. It also fails check two because notarization requires check one. So macOS shrugs and refuses.
I’ve inspected the binary with codesign and run it through VirusTotal. Both come back clean. I cover the safety walkthrough in Is Auto Clicker for Mac Safe?, but the TL;DR: unsigned doesn’t mean malicious. It means the developer didn’t pay Apple’s annual tax. Sequoia just makes you click more to confirm you understand that.
I think Apple’s Sequoia 15.0 tightening is reasonable, even though it’s annoying. They removed the old Control-click “Open” workaround entirely (per MacRumors coverage from August 2024) and forced everything through System Settings. The reasoning: the right-click bypass was getting abused by malware installers. I’d rather have the friction.
The 6-Step Open Anyway Fix (Sequoia 15.0+ Path)
This is the exact flow I run on every new Mac I set up. It takes about 90 seconds once you know where everything lives. The first three steps stage the block; the last three execute the override.
Try to open it once
Double-click Autoclick.app from /Applications (or wherever you dropped it). macOS shows a dialog: “Apple could not verify [App] is free of malware that may harm your Mac.” Click Done. Don’t click Move to Bin. This first failed launch is what registers the app with Gatekeeper so the override appears in step 4.
Open System Settings
From the Apple menu, click System Settings. On Sonoma the panel is called System Settings; on Ventura and earlier it’s System Preferences. Same content, different name. Either way, head to Privacy & Security in the sidebar.
Click Privacy & Security
Scroll the sidebar if you don’t see it. Click into the panel and you’ll land on a long pane covering Location Services, Contacts, Calendars, FileVault, FileVault Recovery, App Management, Developer Tools, and finally Security. The Security section is what you want.
Don’t see the line? If you wait too long between steps 1 and 4, Sequoia sometimes hides the override notice. Repeat step 1 to re-trigger the block, then immediately scroll down. The reference is the Apple Discussions thread 254750979 where multiple users hit the same timing window in late 2024.
Find the Open Anyway line
Scroll all the way to the bottom of the Privacy & Security pane. You’re looking for a one-line summary that reads something like “Autoclick.app was blocked to protect your Mac.” To the right of that line is an Open Anyway button. Click it.
Authenticate
macOS prompts for Touch ID or your account password. Confirm. Sequoia tightened this gate over Sonoma; on Sonoma 14.6 the auth prompt is sometimes skipped for admin accounts, but on Sequoia 15.0+ it’s mandatory every time. Standard friction.
Confirm in the second dialog
Here’s the step most guides miss. After the password prompt, a second confirmation dialog appears repeating the warning with another Open Anyway button. Click it. Now the app actually launches. Sequoia stores the override in the local Gatekeeper database, so future launches go through normally. You’re done.
What to expect after a successful override: the auto clicker UI window appears. macOS may immediately show a separate Accessibility permission prompt (different feature, same Privacy & Security panel). Granting Accessibility is a separate step. I cover that in How to Grant Accessibility Permission.
Sequoia v15.0 vs Sonoma v14.x: Path Comparison
The Open Anyway flow exists on every macOS version from Mojave forward, but the path and total click count have shifted with each release. Here’s what changed and where to find the override on each version I’ve personally tested.
| macOS Version | First-launch dialog text | Override location | Total clicks to open |
|---|---|---|---|
| Sequoia 15.1 (Nov 2024+) | “Apple could not verify [App] is free of malware that may harm your Mac” | System Settings > Privacy & Security > Security (bottom) | 6 clicks |
| Sequoia 15.0 (Sep 2024) | “Apple could not verify [App] is free of malware…” | System Settings > Privacy & Security > Security | 6 clicks |
| Sonoma 14.6 | “[App] cannot be opened because Apple cannot check it for malicious software” | System Settings > Privacy & Security (Open Anyway button visible after first try) | 4 clicks |
| Ventura 13.7 | “[App] cannot be opened because the developer cannot be verified” | System Settings > Privacy & Security (or Right-click > Open shortcut) | 3 clicks |
| Monterey 12.x | “[App] cannot be opened because the developer cannot be verified” | System Preferences > Security & Privacy > General > Open Anyway | 2 clicks (right-click bypass) |
Source: hands-on testing by me on the four physical Macs listed in the meta bar, May 2025 through April 2026. Each click count assumes a fresh failed launch.
I see the trend clearly. Apple keeps adding clicks. Sequoia 15.0 was the biggest jump because they killed the right-click shortcut and added the second confirmation dialog. So what was 2 clicks on Monterey is 6 clicks on Sequoia now. Annoying, sure. But it’s a one-time chore.
When Open Anyway Doesn’t Appear
About 5% of the time the override line is missing from Privacy & Security entirely. I’ve reproduced four scenarios where this happens. Each has a different fix.
Dialog dismissed too fast
If you clicked “Move to Bin” or closed the dialog before macOS logged the block, the override line never appears. Fix: re-launch within 5 minutes, click Done, then walk the override flow. The block entry expires fast on Sequoia.
App moved after first run
Sequoia binds the override to the exact filesystem path. If you launched from ~/Downloads, hit the dialog, then dragged to /Applications before approving, the block reset. Launch from the new location to re-trigger.
MDM-managed Mac
On work or school Macs, IT may have pushed a profile disabling Open Anyway. Symptom: greyed-out button, or no line at all. Ask IT to whitelist the app, or use a personal Mac.
Signed but revoked cert
Rarer: dialog says “signature is invalid” rather than “developer cannot be verified.” Gatekeeper treats this as malicious. Re-download from the official source.
Post-Update Permission Wipe (Sequoia 15.0 to 15.1)
I learned this one the hard way. After updating my M3 Pro from Sequoia 15.0 to 15.1, my previously-working auto clicker wouldn’t fire clicks. App launched fine, UI showed up, Start button did nothing. No error. I spent 20 minutes before realizing: the update wiped the Accessibility permission entry without notice.
It’s different from a launch block. The app opens, but the Accessibility entry is gone. macOS dropped it silently because the binary’s hash changed (Sequoia 15.1 also pushed a new XProtect database). Multiple r/macapps threads confirmed I wasn’t alone; the same thing hit Hammerspoon, BetterTouchTool, and Karabiner-Elements users.
How to detect it: open the auto clicker, press Start, watch the cursor. If nothing fires, open System Settings > Privacy & Security > Accessibility. If Autoclick isn’t listed (or the toggle is off), that’s your culprit. Click the +, browse to /Applications, add it. Toggle activates automatically.
I now plan for this on every point release. The full eight-fix list lives in Auto Clicker Not Working on Mac: 8 Fixes, but for this symptom, re-adding to Accessibility is the entire fix.
Verifying the Binary Before Open Anyway
Before clicking Open Anyway on any unsigned app, I verify what I downloaded. I do this every time. Takes 30 seconds and it’s the single most important security habit on macOS.
I open Terminal and run codesign -dv --verbose=4 /Applications/Autoclick.app. The output reveals whether the binary has any signature, who signed it, and which entitlements it requests. For the Mahdi Autoclick build, I see “code object is not signed at all,” which is expected. What I don’t want to see: a signature from an unfamiliar developer that doesn’t match the project’s GitHub README.
Then I verify SHA-256. Run shasum -a 256 ~/Downloads/autoclick.zip and compare against the documented hash. If values don’t match, the file got tampered with in transit, or it came from a malware mirror. Delete and re-download from canonical source.
Why bother? Open Anyway is the security checkpoint. Once you click through, macOS trusts the binary forever (until the next update wipes trust). I cover the full verification trail in Is Auto Clicker for Mac Safe?. The companion Why macOS Flags Some Auto Clickers as Unverified Developer covers the notarization economics: $99/year to Apple, plus build-pipeline overhead, plus cert renewals. For a side-project archived in 2022, that’s a non-starter.
Other Reasons an App Might Refuse to Launch
Open Anyway covers about 90% of “won’t open” scenarios on Sequoia. If you’ve walked the override and the app still won’t launch, one of these less-common issues is probably to blame.
- Quarantine attribute stuck: macOS tags downloads with a
com.apple.quarantineattribute. If the override didn’t clear it, runxattr -d com.apple.quarantine /Applications/Autoclick.appand re-launch. - App translocation: if the app launches from a randomized read-only path (title bar shows /private/var/folders/…), macOS is translocating it. Move the app from /Downloads to /Applications. Translocation only fires from quarantined locations.
- Antivirus blocking: Norton, McAfee, ClamXAV may quarantine unsigned binaries on touch. Check the AV’s quarantine list. Whitelist the auto clicker, or disable real-time scan long enough to launch once.
- Corrupted .app bundle: if the download stopped mid-way or unzip failed, the Info.plist or main binary is incomplete. Delete, redownload, re-extract.
- Missing Rosetta 2: not relevant for Autoclick (universal binary), but if your target app is x86-only on Apple Silicon, run
softwareupdate --install-rosetta --agree-to-license.
For the long-form treatment of every failure mode I’ve hit (clicks not firing, permission wipes, peripheral conflicts), see Auto Clicker Not Working on Mac: 8 Fixes. If you haven’t installed yet, How to Install on Sonoma & Sequoia walks the download-to-first-launch flow.
Frequently Asked Questions
Common questions I get from readers stuck on the Sequoia notarization gate.
Why won’t my auto clicker open on Mac?
Because Gatekeeper blocks unsigned, un-notarized apps on first launch. The Autoclick binary isn’t notarized (the developer doesn’t pay Apple’s $99/year fee). The fix is the Open Anyway override under System Settings > Privacy & Security. One-time chore.
Where is Open Anyway on macOS Sequoia?
System Settings > Privacy & Security, then scroll past Location Services, FileVault, and Developer Tools to the Security section at the bottom. You’ll need to launch the app once first so macOS logs the block.
Why doesn’t right-click Open work anymore?
Apple killed the Control-click bypass in Sequoia 15.0, citing abuse by malware installers. The only sanctioned override path is System Settings > Privacy & Security now.
Does Sequoia auto-clear the Open Anyway approval?
Sometimes after macOS point updates (15.0 to 15.1). When the binary hash changes or XProtect updates, Gatekeeper re-evaluates. If a previously-approved app won’t open after an update, walk the flow again.
Is it safe to click Open Anyway?
It’s safe if you trust the source. Only click Open Anyway on builds from the canonical project URL with a SHA-256 that matches the documented hash. Don’t click it on apps from random Google Drive links.
Why is the Open Anyway button greyed out?
Two causes. First, an MDM profile (work or school Mac) has disabled the override. Second, the signature is revoked rather than missing. The dialog text is the tell: “signature is invalid” means revoked; “developer cannot be verified” means unsigned.
Do I need to disable Gatekeeper to open the auto clicker?
No, and you shouldn’t. The spctl --master-disable command lowers the security posture of every install. Use the per-app Open Anyway instead.
Why does the app open once and refuse next time?
The binary probably moved. Open Anyway is path-bound, so /Downloads vs /Applications counts as different apps. I keep mine in /Applications and never move it.
How do I verify an unsigned auto clicker is legit?
Three checks. Run codesign -dv on the app. Run shasum -a 256 on the .zip and compare to the official hash. Upload the zip to VirusTotal for a multi-engine scan.
Does the Open Anyway override expire?
Not on a timer. It can be invalidated by a macOS point update or an XProtect refresh. In practice I re-approve maybe once a year on a heavy-update machine.
Can I script the Open Anyway flow?
Sort of. You can run spctl --add with sudo to whitelist a specific binary. But it still requires admin auth. For one Mac, the GUI flow is faster.
Related Guides
Other spokes in the auto-clicker-on-Mac cluster, all of which I’ve personally tested and updated for Sequoia 15.x.