Windows global dictation repeatedly starts/cancels on hold and silently fails to paste into external apps

What version of the Codex App are you using?

OpenAI.Codex_26.803.5235.0_x64

What platform is your computer?

Windows 11 x64 (OS build 26100).

PowerShell: Windows PowerShell 5.1.26100.8875.

What issue are you seeing?

The Windows global hold-to-dictate feature has two related failures when used outside the Codex window:

1. Holding the configured shortcut (Ctrl+D in this case) can repeatedly start and cancel dictation instead of keeping one recording session active.
2. Even when speech is transcribed, the text can silently fail to appear in the focused editable field of another application.

Dictation inside the Codex composer works through a different internal insertion path and does not show the same external-field behavior.

This is not a microphone or speech-to-text failure. Immediately before the failing sequence, two Chinese recordings were successfully captured and transcribed.

Local history shows eight global dictation sessions cancelled between 21:56:08 and 21:56:11. Each session lasted only 195–247 ms, with a new session starting roughly every 0.3 seconds. This matches the visible start/cancel/start/cancel loop while the shortcut remained held.

What steps can reproduce the bug?

1. Install and open Codex Desktop on Windows.
2. Configure Hold-to-dictate to Ctrl+D.
3. Focus an editable text field in another application.
4. Hold Ctrl+D, speak, and then release it.
5. Observe that the global dictation UI may rapidly alternate between starting and cancelling.
6. On an attempt that reaches transcription, observe that the transcribed text may not be inserted into the external field and no actionable error is shown.

The exact target application does not appear to be the audio failure boundary; in-app composer dictation can still record and transcribe successfully.

What is the expected behavior?

• One physical key hold should create exactly one recording session.
• Releasing the shortcut should stop that session once.
• The transcript should be inserted into the editable control that was focused when dictation began.
• If insertion is blocked or rejected, Codex should preserve the transcript and show an actionable error instead of failing silently.

Additional information

I inspected the packaged Windows desktop implementation and found two reliability risks that match the symptoms:

• Shortcut press handling uses Electron's globalShortcut, while release/held-state detection is performed by a separate PowerShell process polling GetAsyncKeyState every 40 ms. The two paths can disagree about the physical key state, which can produce repeated start/cancel transitions from one hold.
• External insertion writes the transcript to the clipboard, waits 150 ms, invokes PowerShell [System.Windows.Forms.SendKeys]::SendWait('^v'), waits 700 ms, and restores the clipboard. It does not appear to capture/verify the foreground window or confirm that the focused control accepted the paste. Elevated target applications may additionally reject synthetic input due to Windows integrity-level restrictions.

PowerShell integrity and command resolution were checked:

• Only C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe resolves.
• The executable has a valid Microsoft Authenticode signature.
• There is no PATH shadowing.
• All four PowerShell profile files are absent, and Codex invokes PowerShell with -NoProfile.
• System.Windows.Forms.SendKeys and GetAsyncKeyState dependencies load successfully.

No live SendKeys probe was run because it would inject text into whichever user application happened to be active.

Possible fixes:

• Use one authoritative native input-hook/state-machine path for key-down and key-up, with debouncing and a one-session-per-physical-hold invariant.
• Capture the intended target HWND/process when recording starts, validate it before insertion, and verify/report insertion failure.
• Prefer a native Windows text-injection/accessibility path where available; at minimum, keep the transcript recoverable when synthetic paste fails.

Related but different reports found during duplicate search:

• #30948: shortcut settings do not synchronize between two settings pages.
• #27296: macOS Fn global hotkey stops working across applications.
• #26318 / #31139: microphone/recording/transcription failures.

Redacted local dictation history and desktop logs can be provided if useful.