[Linux] Voice chat hotkey never registers — no Wayland portal support, and no X grab even under XWayland

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

26.803.81509 (Arch Linux package openai-codex-desktop 26.803.81509-8)

What subscription do you have?

Not specified — this is a client-side shortcut-registration bug and should be independent of account tier.

What platform is your computer?

Linux 7.1.6-1-cachyos x86_64 unknown — CachyOS (Arch), KDE Plasma 6.7.4, native Wayland session (KWin). Bundled Chromium 151.0.7922.76. xdg-desktop-portal-kde 6.7.4, with org.freedesktop.portal.GlobalShortcuts version 2 available and healthy.

What issue are you seeing?

The global Voice chat hotkey does not work on Linux. Pressing the combination does nothing, from any window, including when the ChatGPT window itself is focused.

The setting saves correctly — it persists to ~/.codex/keybindings.json as:

[{"command":"realtimeVoice","key":"Ctrl+Alt+V"}]

and the settings UI continues to display the hotkey as active. No error appears anywhere: not in the app logs, not in the systemd journal, not in Sentry. From a user's point of view the feature simply looks configured and silently does nothing, with no indication that anything failed.

I tried several different key combinations with the same result, so this is not a conflict with an existing shortcut.

I've isolated two independent causes.

1. No Wayland support for global shortcuts

The app registers the hotkey solely via Electron's globalShortcut.register(), which is implemented as an X11 XGrabKey. Under a native Wayland session that call cannot work, and the app bundle contains zero references to org.freedesktop.portal.GlobalShortcuts — the only sanctioned mechanism for global hotkeys on Wayland. (The one match for that string anywhere in the install lives inside the bundled Chromium binary, not in application code.)

Making this worse: globalShortcut.register() returns true on Wayland while doing nothing at all. So the app has no way to detect its own failure, and the user is never told.

2. The hotkey is not registered on Linux at all, even on X11/XWayland

I tried the obvious workaround of launching with --ozone-platform=x11 so that XGrabKey would work under XWayland. It does not help. With the app verifiably running as an X11 client, and with the keybinding already present on disk before the app started, no X key grab is ever placed — even though a control Electron app registering the identical combination on the same display grabs it successfully seconds later.

This second issue is not explained by Wayland, and it is the more serious of the two.

Evidence

Control experiment — a minimal 10-line Electron app registering Ctrl+Alt+V on this same machine and display, with the resulting X server state checked from a separate X client:

--ozone-platform=x11        register() = true    real X grab placed (all CapsLock/NumLock variants)
--ozone-platform=wayland    register() = true    NO grab placed at all

That is the direct demonstration that register() reports success on Wayland while silently doing nothing.

ChatGPT app, cold start with --ozone-platform=x11 and the keybinding already in keybindings.json before launch, checked at both 30 seconds and 152 seconds of uptime:

Ctrl+Alt+V (keycode 55):
  +none      -> FREE (nobody grabbed it)
  +CapsLock  -> FREE (nobody grabbed it)
  +NumLock   -> FREE (nobody grabbed it)
  +Caps+Num  -> FREE (nobody grabbed it)

Grab conflicts were detected from a second X client via BadAccess, and every run included a passing positive control (two of my own connections contending for the same combination) to prove the test actually detects real grabs.

XWayland operation confirmed genuine — the app's window is a real X11 window listed in _NET_CLIENT_LIST, with _NET_WM_PID matching the main process and WM_CLASS "chatgpt".

Additionally, the app registers no kglobalaccel component with KDE; all components currently registered on this system belong to other applications.

One note for triage: the journal line Appshot hotkey inactive is unrelated. That code path is gated on process.platform === 'darwin', so it is macOS-only and a red herring.

What steps can reproduce the bug?

1. On a KDE Plasma (or any) native Wayland session, install and launch the ChatGPT/Codex desktop app on Linux.
2. Open Settings and assign a voice chat hotkey, e.g. Ctrl+Alt+V.
3. Press the hotkey from any window. Nothing happens.
4. Confirm the value was saved in ~/.codex/keybindings.json — it will be there.
5. Optionally restart with --ozone-platform=x11 and repeat; still nothing.

What is the expected behavior?

Pressing the configured voice chat hotkey from any window should start a realtime voice chat, as it does on macOS and Windows. Failing that, the app should at minimum surface an error rather than displaying a hotkey as active when it has not been registered.

Additional information

Suggested fixes:

• Implement org.freedesktop.portal.GlobalShortcuts (CreateSession / BindShortcuts / Activated) for Linux. This is the only approach that works on Wayland, and it is what other Electron applications have adopted.
• Do not trust the return value of globalShortcut.register() on Linux, since it is unreliable on Wayland. Verify the registration actually took effect and surface failures in the settings UI.
• Separately, investigate why no registration occurs even on X11/XWayland, where the underlying Electron API demonstrably works.

Workaround: none found. --ozone-platform=x11 does not work. As far as I can tell the voice hotkey is currently non-functional on Linux regardless of session type, which makes the realtime voice feature effectively unreachable for keyboard users on this platform.

I searched existing issues before filing — #35629, #36944, #24009, #31992, #32152 and #37593 all cover different hotkey problems (working-but-misbehaving hotkeys, or macOS/Windows specifics). I could not find an existing report of the Linux hotkey never registering. Happy to test a fix or gather more diagnostics.