›_ Codex Issues
Codex Issues / #27296

Fn global dictation hotkey stops working across apps after update to 26.608.12217

Resolved 💬 10 comments Opened Jun 10, 2026 by ogiso-abukuma Closed Jun 12, 2026

What version of the Codex App are you using (From “About Codex” dialog)?

26.608.12217 (CFBundleVersion 3722); previous working version: 26.602.71036

What subscription do you have?

Not relevant to this issue / not provided

What platform is your computer?

Darwin 25.5.0 arm64 arm; macOS 26.5; MacBook Pro (Apple Silicon)

What issue are you seeing?

After Codex updated from 26.602.71036 to 26.608.12217 on June 10, 2026, the bare Fn global dictation hotkey stopped working reliably.

Immediately after fully quitting and restarting Codex, holding Fn inside the Codex input field can initially start dictation and transcription. However, after switching to ChatGPT or another application's editable text field, holding Fn does not start Codex global dictation. After that failed cross-application attempt, the Fn hotkey also stops working inside Codex and remains broken until Codex is fully quit and restarted.

The microphone and transcription pipeline themselves work correctly:

  • Clicking the microphone icon in Codex records and transcribes normally.
  • Clicking the microphone icon in ChatGPT records and transcribes normally.
  • macOS system Dictation, assigned to the F5 microphone key, works in all applications.
  • The external wireless microphone shows normal input levels in macOS settings.
  • Codex has Microphone, Accessibility, and Input Monitoring permissions enabled.

This appears to be a regression in Codex's global bare-modifier hotkey monitoring rather than an audio input or speech-transcription problem.

What steps can reproduce the bug?

  1. On macOS 26.5, configure Codex global dictation to use the bare Fn key.
  2. Fully quit Codex and reopen it.
  3. Focus the Codex input field, hold Fn, speak, and release it.
  4. Observe that dictation may work immediately after the restart.
  5. Switch to ChatGPT, TextEdit, Notes, or another application and focus an editable text field.
  6. Hold Fn, speak, and release it.
  7. Observe that Codex global dictation does not start.
  8. Return to the Codex input field and try the same Fn hotkey again.
  9. Observe that it no longer works inside Codex either.
  10. Fully quit and restart Codex; the hotkey may work inside Codex again temporarily.

What is the expected behavior?

Holding the configured Fn global dictation hotkey should consistently start Codex dictation in any focused editable text field. Switching between applications or one failed invocation should not disable the hotkey until the application is restarted.

Additional information

  • The feature worked reliably inside Codex and across applications before the update to 26.608.12217.
  • macOS 26.5 was installed on May 15, 2026, and the Codex Fn dictation shortcut continued to work after that OS update. The problem began after the Codex application update on June 10, 2026.
  • Changing macOS system Dictation to F5 avoids a shortcut conflict, but does not resolve the Codex Fn problem.
  • Re-enabling Input Monitoring and Accessibility permissions and restarting Codex did not restore reliable cross-application operation.
  • Standard microphone-button dictation remains functional throughout.
  • Not model-specific: the failure occurs before dictation starts and before any model request is sent.

Related but different issue: #19710 concerns successful transcription followed by a layout-dependent paste failure. In this case, pressing Fn does not start dictation at all, and the hotkey remains inactive until Codex is restarted.

View original on GitHub ↗

10 Comments

heyobravo · 1 month ago

I’m seeing a very similar failure on Codex Desktop 26.608.12217, though with a normal key-combo global dictation shortcut rather than bare Fn.

Environment:

  • Codex Desktop: 26.608.12217
  • macOS: 27.0 beta, build 26A5353q
  • Darwin: 27.0.0
  • Apple Silicon
  • Bundle ID: com.openai.codex

My configured global dictation toggle hotkey was originally Option+Shift+Space. I also tried changing it to Control+Option+Backtick. In both cases, pressing the shortcut does not start Dictate Anywhere/global dictation at all. No dictation bar appears and recording does not begin.

