Auto Clicker Hotkey Not Working on Mac? 7 Fixes for Sequoia, Sonoma, Ventura

I press F19 to start the clicker. Nothing. I press it again. Still nothing. The toolbar says Idle like I’m not even there.

I’ve been bouncing between an M2 Air on Sequoia 15.3 and an Intel MacBook Pro stuck on Sonoma 14.6. I’ve hit this dead silence on both, for completely different reasons. The fix is one of seven things. The right one depends on which permission flow Sequoia broke this week, what app you’re clicking into, and whether Karabiner is running in the background.

I wrote this after the third time a friend texted me “the hotkey just stopped, did Apple kill it again?” Sometimes yes. Sometimes no. Either way, this is the order I run through, and it almost always lands on the right fix in under five minutes. If you haven’t bound a hotkey yet, the set up Start/Stop hotkeys guide covers that first.

The 5-second test that tells you which fix to try first

Before you start toggling permissions, do this. It saves a lot of time.

I open Notes, click into a blank note so the cursor is blinking, then press my bound hotkey and watch the auto clicker’s toolbar.

• Toolbar flips Idle to Running: hotkey works. Your problem is the target app refusing to receive the simulated clicks. Skip to Fix 4 and Fix 5.
• Toolbar stays Idle, no flicker: the listener is dead. Start at Fix 1.
• Toolbar flickers but doesn’t switch state: Karabiner or another remapper is partially eating the event. Jump to Fix 5 first.

I run this test before anything else now. It cut my “why isn’t this working” time in half. I stopped doing the permission dance for problems that were actually about the foregrounded app.

Fix 1: Toggle Input Monitoring permission off and on

I’d guess this fixes 60% of cases. Apple’s TCC system (per-app permissions) gets stuck. The toggle says On, the green check appears, but the event tap is dead. Toggling resets it.

I’ve watched this fix work when the permission was clearly granted, when nothing on the system had changed. macOS just decides the event tap should stop existing. The toggle wakes it up.

Fix 2: Toggle Accessibility permission off and on

Same idea, different permission. I think this is the one people forget exists. They grant Input Monitoring, see the green check, assume that’s the whole story. It isn’t.

Input Monitoring lets the app hear your hotkey. Accessibility lets it send the click. Two different APIs, two grants, two toggle switches in two sub-panels of System Settings.

I had a stretch of about three weeks on my M2 where the hotkey fired (Input Monitoring fine) but no clicks actually happened (Accessibility silently broken). I watched the toolbar say Running and the counter tick up while the cursor never moved. Toggling Accessibility off and on fixed it instantly.

Fix 3: Hotkey conflict with a macOS shortcut

macOS reserves a surprising number of key combos for itself. Any combo that’s “owned” by the OS never reaches the auto clicker. The OS catches it first and runs Mission Control, Spotlight, or Stage Manager instead.

Here’s the hit list of combos that bite people most often, based on messages I get and GitHub issues on similar Mac click tools.

