Choosing a push-to-talk key on macOS, and why it's harder than it looks

17 August 2026 · 3 min read · Muteeb Mehraj

Push-to-talk needs a key you can hold without meaning anything else by it. On macOS there are fewer of those than you would expect, and each candidate fails differently.

Why a normal shortcut will not do

Registering a hotkey on macOS is straightforward, and it gives you the wrong thing. The standard API tells you a combination was pressed. Push-to-talk needs to know the key is being held, and then that it was released, because the hold defines the recording.

Observing that means watching raw modifier-flag transitions system-wide, which requires the Accessibility permission. That is why every push-to-talk app asks for it, and why none of them can avoid asking.

Fn, the Globe key

The obvious choice. It is in the corner, it means nothing on its own, and it is where push-to-talk sits in most voice apps people already use.

Two catches.

First, macOS may claim it. Under System Settings, Keyboard, the Press 🌐 key to setting can be set to show the emoji picker or start Apple's own dictation. Either intercepts the keystroke before any app sees it. Set it to Do Nothing or Change Input Source.

Second, Fn is unusual at the hardware level. It does not behave like the other modifiers in every context, and some external keyboards do not send it to the host at all, which is why a trigger that works on a MacBook can appear dead on a desktop with a third-party keyboard.

Right Command and Right Option

The reliable fallback, and the reason handedness matters.

Almost nobody uses the right-hand modifiers deliberately. Shortcuts are pressed with the left hand while the right is on the mouse or trackpad. So the right-hand keys are effectively free, while binding the left ones would collide with your muscle memory constantly.

Distinguishing them requires looking at the key code, not just the modifier flag, because both sides report the same flag. An app that only checks the flag cannot tell left from right and will trigger on either.

The interference problem

Every modifier has one failure mode in common: sometimes you are using it as a modifier.

If your trigger is Right Command and you press Right Command with C, you meant to copy. You did not mean to record a fifth of a second of audio and paste a transcript of it into whatever you were doing.

The fix is to watch for interference. If any other key, click or scroll arrives during a hold, the recording is discarded rather than transcribed. That is why a good implementation cancels rather than transcribes when it sees a second event: silently pasting text you did not ask for is much worse than doing nothing.

Hold or toggle

Hold is the better default. The microphone is open only while your finger is down, which is both a privacy property and a natural way to control where a sentence starts and stops.

Toggle earns its place for long dictation. Holding a key for four minutes is genuinely uncomfortable, and for anything long-form, tapping once to start and once to stop is kinder to your hand.

Picking one

Start with Fn. If nothing happens, check the Globe setting first, before assuming the app is broken.

If you use an external keyboard, or Fn stays unreliable, move to Right Option. It is the least-used modifier on most people's keyboards and it survives keyboard changes better than Fn does.

Whatever you choose, make sure there is a backup binding that does not depend on modifier detection at all. When the primary trigger stops working, and eventually it will, a plain key combination that always works is the difference between a minor annoyance and an app that appears dead.