A few things I checked locally:

  • Codex is saving the keybinding correctly in ~/.codex/keybindings.json.
  • Codex has Accessibility and Input Monitoring permissions granted.
  • The microphone/transcription path itself works; Codex dictation has produced recent transcription history.
  • The Popout Window global hotkey still works, so global shortcuts in Codex are not completely broken.
  • macOS is seeing the key events for the configured shortcut.
  • A small Carbon hotkey registration test can register Option+Shift+Space, so macOS does not appear to be rejecting that shortcut globally.
  • I do not see Secure Input being active.
  • The failure appears to happen before any recording/transcription/model request starts.

I’m on a macOS 27 beta, so I initially suspected the OS, but this issue being reported on macOS 26.5 with the same Codex version makes it look much more like a regression in Codex 26.608.12217, specifically in the global dictation / Dictate Anywhere activation path.

In my case, this is toggle dictation rather than hold-to-dictate, but the symptom matches closely: the configured global dictation hotkey stops at the activation step while audio/transcription and other app hotkeys still work.

marcellosilvestri · 1 month ago

I’m seeing the same issue on Codex App 26.608.12217 / build 3722 on macOS 26.5.

In my case this is not limited to Fn: it happens with any configured Hold to dictate shortcut. The shortcut works while Codex is focused, but if I trigger it while another app is focused, nothing happens. The bottom recording indicator does not appear, and after that the shortcut stops working entirely until Codex is fully restarted.

I initially suspected another app was interfering, but after testing different shortcuts and apps, the repro seems to depend only on whether Codex is focused or not.

I also checked for macOS Secure Keyboard/Input and it does not appear to be active. In local logs I saw repeated messages from Codex’s bare-modifier-monitor helper related to:

connection to service named com.apple.linkd.autoShortcut

ending with:

Will NOT re-try to establish the connection

This looks like the same global Hold to dictate shortcut/listener regression.

kendonB · 1 month ago

Also seeing this on Windows WSL

DanielVargasCoyoy-byte · 1 month ago

I’m experiencing the same issue on macOS after the latest Codex update.

In my case, the global “hold shortcut to edit/dictate where the cursor is on the desktop” no longer triggers at all. I configured the shortcut in Settings > Keyboard Shortcuts, but pressing and holding it does nothing: no listening indicator appears and no text is inserted in other apps.

Important detail: in-app dictation still works. When I hover over the microphone button inside Codex, it shows Control + Shift + D, and that shortcut does activate dictation inside Codex.

What I already tried:

  • Reinstalled Codex.
  • Granted Microphone permission.
  • Granted Accessibility / Codex Computer Use permission.
  • Granted Input Monitoring permission.
  • Changed the shortcut multiple times.
  • Closed ChatGPT and Codex completely.
  • Reopened Codex after permission changes.

So this does not seem to be a microphone/transcription issue. It looks like the global desktop hotkey listener is not triggering after the update.

Codex version:
codex-cli 0.138.0-alpha.7

macOS version:
ProductName: macOS
ProductVersion: 26.3.1
ProductVersionExtra: (a)
BuildVersion: 25D771280a

MNJ-INTERNAL-APP · 1 month ago

I’m seeing the same global dictation activation failure on Windows Codex App 26.608.1337.0.

Environment:

  • Codex desktop app: 26.608.1337.0 from Microsoft Store / WindowsApps
  • Codex CLI bundled/available locally: codex-cli 0.136.0
  • OS: Windows, Japanese locale/input environment
  • Microphone permission for Codex: allowed

What works:

  • In-app dictation can be started from inside Codex with Ctrl+Shift+D.
  • When that in-app shortcut is used, Codex does access the microphone.
  • This suggests the microphone/transcription path itself is not completely broken.

