Skip to content
Datfx Labs Claude Guide

Branch: Fork a Session

/branch creates a fork of your current Claude Code conversation — a new session that starts from the same context, files, and history, but evolves independently. Think of it as git branching for your AI conversation: the original session is preserved exactly as it was, and the fork can go in a different direction.

Syntax

Terminal window
# Fork the current session (interactive)
/branch [name]


# Examples
/branch try-refactor-approach
/branch explore-graphql-alternative
/branch risky-migration


# Fork from CLI (resume a saved session at a fork point)
claude --resume <session-id> --fork-session


# List branches from the current session
/branch --list


# Switch back to original session
/branch --switch main

The name is optional but recommended — it makes it easier to identify branches when you have several active forks.

When to Use Branching

Trying a Risky Approach

You are about to ask Claude to do something irreversible or hard to undo — a large refactor, a schema migration, a wholesale rewrite of a module. You want to see the result before committing to it.

Fork first. If the approach works, keep the fork. If it doesn’t, the original session is untouched.

Exploring Alternatives in Parallel

You have two plausible architectural directions. Instead of asking Claude to try one, evaluate, then try the other sequentially (losing context each time), fork into two sessions and explore both simultaneously.

Isolating Experiments

You are deep into a debugging session and want to try a speculative fix that might make things worse. Fork, apply the fix in the fork, evaluate — without disturbing the known-good state of the original session.

How the Original Session Is Preserved

When you run /branch, Claude Code:

  1. Snapshots the current session state: conversation history, file context, tool results, memory
  2. Creates a new session initialized from that snapshot
  3. Continues the original session exactly where it was — no changes, no side effects

The fork and the original session share the snapshot as a read-only base. Changes made in either session after the fork are independent. Files written in the fork do not appear in the original session’s file context unless you explicitly merge or pull them.

Session Fork Flow

flowchart TD START([Session Start]) --> WORK["Working session\n(context builds up)"] WORK --> FORK{"/branch risky-approach"} FORK --> ORIG["Original session\n(preserved, unchanged)"] FORK --> NEW["Forked session\n(starts from same state)"] ORIG --> OR1["Continue original work"] NEW --> NR1["Try the risky approach"] NR1 --> NR2{Did it work?} NR2 -- Yes --> KEEP([Keep fork, discard original]) NR2 -- No --> DISCARD([Discard fork, return to original]) style START fill:#1e293b,color:#94a3b8,stroke:#334155 style WORK fill:#1e293b,color:#7dd3fc,stroke:#334155 style FORK fill:#1e293b,color:#fcd34d,stroke:#334155 style ORIG fill:#1e293b,color:#7dd3fc,stroke:#334155 style NEW fill:#1e293b,color:#7dd3fc,stroke:#334155 style OR1 fill:#1e293b,color:#7dd3fc,stroke:#334155 style NR1 fill:#1e293b,color:#7dd3fc,stroke:#334155 style NR2 fill:#1e293b,color:#fcd34d,stroke:#334155 style KEEP fill:#1e293b,color:#86efac,stroke:#334155 style DISCARD fill:#1e293b,color:#94a3b8,stroke:#334155

Example: Fork to Compare Refactor Approaches

You are refactoring a data-fetching layer. Two approaches are on the table: React Query or SWR. You want to see a real implementation of each before deciding.

Terminal window
# In your current session — context is loaded, you understand the codebase
/branch try-react-query
# Claude Code opens a new terminal tab with the forked session


# In the fork: try approach A
"Refactor all data fetching in src/hooks/ to use React Query.
 Keep the same external API — components should not need to change."


# Back in original session: try approach B
/branch try-swr
"Refactor all data fetching in src/hooks/ to use SWR.
 Keep the same external API — components should not need to change."

Both forks run simultaneously (in separate terminal tabs or tmux panes). You compare the diffs side by side and pick the approach you prefer.

Forking from CLI

If you saved a session ID and want to fork from a specific point later:

Terminal window
# Save the session ID when you want a fork point
claude --print-session-id
# → session-abc123


# Later, resume at that fork point
claude --resume session-abc123 --fork-session


# The original session-abc123 is untouched
# A new session branches from it

This is useful for creating reproducible experiment baselines — fork the same session multiple times to test different prompts or approaches against identical starting conditions.

Gotchas

File changes are not automatically synced. If the fork writes files and the original session also writes the same files, you have a manual merge situation. Plan your fork so each branch owns distinct files, or use the fork only for exploration (not production commits).

Branches do not communicate. Two forked sessions have no awareness of each other. They cannot share tool results, file reads, or conversation history after the fork point.

Session IDs are required for CLI forking. The --resume --fork-session pattern requires that you captured the session ID at fork time. If you did not, you cannot retroactively fork an old session.

Memory writes in forks. If Claude writes to CLAUDE.md or project memory in a fork, those writes stay in the fork’s context. They do not propagate back to the original session or to your actual CLAUDE.md file unless the fork explicitly commits and pushes.