CLI: Esc can dismiss `/side` instead of submitting queued steering, losing side-chat context

This is by design. Side conversations are not intended for substantive work. They're intended for simple side questions. They are limited in what they can do; for example, many slash commands are not available.

I'll change this from a bug report to an enhancement request and keep it open to see if we get similar feedback from other codex users.

I don't mind how this is classified. Bug / Feature. From my perspective the problem here is there's a prompt at the bottom of the screen that says Esc will do one thing (submit a message immediately), but which actually does something else (closes the side chat) which lost actual important work and means that now I can't trust that the UI will do what it says it will do.

This is not a hypothetical situation. I was in the middle of something substantive on an intentional side conversation. Regardless of whether /side is intended to be used this way, the problem of that framing is that it assumes that we will always only know when substantive work happens up front.

Obv. your call on how this works, but perhaps consider disabling the Esc to submit immediately message or something like that to avoid this from being a data loss event.

As a general rule though, I have a strong opinion that all chats with codex should result in a session log, so I'd push back on /side being generally ephemeral being an answer to this from that perspective see https://github.com/openai/codex/issues/20262

Right now, I'm fine with this not being worked on, I know that this bug/feature works this way, so I'd avoid this path as a sharp edge.

/side is not meant to be used for something substantive. It's meant for quick lightweight questions. If you need to do something substantive and want persistence, there are other tools you can use like /fork.

From my perspective the problem here is there's a prompt at the bottom of the screen that says Esc will do one thing (submit a message immediately), but which actually does something else (closes the side chat)

I've encountered a variant of this behaviour that I also find disruptive: I can't interrupt the agent to correct a prompt in a /side chat by pressing esc.

It seems that ctrl-c and ctrl-d both close the /side chat, analogously to closing a sub-shell. So perhaps the esc binding could simply be removed in favour of advertising one of those other two bindings?

/side is not meant to be used for something substantive. It's meant for quick lightweight questions. If you need to do something substantive and want persistence, there are other tools you can use like /fork.

I think the “intended use” framing is doing too much work here.

I understand the argument that /side is meant for lightweight questions rather than substantive work, and I’m not trying to litigate whether this is a bug or an enhancement. But “not intended for substantive work” does not fully answer the product problem.

A feature can be “not intended for substantive work” and still be badly designed if it invites substantive work and then makes losing it easy.

That is the distinction I think matters here: misuse is different from foreseeable use. /side is a chat interface, opened inside the current session, with access to the current context, capable of producing useful work. It is very foreseeable that users will occasionally do something meaningful there, even if that was not the original design intent.

“Intended use” defines the happy path, but good product design also accounts for foreseeable use. If a product makes a behavior natural, productive, and only weakly marked as unsafe, then failures in that behavior are not simply user error. They are affordance failures, expectation failures, or data-loss safety failures.

The sharper issue here is that the UI advertises one meaning for Esc, but the focused mode can interpret Esc as something else. In this case, the queued-message hint says Esc will submit the message immediately, but in /side the same key can instead dismiss the side conversation. Because /side is ephemeral and not stored in the session log, that turns a keybinding ambiguity into a data-loss path.

That is not just “the user used /side for the wrong thing.” The product showed a prompt, the user followed the prompt, and the result could be losing work.

I think a better product principle is:

Products are responsible not only for intended workflows, but also for foreseeable misuse created by their own affordances.

In this case, any of these would reduce the sharp edge:

• persist /side chats in the session log
• make discarded side chats recoverable
• require confirmation before closing a non-empty, non-persisted side chat
• remove or change the Esc hint while /side is focused
• make Esc submit the queued message when the UI says it will
• reserve a separate keybinding for “leave side chat”

I don’t think this requires making /side a full replacement for /fork. It just means the product should not make an ephemeral workspace look and behave like a normal chat, allow valuable work to happen there, and then silently discard it through an ambiguous or timing-sensitive keypress.

Put another way: when a product creates an attractive footgun, the injury is not explained away by saying the user pulled the trigger wrong.

We received similar feedback from several other users. This will be addressed in the next release.

I was unconsciously trying to go back to the conversation by pressing Esc, but I was immediately ejected without any notice, which dropped my mood to the bottom. Honestly, if you really want to do it in a semantic conflict, at least give a secondary pop-up window. If the design of the library is not elegant enough, it would be better to pop up a secondary confirmation window on the first press of Esc and then use Y/N to close. I don't think it's necessary to keep the content of side, but the unannounced exit and loss of conversation due to semantic conflict is completely unacceptable. You should understand the importance of this.