Global hotkeys: Carbon RegisterEventHotKey does swallow the key, and needs no permission — measured

[math65]

The global hotkey engine uses a listen-only CGEventTap, which requires the Input Monitoring permission and, under the App Sandbox, cannot swallow the key — the chord still reaches the app in front. Releases up to 1.8.0 asked for no permission at all; 1.9.0 is the first to require it.

HotkeyMonitor.swift's header rules out the Carbon alternative:

(Carbon RegisterEventHotKey was tried and rejected — it doesn't swallow either, and can't do bare keys / modifier-only chords.)

I measured both claims. Neither holds.

Does RegisterEventHotKey swallow?

A test binary registered ⌥J globally at .accessory policy (never frontmost), with TextEdit in front. ⌥J was chosen because it inserts a character when it is not swallowed, so the document answers the question by itself.

Step	Result
⌥J, hotkey registered	handler fired — TextEdit document stayed empty
Plain "A", hotkey registered	"A" inserted — control: the app does receive keystrokes
⌥J, after unregistering	"Ï" inserted

It swallows. The control rules out the alternative explanation that ⌥J simply types nothing on this layout (French/AZERTY).

What does it actually refuse?

RegisterEventHotKey return status, one call per form:

Form	Status
F13, no modifier	0 — accepted
A letter key, no modifier	0 — accepted
⌘⇧A	0 — accepted
⌥⇧⌘Space	0 — accepted
Modifier-only chord (⌘⌃ held)	not expressible — the API takes a key code, and 0 is a real key

Bare keys are accepted, so that half of the claim is wrong too. A bare letter would be swallowed system-wide and become untypable everywhere, which is a good reason to keep refusing it in the recorder — but F13–F20 is exactly the recommended binding, and it works.

Push-to-talk is covered as well: registering F13 bare and listening for both kEventHotKeyPressed and kEventHotKeyReleased produced F13 PRESSED then F13 RELEASED.

Proposal

Route by the shape of the binding:

• anything with a key code → Carbon. No permission, and the chord is genuinely swallowed.
• modifier-only chord → the existing tap, permission and all.

Consequences worth weighing:

• Input Monitoring disappears for nearly every user.
• It removes most of the case for Proposal: drop the App Sandbox so global hotkeys can truly swallow keys #34: if Carbon already swallows inside the sandbox, dropping the sandbox only buys the modifier-only chord.
• It makes much of Global mic-toggle hotkey: work while ttaccessible is focused, and use one chord everywhere #38 moot. A ⌘⇧A swallowed by Carbon never reaches the main menu, so mainMenuOwns / safeMenuKeyEquivalent / the double-fire guard have nothing left to arbitrate for those bindings. Global mic-toggle hotkey: work while ttaccessible is focused, and use one chord everywhere #38 is still correct for the engine as it stands today and should land on its own merits — this would simplify it afterwards, not block it.

Not yet measured

• Behaviour under secure input (password fields neutralise Carbon hotkeys).
• Migration of bindings already stored in preferences.
• Whether a Carbon hotkey and the SwiftUI menu key equivalent can coexist on the same chord without one shadowing the other.

[math65]

Follow-up: the measurements above were taken with an unsandboxed test binary and synthetic keystrokes, which left the one objection that matters — we are sandboxed, and it is the sandbox that stops the tap from swallowing. Re-ran the whole thing without either weakness.

Sandboxed, physical keypress

A minimal .app signed with com.apple.security.app-sandbox, .accessory policy so it is never frontmost. The sandbox is proven active at runtime rather than assumed: writing outside the container fails, and NSHomeDirectory() reports ~/Library/Containers/com.math65.sandboxhk/Data.

Step	Result
⌥J typed physically, hotkey registered	handler fired — no character inserted anywhere
Control: plain "A"	inserted normally
⌥J after unregistering	"Ï" inserted

Carbon swallows the chord from inside the App Sandbox, on a real keypress. The sandbox is not what blocks swallowing — a consuming CGEventTap needs Accessibility, whereas a Carbon hotkey is intercepted by the WindowServer before the front app ever sees it.

Press/release timing

Registering both kEventHotKeyPressed and kEventHotKeyReleased, timestamps in seconds of uptime:

Gesture	PRESSED	RELEASED	Held
short tap	288817.303	288817.436	133 ms
held press	288821.562	288823.391	1829 ms

One PRESSED per press, even when held for nearly two seconds — no autorepeat storm. The tap has to filter keyboardEventAutorepeat by hand for this; Carbon delivers a clean cycle with the real hold duration, which is what push-to-talk wants.

Where that leaves things

