Allow forward navigation in “Edit/resume conversation” (Esc–Esc) overlay
Resolved 💬 7 comments Opened Aug 27, 2025 by mkusaka Closed Nov 27, 2025
💡 Likely answer: A maintainer (aibrahim-oai, contributor)
responded on this thread — see the highlighted reply below.
What feature would you like to see?
Add a keybinding to move to the next (newer) user message while in the “Edit/resume conversation” transcript overlay (invoked via Esc–Esc). Today, pressing Esc only steps backward to older messages. There is no way to step forward to newer messages without closing the overlay and starting over.
Are you interested in implementing this feature?
Potentially yes, if the approach is accepted. For example, consider one of these options (avoiding conflicts with existing scroll keys):
- Shift+Esc to step forward (symmetry with Esc for backward)
- Left/Right arrows for forward/backward selection
- Tab/Shift+Tab for next/previous selection
Additional information
The overlay and “Edit/resume conversation (Esc–Esc)” flow shipped in 0.24.0. The footer shows “Esc edit prev” and “⏎ edit message”, but does not expose a command to move forward to a newer selection.
7 Comments
Do you think you can implement this?
Yes — I can implement this. I prototyped forward navigation (Shift+Esc forward, Esc backward) in the transcript overlay, and it works well on my setup (macOS Terminal, iTerm2, tmux).
One caveat: Esc is historically sent as bare 0x1B, so some terminals/settings don’t report Shift—making Shift+Esc indistinguishable from Esc. Codex enables crossterm’s KeyboardEnhancementFlags (DISAMBIGUATE_ESCAPE_CODES / REPORT_EVENT_TYPES / REPORT_ALTERNATE_KEYS), so on terminals that support CSI u / modifyOtherKeys the keys are distinguishable. References:
This feature request has received only one upvote in three months, so I'm going to close it.
Would love to see forward navigation added to the Esc–Esc "edit previous message" overlay. Right now we can only step backward; having a key (e.g., ↓/Tab) to move to newer messages would restore parity with the /rewind flow we had in Claude Code and make backtracking edits much smoother.
codexCLI utility is wonderful. I think this is the most relevant missing feature that I have found so far. Mainly because it is probably a relatively straightforward modification to the code with high benefit for the little effort. I am sure that you can ask Codex to self-implement this feature in its own code.In any case, I want to send my love for the Codex CLI interface!
@alberti42, thanks for the feedback. Would you be willing to open a new feature request? This one received relatively few upvotes or follow-on posts, which means that it didn't resonate with many Codex users. That might be because of the original title or description, so it can be beneficial to start fresh with a new feature request that might garner more interest.
Yes, I will do it in the next days!