Combo	Owned by	Status
Cmd+Space	Spotlight	Reserved
Ctrl+Space	Input source switch	Reserved
F3	Mission Control	Reserved
F4	Launchpad / Spotlight	Reserved
F11	Show Desktop	Reserved
F12	Notification Center	Reserved
Ctrl+Up / Ctrl+Down	Mission Control / App Exposé	Reserved
Cmd+Tab / Cmd+`	App switcher / window switcher	Reserved
Cmd+Q	Quit App	Reserved
Ctrl+Option+S	Stage Manager (Sequoia 15.2+)	Newly reserved
F13 through F19	Nothing built-in	Safe to use
Ctrl+Option+1 through 9	Nothing built-in	Safe to use

To audit, open System Settings, Keyboard, Keyboard Shortcuts. Walk through every category (Mission Control, Spotlight, Services, Stage Manager on Sequoia, App Shortcuts) and look for any binding matching what you want to use.

I always pick a fresh combo rather than fighting Apple’s defaults, because the defaults usually come back after a major update.

I default to F19. Nothing on Apple’s side touches it. If you’re on a smaller MacBook keyboard without an extended function row, Ctrl+Option+1 is my second pick. Same logic, nothing fights you for it.

Fix 4: App focus required (Steam Intel games and fullscreen weirdness)

This is the one that gets people in fullscreen games and certain browser targets. The hotkey works in Notes, but the moment a specific app is in the foreground, it vanishes.

I’ve hit this hardest with fullscreen Steam games running through the Intel binary on Sonoma 14.5 and 14.6. True fullscreen mode swallows global hotkeys at the WindowServer layer before macOS broadcasts the keypress to background apps.

Fix list for app focus problems:

• Switch fullscreen to borderless windowed. Almost every game offers this. Borderless looks identical on a single-display Mac.
• Disable “Displays have separate Spaces” if you’re on multi-monitor (System Settings, Desktop and Dock). Separate Spaces interacts weirdly with fullscreen apps.
• For Roblox: Roblox on Apple Silicon is Metal-based and respects global hotkeys fine in fullscreen. If your hotkey isn’t firing into Roblox, it’s upstream (Input Monitoring), not focus. The Roblox auto clicker setup guide has the permission flow.
• For Chrome/Edge/Brave: Chrome sometimes intercepts function keys. F19 still works, F1 through F12 may not. Switch to Ctrl+Option+1.

I keep games on Borderless Windowed now. I lost half a day once debugging a hotkey that worked everywhere except the one game I cared about. Fullscreen mode every time.

Fix 5: Karabiner-Elements (or another remapper) is intercepting

If you’ve installed Karabiner-Elements at any point and never fully removed the daemon, it’s almost certainly part of why your hotkey isn’t behaving. Karabiner runs at the DriverKit layer on Apple Silicon and sees keypresses before any normal app does.

If Karabiner has any rule that touches the same key you’re using, it gets the event first, eats or transforms it, and the auto clicker never sees the original keystroke.

• Open Karabiner-Elements (menu bar icon or Applications).
• Go to Complex Modifications. Look at every enabled rule.
• Check Simple Modifications too. Easy to miss, matters just as much.
• Disable any rule that mentions your hotkey’s key or modifier, then retest.

I had a Karabiner rule from 2022 that remapped right-Cmd to F19 for a workflow I’d long forgotten. When I bound the auto clicker to F19, Karabiner intercepted every press, did nothing with it, and the auto clicker never got the event. I disabled the rule and the hotkey worked instantly.

BetterTouchTool, Hammerspoon, and Keyboard Maestro all behave the same way. I’d audit any of those before assuming it’s a permission issue.

Fix 6: A macOS update reassigned your combo

This one’s mostly Sequoia, but the pattern shows up after every major release. Apple ships a point update, introduces a new system shortcut, and your previously-safe hotkey is suddenly reserved.

My rule after every macOS point release: I open Keyboard Shortcuts and skim the categories. Takes 90 seconds. If anything looks newly assigned, I check whether it conflicts with anything I rely on.

I saw the same thing on Sonoma 14.4 with a Spotlight binding, and on Ventura 13.5 with a Mission Control combo. Apple doesn’t announce these in release notes most of the time. You just notice your stuff stopped working.

If you’d rather not babysit this, stick with F13 through F19. Apple has reassigned plenty of combos in the function-modifier space, but the F13-F19 range has stayed unclaimed since they introduced it. Boring and reliable.

Fix 7: Reinstall the auto clicker (TCC database may be corrupt)

If Fix 1 through Fix 6 didn’t help, the TCC entry for your auto clicker is probably corrupt. macOS’s permissions database is a SQLite file at ~/Library/Application Support/com.apple.TCC/TCC.db. If it gets out of sync (mid-update crash, force quit during a grant, Time Machine bringing back a stale row), the toggle says On but the kernel-level entitlement is broken.

I do a full reinstall in this case. Drag to Trash, empty Trash, redownload the latest build of the free Mac auto clicker, install fresh, re-grant both permissions when prompted. The full step-by-step (with receipt cleanup) is in the reinstall after a macOS update guide.

I run this maybe twice a year, usually after a major macOS upgrade. Fresh install fixes it every time.

If the auto clicker also won’t launch at all, the auto clicker won’t even launch guide covers Gatekeeper, quarantine flags, and the unsigned-binary path.

Diagnosis flowchart

Here’s the decision tree I run through, condensed. Pick the symptom that matches.

What if NONE of these work?

You’ve toggled both permissions, audited shortcuts, switched games to windowed, disabled Karabiner, reinstalled the app, and the hotkey still won’t fire. You’re in genuine bug territory. Three useful escalation paths:

1. File a bug with the developer. Include your macOS version (About This Mac, copy the exact build number), auto clicker version, hotkey combo, exact symptom. “Doesn’t work” gets ignored. “F19 hotkey, Sequoia 15.3 build 24D60, both permissions toggled fresh, target is Notes, Idle to Idle no flicker” gets a real answer.
2. Check Console.app for logs. Open Console (Applications, Utilities), filter by the auto clicker name, press the hotkey, look for red entries. If you see “TCC denied” or “EventTap” errors, that’s a system-level rejection telling you exactly which permission isn’t sticking.
3. Try a fresh user account. System Settings, Users and Groups, add a new user. Log in, install the auto clicker fresh, grant permissions, test the hotkey. If it works in the new account, your main account’s TCC database is corrupt and a migration is the cleanest path.

I’ve only ever needed the fresh-user-account test once. It confirmed exactly what I suspected: TCC corruption that survived a reinstall in the original account. I migrated to the new account, problem solved permanently.

FAQ

Related guides