What version of Codex CLI is running?
codex-cli 0.144.0
What subscription do you have?
Pro
Which model were you using?
No response
What platform is your computer?
Darwin 25.5.0 arm64 arm
What terminal emulator and version are you using (if applicable)?
Warp
Codex doctor report
What issue are you seeing?
The Codex CLI documentation says that pressing Esc twice with an empty composer allows editing a previous user message and “forking” the conversation from that point. However, the behavior does not seem to create a separate, resumable fork.
After selecting and editing an earlier user message, the current session appears to continue from the edited point, and the original conversation path is no longer available through resume. This makes the feature behave more like rewriting/backtracking the current session rather than creating a real fork.
What steps can reproduce the bug?
Start a Codex CLI interactive session.
Send several user messages and let Codex respond to them.
Make sure the composer is empty.
Press Esc twice to enter previous-message editing/backtracking mode.
Continue pressing Esc until an earlier user message is selected.
Press Enter to edit that earlier message.
Modify the message and submit it.
Try to return to the original conversation path using codex resume or the resume UI/list.
Observed result: the original session/path cannot be found or resumed. The edited path appears to replace or overwrite the current session history instead of creating a separate fork.
What is the expected behavior?
If the feature is described as “forking” the conversation, the original session should remain preserved and resumable.
Expected behavior would be one of the following:
A new session/task ID is created for the edited branch.
The original session remains available through codex resume.
The forked session and the original session are both visible and distinguishable in the resume list.
The UI clearly communicates whether the action is a destructive rewind/edit or a non-destructive fork.
Currently, the behavior is confusing because the documentation implies a non-destructive fork, but the original conversation path appears to be lost or inaccessible.
Additional information
The OpenAI Codex CLI documentation describes this behavior as a fork:
“Press Esc twice with an empty composer to edit the previous user message and fork the conversation from that point.”
Documentation reference:
https://learn.chatgpt.com/docs/developer-commands?surface=cli#cli-interactive-shortcuts
This wording suggests that the original conversation should remain available after forking. If the intended behavior is actually to rewrite/backtrack the active session, the documentation should be updated to avoid using “fork,” or the CLI should create a separate resumable session when editing from an earlier message.
What version of Codex CLI is running?
codex-cli 0.144.0
What subscription do you have?
Pro
Which model were you using?
No response
What platform is your computer?
Darwin 25.5.0 arm64 arm
What terminal emulator and version are you using (if applicable)?
Warp
Codex doctor report
What issue are you seeing?
The Codex CLI documentation says that pressing Esc twice with an empty composer allows editing a previous user message and “forking” the conversation from that point. However, the behavior does not seem to create a separate, resumable fork.
After selecting and editing an earlier user message, the current session appears to continue from the edited point, and the original conversation path is no longer available through resume. This makes the feature behave more like rewriting/backtracking the current session rather than creating a real fork.
What steps can reproduce the bug?
Start a Codex CLI interactive session.
Send several user messages and let Codex respond to them.
Make sure the composer is empty.
Press Esc twice to enter previous-message editing/backtracking mode.
Continue pressing Esc until an earlier user message is selected.
Press Enter to edit that earlier message.
Modify the message and submit it.
Try to return to the original conversation path using codex resume or the resume UI/list.
Observed result: the original session/path cannot be found or resumed. The edited path appears to replace or overwrite the current session history instead of creating a separate fork.
What is the expected behavior?
If the feature is described as “forking” the conversation, the original session should remain preserved and resumable.
Expected behavior would be one of the following:
A new session/task ID is created for the edited branch.
The original session remains available through codex resume.
The forked session and the original session are both visible and distinguishable in the resume list.
The UI clearly communicates whether the action is a destructive rewind/edit or a non-destructive fork.
Currently, the behavior is confusing because the documentation implies a non-destructive fork, but the original conversation path appears to be lost or inaccessible.
Additional information
The OpenAI Codex CLI documentation describes this behavior as a fork:
“Press Esc twice with an empty composer to edit the previous user message and fork the conversation from that point.”
Documentation reference:
https://learn.chatgpt.com/docs/developer-commands?surface=cli#cli-interactive-shortcuts
This wording suggests that the original conversation should remain available after forking. If the intended behavior is actually to rewrite/backtrack the active session, the documentation should be updated to avoid using “fork,” or the CLI should create a separate resumable session when editing from an earlier message.