Push-to-talk dictation: hold a key, talk, release — the interaction none of the voice PRs implement

[alidarvishi14]

This is not another "add voice support" request — it is about one specific interaction model that none of the existing voice work implements, and that I think is the reason the earlier attempts keep stalling.

What I mean

Hold a key. Talk. Release. The transcript lands in the composer. You never leave the composer, never click anything, never review a panel.

That is how Wispr Flow, superwhisper, macOS dictation and the Claude Code desktop app do it, and it is the thing that makes voice actually usable for short bursts — "run the tests again", "revert that last edit", "check the second file too".

Why this is a distinct ask

I went through the existing work, and every implementation is a modal panel, not a key:

PR	state	interaction
#5213 voice dictation beta	open, CONFLICTING	click to record → waveform + timer → click stop → insert
#6625 Codex-style dictation (web + mobile)	open, CONFLICTING	same panel, plus native mobile recording
#6206 voice supervisor	draft, CONFLICTING	persistent Realtime session
#3997 OpenAI Realtime panel	draft, CONFLICTING	persistent Realtime session

In #6625 — the most current one — the only keyboard handling in the entire diff is window.addEventListener("keydown", cancelOnEscape). Recording starts from onClick={() => void startVoiceTranscription()} and ends from onClick={onStop} / onClick={onSend}. There is no held-key path anywhere in any of these branches.

A panel is a destination: open it, record, watch a waveform, stop, review, insert, close. Push-to-talk is modeless: the held key is the recording state, so there is no panel to open, no timer to watch, no cancel affordance to design (releasing early with no speech is the cancel), and no lifecycle to clean up on navigation. It is a meaningfully smaller surface than what has been attempted four times.

On the earlier decision

#653 was closed NOT_PLANNED in March with "out of scope, there are apps that do this already." I would gently push back on that specific reasoning: people reach for those third-party apps because the in-app options are panels. Nobody installs Wispr Flow to get a waveform — they install it to get a key. The panel-shaped version is the one that loses to external tools; the key-shaped version is the one that does not.

Also worth noting @akhmerov's unanswered follow-up on that thread: codex app-server has supported voice input since v0.147.

Smallest useful scope

• One configurable hold-to-talk binding (unset by default), routed through the existing keybindings system.
• While held: capture audio. On release: transcribe and append to the current draft. Nothing is auto-sent.
• Reuse whichever transcription backend lands from feat: add voice dictation beta #5213 / feat: add Codex-style voice dictation to web and mobile #6625 — this asks for no new provider integration, only a different way to start and stop the recorder that already exists in those branches.
• Desktop-only first is fine. Mobile obviously has no held key and should keep the panel.

Known blocker

On signed macOS builds this cannot work until #5321 lands — the desktop build has no com.apple.security.device.audio-input entitlement, so the OS never even shows a microphone prompt. That PR is +3 lines and MERGEABLE, with an open question about also setting entitlementsInherit for Electron helper processes (which is exactly the renderer path any dictation feature needs). See also #728 and #7268.