How to fork a Claude Code or Codex session to try another approach

The agent has a plan, and it's halfway through. You want to see what the other approach looks like, the one you talked it out of an hour ago. If you ask in the same session, you pollute the context it has built up. If you start a new session, you lose that context.

A fork gives you both. It copies the conversation so far into a new session, and the original stays exactly where it was:

• Claude Code, inside a session: /branch. You're moved into the copy, and the original can be resumed later.
• Claude Code, from the shell: claude --resume <session-id> --fork-session.
• Codex, inside a session: /fork. From the shell: codex fork <session-id>, or codex fork --last.
• Grok Build, inside a session: /fork, which can also put the fork in its own git worktree. From the shell: grok --resume <session-id> --fork-session.
• The catch: a fork copies the conversation, not your files. Two sessions editing the same checkout will step on each other. Give the fork its own git worktree.

When should I fork instead of just continuing?

Fork when you want to keep the current thread intact:

• Trying a different approach. The fork explores the alternative. If it doesn't work out, the original session still has the plan it was following, untouched.
• Comparing two approaches. Fork, then let each session build its version in its own worktree. Compare the diffs, not the arguments.
• Asking a side question. A tangent that isn't worth keeping in the main context: how some library works, or a quick review of one file.

If you just want to undo the last few steps, you don't need a fork. Claude Code's /rewind (also /checkpoint) restores the conversation, the code, or both to an earlier message.

How do I fork a Claude Code session?

Inside a running session, type:

/branch try-event-queue

Claude Code copies the conversation into a new session and switches you into it. The name is optional. The fork's title ends in "(Branch)", so it's easy to tell apart in /resume. The confirmation message includes the command to get back to the original, claude -r <original-session-id>.

From the shell, add --fork-session to a resume:

# Fork the most recent session in this directory
claude --continue --fork-session

# Fork a specific session
claude --resume <session-id> --fork-session

Without --fork-session, both commands reopen the original session and keep adding to it.

How do I fork a Codex session?

Inside a running session, type /fork. From the shell:

# Pick a session to fork from a list
codex fork

# Fork the most recent session in this directory
codex fork --last

# Fork a specific session
codex fork <session-id>

Like codex resume, the picker and --last only look at sessions from the current directory. Add --all to see every directory.

Codex has two more ways to branch. Press Esc twice to step back through your earlier prompts, pick one, and press Enter. Codex forks the conversation just before that prompt and puts the prompt back in the composer for you to edit. The original session keeps the full history. For a quick tangent, /side starts a side conversation in a temporary fork.

How do I fork a Grok Build session?

Inside a running session, type:

/fork --worktree

Grok copies the conversation into a new session and switches you to it. With --worktree, the fork runs in a new git worktree under ~/.grok/worktrees/, and Grok copies your uncommitted changes into it, so the fork starts with the same files you have. The worktree starts on a detached HEAD, so create a branch there (git switch -c try-event-queue) before you commit anything you want to keep. --no-worktree keeps the fork in the current directory. With neither flag, Grok asks each time; fork_worktree_mode under [hints] in ~/.grok/config.toml sets the default. Anything you type after the flags becomes the fork's first prompt, as in /fork --worktree try an event queue instead.

Grok prints the new session's ID next to the one it came from. /dashboard switches between the two, and grok --resume <session-id> reopens either one later.

From the shell, add --fork-session to a resume:

# Fork the most recent session in this directory
grok --continue --fork-session

# Fork a specific session
grok --resume <session-id> --fork-session

--fork-session can't be combined with --worktree. To fork into a worktree from the shell, create one first with cd "$(grok worktree create try-event-queue)", then run the resume there.

Does forking a session copy my code?

No. A fork copies the conversation. Both sessions still work in the same directory, on the same files. If the original agent is editing src/queue.ts while the fork rewrites it, you get a mess that neither of them planned.

Give the fork its own git worktree. A new worktree starts from your last commit, not from the files on disk, so uncommitted edits and new files don't come along. If the agent has been working for a while, commit first:

git add -A && git commit -m "wip: before fork"

You can squash or amend that commit later. Without it, the fork remembers changes that its worktree doesn't have. Grok's /fork --worktree is the exception: it copies uncommitted changes into the new worktree, so you can skip the commit there. Like Codex's, its worktree starts on a detached HEAD, so create a branch in it before committing. If you've used claude --worktree in this repo before, add .claude/worktrees/ to .gitignore first, or git add -A will pick up those worktree folders too.

Then fork into a worktree. Both CLIs can create one for you:

# Claude Code: fork into a new worktree under .claude/worktrees/try-event-queue
claude --worktree try-event-queue --resume <session-id> --fork-session

# Codex: fork into a new worktree under ~/.codex/worktrees
codex fork --worktree <session-id>

Claude Code puts its worktree on a new branch named worktree-<name>. Codex needs an explicit session ID here, since --last doesn't work with --worktree, and its worktree starts on a detached HEAD, so create a branch there (git switch -c try-event-queue) before you commit anything you want to keep.

Or create the worktree yourself and fork from inside it:

git worktree add ../myapp-event-queue -b try-event-queue
cd ../myapp-event-queue
claude --resume <session-id> --fork-session

The fork still has the whole conversation, even though it now runs in a different directory. When one approach wins, merge its branch and remove the other worktree by path, for example git worktree remove ../myapp-event-queue. git worktree list shows the paths, including the ones Claude Code and Codex created.

How do I keep track of which session is which?

Forks look alike in a session list, since they start from the same conversation. Name them when you create them:

• Claude Code: /branch <name>, or /rename inside any session.
• Codex: /rename inside the session.
• Grok Build: /rename <title> inside the session.

A name that says what the fork is trying, such as "event queue" or "keep polling", makes the right session easy to find in claude --resume, codex resume, or Grok's /resume a day later.

Can I fork without typing session IDs?

Yes. In PonyMux, select a Terminal that's running Claude Code, Codex, or Grok, open the Inspector, and click Fork Session in the Session section. The same action is in each session's ⋯ menu in the Sessions panel.

The Inspector's Session section for a Claude Code session. Fork Session is right above Handoff.

PonyMux asks where to put the fork:

• Here ends whatever is running in the current Terminal and starts the fork in its place.
• New Terminal opens the fork next to the original, in the same list.

It runs claude --resume … --fork-session, codex fork …, or grok --resume … --fork-session for you, in the session's working directory. The fork's row in the Sessions panel is marked fork. With Here, it sits in the same Terminal's list as the session it came from. With New Terminal, the source stays in the original Terminal's list.

PonyMux doesn't create a worktree for the fork, and it always starts the fork in the original session's working directory. If the two sessions will edit files, commit first as described above, create the worktree yourself, open a Terminal in it, and run claude --resume <session-id> --fork-session there, or use codex fork --worktree or Grok's /fork --worktree. A session needs at least one saved exchange before it can be forked.

You also don't need to remember which session was which. Each PonyMux Terminal keeps a timeline of every Claude Code, Codex, and Grok session that has run in it. Open the Sessions panel to see them, with their titles, recaps, and when each was last used. Click Resume on any row to go back to that exact session, not just the most recent one.

The Sessions panel lists every conversation that has run in this Terminal. Resume reopens the one you pick.

Resume needs the agent's transcript to still be on disk. Claude Code deletes transcripts after 30 days by default; see Claude Code conversation history for how to keep them longer.

For the details of Resume, Fork, and Handoff, see the Sessions docs. To move a task to the other agent instead of copying it, see How to hand off a task from Claude Code to Codex.

Originally published on ponymux.com, where the demos are interactive.