What version of Codex CLI is running?

codex-cli 0.130.0

What subscription do you have?

Pro

Which model were you using?

Any

What platform is your computer?

Darwin 24.6.0 arm64 arm

What terminal emulator and version are you using (if applicable)?

Any terminal tested/observed, including Ghostty and VS Code terminal.

Codex doctor report

N/A

What issue are you seeing?

In the CLI, Esc has conflicting meanings while a /side conversation is focused.

If the main thread is working, I can open /side, start work in the side conversation, then submit a queued steering/follow-up prompt while the side conversation is still working. The UI shows the normal queued-message hint saying the message will be submitted after the next tool call, and that pressing Esc will submit it immediately.

However, because the active UI is a /side conversation, pressing Esc returns to the main thread / dismisses the side chat instead of submitting the queued steering prompt. Since /side conversations are ephemeral and currently not stored in session logs, this can lose the side-chat context and the queued prompt. See #20262 for the related persistence issue: #20262

There is also a race/bounce problem. If the side-chat work completes just before the user presses Esc, the user's intent is still "submit the queued steer immediately," but the actual action becomes "close the side chat." That makes the same visible user action switch from submitting work to discarding the side conversation based on timing the user cannot reliably perceive.

This is different from cases where Esc is not received by the terminal. Esc is received, but the /side "return to parent" handler appears to win over, or race with, the queued-message "submit immediately" action.

What steps can reproduce the bug?

1. Start a Codex CLI session.
2. Submit a prompt in the main thread that keeps the main thread working long enough to interact with the UI.
3. Run /side while the main thread is still working.
4. In the side conversation, submit a prompt that starts work in the side conversation.
5. While the side conversation is working, type a steering/follow-up message so the UI shows the queued-message prompt:
   Messages to be submitted after next tool call (press esc to interrupt and send immediately)
6. Press Esc.
7. Observe that Esc can return from/dismiss the side chat instead of submitting the queued side-chat message immediately.
8. If the side-chat work completes just before Esc is processed, observe the bounce/race: the same Esc keypress closes /side even though the user pressed it in response to the "submit immediately" hint.

What is the expected behavior?

Esc should not silently choose the lossy /side dismissal behavior when the UI is advertising Esc as "submit immediately" for a queued message.

A reasonable behavior would be:

• If a queued message/steering prompt is pending in the focused side conversation, Esc should submit that queued prompt immediately to the focused side conversation.
• Returning from /side should only happen when there is no pending queued prompt, or should require a separate action such as a second Esc.
• If the queued prompt is no longer actionable because the turn completed just before Esc was handled, the CLI should avoid treating that same Esc as an implicit request to close/discard the side chat.
• If leaving /side would discard non-persisted side-chat state, the CLI should avoid data loss: preserve the side chat, make it recoverable, or confirm before discarding unsaved side-chat content.

Additional information

Related but not duplicate issues:

• Store /side chats in session logs #20262 asks to store /side chats in session logs. This bug is higher severity while /side remains ephemeral, because an accidental Esc can lose the side-chat context.
• Messages to be submitted after next tool call (press esc to interrupt and send immediately) not working on CLI #17095 reports Esc not submitting queued messages generally in one terminal. This issue is different: Esc is handled, but it is handled as /side dismissal.
• TUI mixes queued follow-ups with removed steer state, causing "pending steer" leakage and delayed execution #13892 reports queued follow-up / pending steer state confusion in the TUI.
• /side while working and then escaping back to the main thread breaks the working-timer #21168 is a closed CLI /side + Esc issue, but it covered the working timer resetting, not queued-message submission or side-chat data loss.
• Side chat queued/steer messages route to main chat, and closed side chats are lost #21583 covers similar side-chat loss/routing concerns in Desktop, not the CLI /side Esc keybinding collision.