Double-Esc triggers conversation rewind too easily and lacks a safety mechanism

Confirmed that the underlying UX problem is still present in codex-cli 0.145.0 on Linux (x86_64).

The current flow is now safer than the original report in one respect: Esc Esc opens a transcript picker, and no branch is persisted until an older prompt is edited and submitted. However, the key-state behavior remains surprisingly easy to trigger by accident:

1. First Esc: arms “edit previous message”.
2. Second Esc: opens the transcript overlay.
3. Once the overlay opens, every additional Esc is immediately reinterpreted as “select the previous editable user message” (the same action as Left).
4. Right selects the next editable user message, while Up/Down scroll the transcript rather than changing the selected message.
5. Enter chooses the highlighted prompt for editing; submitting it creates a new conversation branch.

This is especially error-prone when the TUI is slow to redraw. A user may press Esc three or four times because the UI has not visibly reacted yet. Those queued keypresses cross the mode transition and silently move the selection farther back than intended. The footer does document the controls, but users should not need to infer that repeated presses of the conventional “cancel/back” key become a destructive-range navigation command after a delayed state transition.

This had a material impact in my case: one ordinary CLI conversation accumulated a linear chain of five descendant forks. Local rollout metadata confirmed that these were real TUI-created branches (forked_from_id), not duplicate list rendering or mobile/remote activity.

There is also an intermittent, not-yet-deterministic failure mode: after pressing Esc too many times and then Enter, Codex has occasionally exited outright. I have not reduced that part to a reliable minimal reproduction, so I am mentioning it as an observation rather than claiming a confirmed root cause.

Possible improvements:

• Consume or debounce queued Esc events across the transition into the transcript overlay.
• Make Esc close/cancel the overlay instead of selecting an older prompt.
• Use Up/Down for prompt selection and PgUp/PgDn for transcript scrolling, or make this configurable.
• Show a conspicuous confirmation that submitting the edited prompt will create a new conversation branch.
• Keep Left/Right as optional previous/next shortcuts, but do not make them the only selection controls.

The issue is not that the current controls are completely undocumented; it is that the same key changes from “open/cancel” to “move farther back” across a potentially slow redraw boundary, which makes accidental rewinds and branch proliferation unusually easy.

This matches my workflow as well. I often use Esc repeatedly as a cancel/normal-mode key, and in a slow or busy TUI those queued keypresses can cross the transition into the transcript picker. The result is an unintended rewind/fork rather than a no-op or a visible confirmation.

Requested UX:

• Treat the first Esc Esc as opening the transcript picker only.
• Do not change the active conversation or create a branch until the user explicitly selects a checkpoint and confirms/submits.
• While the picker is opening, consume/debounce additional queued Esc events.
• In the picker, make Esc consistently cancel/close; use explicit navigation keys for checkpoint selection.
• Show a clear confirmation that submitting an earlier prompt creates a new conversation branch.

This would provide the Claude Code-style convenience without making accidental context rewinds easy to trigger.