Codex Desktop: Cmd+1..9 selects the wrong pinned chat after unified sidebar migration

Start by tracing the thread1..thread9 command registration and dispatcher selection in the unified sidebar and legacy shortcut registrars. Compare the visible unified-sidebar order with the legacy loaded-thread order, including pinned-thread-ids and unified-sidebar-pinned-order-v1 filtering. Done means Cmd+N consistently opens the Nth currently visible chat without losing pins.

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

26.727.40816 (Build 6067)

What subscription do you have?

Not specified

What platform is your computer?

macOS — Darwin 25.5.0 arm64

What issue are you seeing?

In the unified Codex Desktop sidebar, Cmd+1 does not open the first visible pinned chat. It opens the sixth visible pinned chat instead. Other Cmd+number shortcuts are also mapped to the wrong visible positions.

This is not a keyboard-layout or custom-keybinding problem: Cmd+1 is correctly dispatched as the thread1 command, but the command resolves its target from a different thread ordering than the one rendered in the sidebar.

No chats or pins are lost. The bug affects shortcut target selection only.

What steps can reproduce the bug?

1. Open Codex Desktop in the unified sidebar/project layout.
2. Pin several chats and arrange them in a visible manual order.
3. Press Cmd+1.
4. Observe that Codex opens the sixth visible pinned chat instead of the first.
5. Press other Cmd+number shortcuts and observe that they also select chats according to a different ordering.

The issue remains reproducible with no custom thread1..thread9 keybindings configured.

What is the expected behavior?

Cmd+N should open the Nth currently visible chat in the sidebar. This matches the behavior proposed in #11832: the shortcut index should follow the currently visible thread-list order.

Additional information

Read-only local inspection found:

• Cmd+1..9 are correctly registered as thread1..thread9.
• Desktop state contains two divergent pinned-order sources: pinned-thread-ids and unified-sidebar-pinned-order-v1.
• The current renderer mounts both the unified-sidebar shortcut registrar and a legacy shortcut registrar.
• The command dispatcher chooses among multiple active handlers by registration order.
• Runtime navigation matches the legacy loaded-thread order rather than the visible unified-sidebar order.
• The unified pinned-order state also contains stale client-new-thread entries, which are filtered differently from the legacy pinned IDs.

Suggested fix direction:

• When the unified sidebar is enabled, register only the visible-order shortcut handler.
• Alternatively, make both handlers consume the same visible shortcut target list.
• Migrate or reconcile the two persisted pinned-order representations.

Feedback ID: no-active-thread-019fb6f6-4dff-7410-b9d5-2ceb57df6d50

Related issues:

• #11832 — original Cmd+1..9 visible-thread behavior request
• #35090 — related sidebar ordering/cache problem after pin/unpin, but not the same shortcut regression