Nothing in the sandbox argues for the tap. The remaining case for it is the modifier-only chord, which RegisterEventHotKey genuinely cannot express — it takes a key code, and 0 is a real key.

Still unmeasured, and worth checking before this ships: behaviour under secure input (password fields neutralise Carbon hotkeys), and whether a Carbon hotkey and the SwiftUI menu key equivalent can hold the same chord without one shadowing the other — if Carbon swallows it first, the menu item would keep displaying a shortcut it no longer answers.

[math65]

Pushed a working prototype to work/carbon-hotkeys (facfb35) — easier to test than to describe. It is deliberately not a PR: what I'm after is a measurement on your machine, not a review.

What it does

Bindings route by shape: anything with a key code registers through Carbon, a modifier-only chord keeps the tap. Input Monitoring is now only ever requested by that last form.

A refused registration means another app already owns the chord. There is no silent fallback to the tap — that would ask for a permission out of nowhere and then fire on top of whatever the other app does with the same press. Instead the recorder asks the OS up front, at record time, so you are told while you can still pick another chord.

What I'd like you to check, in this order

1. Build and run, then look at audio.log. It should say Carbon hotkey ACTIVE for <chord> (no permission needed), and macOS should never ask for Input Monitoring.
2. Set a global binding, put another app in front, press it. Does it fire and get swallowed — no character typed, no system action in the other app?
3. Same with VoiceOver running. That is your normal condition, and it was mine when I measured — it changed nothing here, but you are the one who would notice if it does for you.

If step 2 fails on your machine while it passes here, that is the finding, and it changes what we do next rather than confirming what I wrote above. Worth running ioreg -l -w 0 | grep kCGSSessionSecureInputPID if it does: a latched secure input suspends Carbon hotkeys and would look exactly like "it doesn't swallow" — which may well be what you hit originally.

Still missing, so don't read it as finished

• isChordUnavailable is set but not surfaced in Preferences yet. It covers the case where a chord is taken by another app after it was chosen — rare, but silence there reads as "the app is broken".
• The parts of Global mic-toggle hotkey: work while ttaccessible is focused, and use one chord everywhere #38 this makes redundant (mainMenuOwns, safeMenuKeyEquivalent, deferToMainMenuWhenActive) are untouched. They still serve the tap and the app-focused path, so it is not a straight deletion.
• Secure input suspends the hotkey, which resumes on its own. Measured, not yet documented for users.

[rfiorentino1]

Reproduced. Your result holds on my machine.

work/carbon-hotkeys at facfb35, built locally and signed with my own Apple Development identity. Sandbox verified on the built binary rather than assumed — codesign -d --entitlements - reports com.apple.security.app-sandbox = true. macOS 26.6 (25G5052e). Nothing holding secure input: ioreg -l -w 0 | grep kCGSSessionSecureInputPID returns nothing.

[Hotkey] configure mode=alwaysOn key=⌃⌘ pttGlobal=1 muteGlobal=1
[Hotkey] Carbon hotkey ACTIVE for ⇧⌘A (no permission needed)

Registration succeeded, so "another app owns the chord" is ruled out here. With Safari frontmost and ⌘⇧A pressed physically, Safari never saw it and the mic toggled. No Input Monitoring prompt appeared — cleanly so, because my push-to-talk binding is a modifier-only chord and the mode was alwaysOn, so no tap was installed at all in that run.

On where the line came from, since you asked rather than assumed.

I went looking, and there is no Carbon code anywhere in the repo's history — no EventHotKeyRef, no InstallEventHandler, no RegisterEventHotKey on any branch. That sentence was written in 3eb8c51, the same commit that removed the KeyboardShortcuts library, which is RegisterEventHotKey underneath. So it describes that library's behaviour as I understood it at the time, not an experiment I ran. I should have written it that way, or not written it at all.

Two things were true then and both fit what I saw. The willSet stale-prefs bug was still live — the same bug that later made "the sandbox blocks the CGEventTap" look true when it wasn't — and a hotkey that never gets configured is indistinguishable from one that doesn't swallow. And the chord I had in play was ⌘⌃, which RegisterEventHotKey genuinely cannot express. "Didn't work" became "doesn't swallow," and the half of that sentence that is correct is what made the other half read as measured.

One more of the same kind, before it becomes load-bearing: the header on the un-sandbox branch says "suppressing flagsChanged would corrupt modifier state everywhere." That was a judgment call, not a measurement, and I don't think either of us has tested it — so please don't take it from me the way this one got taken.

Happy to talk about what this means for #34 separately.

Small thing from running the branch: the configure/register pair fires twice at launch, so Carbon hotkey ACTIVE is logged twice for one binding.