Codex App [bug]: Quick Chat shortcut opens a full new chat when sidebar is hidden
What version of the Codex App are you using?
Codex Desktop 26.818.21641 on macOS arm64.
What issue are you seeing?
The documented Quick Chat shortcut (Cmd + Option + N) behaves differently depending on whether the left sidebar is visible.
- With the sidebar visible,
Cmd+Option+Ncorrectly opens Quick Chat in the small popup/overlay. - With the sidebar hidden, the same shortcut opens a new full chat in the main window, replacing the currently visible chat instead of opening Quick Chat.
This makes the shortcut state-dependent and interrupts the current workflow when the sidebar is collapsed.
The current shortcut reference documents these as separate commands:
- Quick chat:
Cmd+Option+N - New chat:
Cmd+NorCmd+Shift+O
Reference: https://learn.chatgpt.com/docs/reference/commands
Steps to reproduce
- Open Codex on macOS and open an existing chat.
- Leave the left sidebar visible.
- Press
Cmd+Option+N. - Observe that Quick Chat opens in the small popup/overlay as expected.
- Close Quick Chat.
- Hide the left sidebar (
Cmd+B). - Press
Cmd+Option+Nagain. - Observe that Codex navigates the main window to a new full chat instead of opening Quick Chat.
Expected behavior
Cmd + Option + N should always invoke Quick Chat regardless of sidebar visibility. Hiding the sidebar should not change the semantic meaning of the shortcut or replace/navigate away from the current chat.
Actual behavior
Sidebar visible:
Cmd + Option + N → Quick Chat popup ✅
Sidebar hidden:
Cmd + Option + N → new full chat in main window ❌
Why this matters
Quick Chat is useful for asking a lightweight or tangential question without leaving or disturbing the current Codex thread. When the sidebar is hidden, the current behavior turns that lightweight action into a navigation/context switch.
Related issues
- #33731 — Quick Chat/sidebar entry regression on macOS
- #34098 — Quick Chat/sidebar entry regression on Windows
- #33977 — sidebar keyboard handling interfering with Quick Chat on macOS
I could not find an existing issue for this exact sidebar-hidden shortcut routing behavior.