Summary
Pressing a bare modifier key — Right Shift, the Windows key, and friends — navigates the desktop app to Settings → General. No chord, just tapping Shift while (for example) thinking about what to type next.
Root cause
SHORTCUTS.SETTINGS is defined as "mod+," in packages/ui/src/features/command/keyboard-shortcuts.ts:
export const SHORTCUTS = {
...
SETTINGS: "mod+,",
...
}
That string is passed to react-hotkeys-hook's useHotkeys (in the global event handlers and on the AI-approval screen). But , is react-hotkeys-hook's default hotkey-list separator (splitKey). The library does keys.split(",") before parsing, so "mod+," never registers Ctrl+Comma at all — it registers two degenerate hotkeys:
"mod+" → { mod: true, keys: [""] }
"" (empty string) → { keys: [""] } — no key, no modifiers
Inside the library's matcher (isHotkeyMatchingKeyboardEvent), a keydown of a bare modifier passes every gate for these degenerate hotkeys:
- the first guard doesn't reject because
mapKey(e.code) for a modifier ("shift", "meta", …) is in the matcher's modifier allowlist;
- the modifier-consistency checks are all skipped for the pressed modifier itself (
pressedKey === "shift" etc.);
- the final check is
isHotkeyPressed([""]), i.e. is "" in the internal pressed-keys set — and "" gets seeded into that set whenever any KeyboardEvent with an empty code is processed (pushToCurrentlyPressedKeys(mapKey(event.code))), which synthetic events dispatched by UI libraries do.
Once that happens, every bare modifier keydown fires the settings callback → openSettings() → Settings → General.
The display layer already hints somebody fought this before: formatKey special-cases "," and extractHotkey has an endsWith(",") guard — but the registration string was never fixed.
Reproduction
- PostHog Code 0.58.1, Windows 11 (should reproduce on macOS with bare ⇧/⌘ too — the bug is platform-independent).
- Use the app normally for a bit (opening the command menu / any Radix-style popover is enough to get a synthetic
code: "" event processed).
- Tap Right Shift or the Windows key on the main view.
- App navigates to Settings → General.
Also note: because the comma got eaten by the splitter, the intended shortcut Ctrl+, is only working via the native menu accelerator (CmdOrCtrl+,), not via the renderer hotkey registration.
Fix
One line — react-hotkeys-hook's documented spelling for the comma key is comma:
Plus a tiny follow-up in the shortcuts-sheet formatter so it still renders as Ctrl+, / ⌘, (formatKey currently only special-cases the literal ","):
if (k === "comma") return ","
(Alternative: pass a custom splitKey to useHotkeys, but the comma spelling is the minimal change.)
Verification
I byte-patched exactly this change ("mod+," → "mod+comma" + the formatKey branch) into the shipped renderer bundle of my local 0.58.1 install: bare Right Shift / Win no longer navigate to settings, and Ctrl+, still opens them. So the one-liner above is a confirmed fix, not a hypothesis. (It also means I get to re-patch after every auto-update, which is why I'd love this upstreamed 🙂)
Created with PostHog Code
Summary
Pressing a bare modifier key — Right Shift, the Windows key, and friends — navigates the desktop app to Settings → General. No chord, just tapping Shift while (for example) thinking about what to type next.
Root cause
SHORTCUTS.SETTINGSis defined as"mod+,"inpackages/ui/src/features/command/keyboard-shortcuts.ts:That string is passed to react-hotkeys-hook's
useHotkeys(in the global event handlers and on the AI-approval screen). But,is react-hotkeys-hook's default hotkey-list separator (splitKey). The library doeskeys.split(",")before parsing, so"mod+,"never registers Ctrl+Comma at all — it registers two degenerate hotkeys:"mod+"→{ mod: true, keys: [""] }""(empty string) →{ keys: [""] }— no key, no modifiersInside the library's matcher (
isHotkeyMatchingKeyboardEvent), a keydown of a bare modifier passes every gate for these degenerate hotkeys:mapKey(e.code)for a modifier ("shift","meta", …) is in the matcher's modifier allowlist;pressedKey === "shift"etc.);isHotkeyPressed([""]), i.e. is""in the internal pressed-keys set — and""gets seeded into that set whenever anyKeyboardEventwith an emptycodeis processed (pushToCurrentlyPressedKeys(mapKey(event.code))), which synthetic events dispatched by UI libraries do.Once that happens, every bare modifier keydown fires the settings callback →
openSettings()→ Settings → General.The display layer already hints somebody fought this before:
formatKeyspecial-cases","andextractHotkeyhas anendsWith(",")guard — but the registration string was never fixed.Reproduction
code: ""event processed).Also note: because the comma got eaten by the splitter, the intended shortcut Ctrl+, is only working via the native menu accelerator (
CmdOrCtrl+,), not via the renderer hotkey registration.Fix
One line — react-hotkeys-hook's documented spelling for the comma key is
comma:Plus a tiny follow-up in the shortcuts-sheet formatter so it still renders as
Ctrl+,/⌘,(formatKeycurrently only special-cases the literal","):(Alternative: pass a custom
splitKeytouseHotkeys, but thecommaspelling is the minimal change.)Verification
I byte-patched exactly this change (
"mod+,"→"mod+comma"+ theformatKeybranch) into the shipped renderer bundle of my local 0.58.1 install: bare Right Shift / Win no longer navigate to settings, and Ctrl+, still opens them. So the one-liner above is a confirmed fix, not a hypothesis. (It also means I get to re-patch after every auto-update, which is why I'd love this upstreamed 🙂)Created with PostHog Code