tarr / Rill@tarr1124
My voice-dictation (Aquavoice) hotkey kept dying after my Mac woke from sleep. Restarting the app did nothing; a reboot always fixed it. I'd been blaming the app the whole time. Today I finally caught the actual culprit, and the app was innocent.
I pointed Claude Code Fable 5 at the machine and let it work through the evidence. First find: the app's native helper logs every dictation trigger with an active_keys_count field, which distinguishes "hotkey pressed" from "user clicked the floating mic." Every day the hotkey had silently died was already fingerprinted in the logs by my own workaround clicks. Second find: a 20-line Swift probe calling CGGetEventTapList showed the helper's event tap still registered and enabled — listening for kCGEventKeyDown, KeyUp, FlagsChanged, all healthy — while the helper's own logs showed no key events arriving at all as I typed. A listener that's alive but starved means the block is upstream, in event delivery itself.
Upstream turned out to be Secure Input. Any process can call EnableSecureEventInput — it's how password fields defend against keyloggers. While any process holds it, WindowServer withholds keyboard events from every CGEventTap and NSEvent global monitor in the session. Typing into the focused app still works, so nothing looks broken; but every tap-based tool — voice input, Keyboard Maestro, TextExpander, window managers — goes deaf at once.
The hunt is where it got interesting. ioreg -l -w 0 | grep SecureInput reports the holder's PID (kCGSSessionSecureInputPID). Mine said loginwindow: a known macOS bug where the lock screen fails to release Secure Input after wake, and a Ctrl+Cmd+Q lock/unlock cycle forces the release. Did that — the PID just moved to my terminal. Restarted the terminal — still dead. The last holder standing was 1Password's unlock prompt, sitting unnoticed in the background. It auto-locks on sleep; its password field enables Secure Input even while the window isn't focused; and until you unlock or dismiss it, every global hotkey on the machine stays dead. Holders stack, and the single PID that ioreg reports is a hint, not a verdict. It's also why rebooting "worked": it killed every holder at once, unlock prompt included.
The runbook, if your hotkeys die after sleep: look for a background password prompt first (1Password is a documented repeat offender), then run ioreg -l -w 0 | grep SecureInput and eliminate suspects until the line comes back empty. Lock/unlock the screen to clear loginwindow. Reboot is the last resort, not the fix.
Two things I'm keeping: "only a reboot fixes it" is a signal that some process is squatting on a session-wide resource, and a diagnostic that names one process is where the investigation starts, not where it ends.
