Forking sessions

Thanks for filing this request! I’ve put together a --fork design and would love feedback before implementing it.

Proposal Summary

• Add a boolean --fork flag (short -f, default off) to codex resume.
• When --fork is set, the CLI always creates a new branch from the chosen session before launching—whether the user goes through the picker, uses --last, or passes a session ID argument.
• The original session remains untouched; the forked session is appended to the recent sessions list so it can be resumed later.

Detailed Behaviour

1. Picker mode

codex resume --fork shows the session list; when the user confirms a selection, the CLI forks the session and starts the new branch.
If the command ends with an optional [PROMPT], the new branch launches with that prompt.

1. Quick resume (--last)

codex resume --last --fork forks the most recent session and immediately drops into the new branch.
If resume gains additional filters later, we can still insert the fork step right after the target session is chosen—no extra compatibility code needed.

1. Direct session ID

codex resume <SESSION_ID> --fork (or --fork <SESSION_ID>) forks the specified session first, then resumes the new branch.
The optional [PROMPT] works exactly as it does today.

1. User feedback

In the TUI, display a banner such as “Starting a new fork (forked from …)” so it’s obvious we’re in a branch.
In pure CLI mode, print the new session ID after a successful fork.

Compatibility

• --fork doesn’t conflict with existing flags (--last, model/config overrides, positional session ID, etc.).
• Future filter options would only affect how we choose the candidate session; the actual fork logic remains isolated.

Implementation Notes

1. Extend ResumeCommand with a fork: bool field and update the clap definitions/help text.
2. Once the CLI resolves the target SessionMeta:

• If fork is false, keep the current resume flow.
• If fork is true, call the existing ConversationManager::fork_conversation to create the new session, then hand that meta to run_conversation.

1. In the picker code path, check the flag when confirming the selection and fork when needed; the --last and direct-ID paths share the same logic.
2. Update the TUI banner and CLI logging to make it clear we’re starting a forked session.

Validation Plan

• Automated tests covering codex resume --fork in the picker, --last, direct session ID, and other relevant paths.
• Manual testing with conversations that include rich content (e.g. images) to ensure forked sessions are saved and originals stay intact.
• Before opening a PR, run cargo fmt -- --config imports_granularity=Item && cargo clippy --tests && cargo test to keep the codebase clean.

Does this approach line up with what you’d expect? I’m happy to revise anything that seems off—just let me know, and once we have consensus I’ll start implementing it. Thanks!

Hi! I just submitted a PR to extend with a flag so that interactive sessions can branch without overwriting the original conversation. It covers TUI picker, , direct ID resumes, core tests, and docs updates. PR: https://github.com/openai/codex/pull/5047 . Happy to adjust if there's anything else you'd like to see.

Closing in favor of #4690, which has more upvotes

I'm sorry @Wangnov I wanted to say that I appreciate the effort you made. I would also love this feature, and was disappointed to see that this was closed.

@rissem, this issue was closed as a duplicate. If you haven't already done so, please upvote (add a thumbs-up reaction to) #4690. And if you think that it doesn't quite capture what you want to see, please post to it.

We generally prioritize features based on community feedback. Duplicate (or largely overlapping) feature requests dilute the upvote counts and make a feature less likely to rise to the top of the priority queue.

Thanks for your reply and I just added a 👍 to #4690. Is there anything beyond that that I can do to get this feature integrated sooner? Or perhaps you know of forks that are more accepting of community contributions?