What does not work reliably:

  • The configured global dictation shortcuts do not reliably activate dictation.
  • I tested the default hold shortcut Ctrl+M and a configured toggle shortcut Ctrl+Alt+M.
  • Windows reports those hotkeys as already registered/unavailable to other processes while Codex is running, so Codex appears to have registered them.
  • However pressing the configured global shortcut does not consistently start recording/transcription.
  • In some attempts, Windows microphone usage showed Codex opening the mic only for an instant and then stopping immediately, with no transcription history written.

Additional notes:

  • I originally tried mapping a preferred shortcut (Alt+.) through AutoHotkey to Ctrl+Alt+M, but removed that mapping and reproduced with Codex defaults/custom Codex shortcuts directly.
  • keybindings.json and persisted state showed globalDictationHold = Ctrl+M and globalDictationToggleHotkey = Ctrl+Alt+M.
  • Ctrl+Shift+D continues to work inside Codex, while the global dictation activation path remains unreliable.

This looks like the same class of regression described here: the dictation engine can work, but the global dictation hotkey/listener path fails or immediately deactivates before a usable recording session begins.

ashmohd · 1 month ago

I’m seeing the same global dictation activation failure on Codex Desktop 26.608.12217 / build 3722, but on macOS 15.3.2 and with a normal toggle shortcut, not only Fn or bare modifier hold-to-dictate.

Environment:

  • Codex Desktop: 26.608.12217
  • CFBundleVersion: 3722
  • Bundle ID: com.openai.codex
  • ChromiumBaseVersion: 149.0.7827.54
  • macOS: 15.3.2, build 24D81
  • uname -mprs: Darwin 24.3.0 arm64 arm
  • Hardware: Apple M1

Permissions checked:

  • Microphone: Codex enabled
  • Input Monitoring: Codex enabled
  • Accessibility: Codex and Codex Computer Use enabled

Repro:

  1. Clear Hold to dictate.
  2. Set Toggle dictation to Control + Option + D.
  3. Fully quit Codex.
  4. Kill any leftover modifier listeners:

pkill -f '/Applications/Codex.app/Contents/Resources/native/bare-modifier-monitor'

  1. Reopen Codex.
  2. Press Control + Option + D while focused in Codex chat: dictation starts correctly.
  3. Switch to Chrome and focus an editable field.
  4. Press Control + Option + D: nothing happens, no dictation UI appears.
  5. Switch back to Codex and press Control + Option + D again: it no longer works inside Codex either.
  6. Fully quitting/reopening Codex temporarily restores it.

Additional observations:

  • The same failure also reproduced with Hold to dictate set to a single modifier key such as Command or Option.
  • After the failure, the shortcut remains broken until Codex is restarted.
  • pkill removes stale listeners, but does not fix the cross-app focus-switch failure.
  • The audio/microphone path itself appears functional because dictation works immediately after launch.
  • This looks like the global dictation shortcut handler/listener becomes inactive after switching apps, not a microphone permission or transcription issue.
kendonB · 1 month ago

Looks to be fixed in 26.609.30741 on Windows WSL. Thanks team

heyobravo · 1 month ago

Follow-up: this is working for me again after updating Codex Desktop.

Current environment:

  • Codex Desktop: 26.609.30741 / CFBundleVersion 3808
  • Previous affected version: 26.608.12217
  • macOS: 27.0 beta, build 26A5353q
  • Darwin: 27.0.0
  • Apple Silicon

With the same macOS install and the same general setup, my global Dictate Anywhere toggle hotkey now starts dictation again after the Codex update. This was previously failing before recording started on 26.608.12217.

So for my repro, this appears to be fixed in 26.609.30741.

ogiso-abukuma · 1 month ago

Confirmed fixed on my system after updating to Codex Desktop 26.609.30741 (CFBundleVersion 3808) on macOS 26.5.

I tested the Fn hold-to-dictate shortcut both inside Codex and across multiple applications, including repeated focus switching. The shortcut continues to work and no longer becomes inactive.

The affected version was 26.608.12217. Thanks for the fix.

ax-openai · 1 month ago

Closing as resolved.