Claude Code Fork: Branch a Session From a Shared Baseline
Claude Code fork branches the current session state so you can explore two approaches from the same starting point. Here is how session forking works, how it differs from a Git fork, and how to record the outcome.
Updated 5 min read
In Claude Code, forking a session creates a copy of the current conversation and file state so you can pursue two different approaches from the same point. One path continues in the original session and one in the fork, both beginning from identical context. You compare the results, then keep the approach that worked.
The decision about which approach to accept belongs in a lasting record, not in whichever session window you happened to keep open. Tools like fenbs keep that decision — what was tried, what was chosen, and why — so the next assistant knows the outcome without having to infer it from file history.
How is a session fork different from a Git fork?
A Git fork creates a copy of a repository for a separate development line. It is about code ownership and branching strategy. A Claude Code session fork creates a copy of the AI conversation state and the current working files, so two sessions can try different solutions to the same task from the same moment.
Session forks work at the level of the Claude Code conversation and the files on disk at the point of forking. They do not create Git branches unless the instructions in the session explicitly do so. If you want the exploration to be visible in version control, create a Git branch before or alongside forking the session.
How do you fork a Claude Code session?
Claude Code checkpoint and fork behavior is described in Anthropic's Claude Code documentation (opens in a new tab). The basic flow is: save a checkpoint at the point you want to branch, then start a second session that resumes from that checkpoint. Each session can now take a different direction.
/checkpoint save before-approach-a
Once the checkpoint exists, open a second Claude Code session in a separate terminal or window and restore from that checkpoint. Both sessions now share the same starting state. Give each one a different instruction and let them run. The session working in the original window is one fork; the second terminal is the other.
What makes a good baseline for forking?
Fork from a clean, confirmed state. The baseline should be a point where the tests pass, the existing requirements are met, and the next step is genuinely uncertain. Forking from a broken state means both paths start with the same unresolved problem, which defeats the purpose of comparing independent solutions.
Describe the goal for each fork clearly before starting. "Approach A: refactor the cache layer using a map. Approach B: replace the cache layer with a third-party library." Both sessions need a precise instruction that differs from the other, or the comparison is not useful.
How do you compare the resulting approaches?
After both sessions finish, review each result against the same criteria. Running the same test suite on both is the clearest comparison when tests exist. Otherwise, compare the diff size, readability, and how closely each approach matches the design guidelines. Do not rely on the AI's self-assessment; it is not a neutral judge of its own work.
- Run the same tests on both. A pass on one and a failure on the other is a clear signal.
- Read both diffs with the project's code style in mind. Correctness and readability matter independently.
- Check that neither approach silently changes the behavior of untouched code. A side effect outside the stated scope is a reason to look more carefully.
- Consider maintainability. Which result would a teammate understand in six months without the session transcript?
How do you record the accepted approach?
Once you choose an approach, the reasoning behind the choice is as important as the choice itself. A future assistant touching the same code needs to know not just what was done but why the alternative was rejected. Without that context, it may undo a deliberate decision by accident.
Record the baseline state, the two approaches tried, and the reasoning for the accepted one as a fenbs decision on the relevant task. If the reason applies to future similar tasks — "always prefer the standard library over a new dependency for cache management" — it becomes a standing rule in Decisions and rules.
Record the baseline and the accepted outcome
Add the fork decision to the fenbs task before closing either session. Note what each approach tried and why you accepted one. If the reasoning is a rule that should apply to future work, save it as a standing rule in Decisions and rules so the next assistant reads it before making a similar choice.
Create a free accountFree for one person · No credit card · Works with Claude, ChatGPT, Cursor and more
How to do this with fenbs
- Create a free account and open the task you plan to fork.
- Write the comparison criteria in the task plan before forking. That way both sessions are evaluated against the same standard.
- Save a Claude Code checkpoint at the baseline. Start both sessions and give each one a clearly different instruction.
- After reviewing both results, record the accepted approach and its reason as a decision on the fenbs task. If the reason is a project-wide rule, add it to Decisions and rules.
- Connect your next Claude Code session to fenbs from Integrations. Ask it to read the project context before continuing work from the accepted approach.
fenbs does not run or manage Claude Code sessions. It keeps the record of what was decided and why. For the underlying checkpoint mechanism, the Claude Code checkpoints guide explains save and restore in detail. For working with multiple parallel sessions on separate file trees, the worktrees guide is the companion read.