- In short
- A fork session copies an existing session history into a new, independent session that diverges from the branch point, leaving the original untouched. It is the tool for exploring two or more divergent approaches from one shared analysis baseline, because each branch then runs on its own and cannot affect the others.
What a fork session is
A fork session is how you branch an agent conversation so two ideas can be tried from the same starting point. You take a session that already contains useful history, the files it read, the analysis it produced, the decisions it made, and you fork it. Forking creates a brand-new session that begins with a copy of that history and then diverges. The new branch gets its own session identifier; the original session keeps its identifier and its history exactly as they were. You end up with two independent threads you can run separately.
The reason this matters for agentic design is that real architecture work is full of forks in the road. You have analysed a codebase and now want to weigh two refactoring strategies, or two testing approaches, both of which should start from that shared analysis rather than from scratch. A fork session gives each option the same baseline and then lets them evolve without interfering, so you can compare them fairly and still return to where you branched.
- Fork session
- An operation that copies a session history into a new session which diverges from the branch point, while the original session and its ID stay unchanged. Used to explore alternative directions from a common baseline, producing two independent, separately resumable threads.
Fork versus resume versus continue
The single most tested point on this knowledge point is the difference between forking and resuming, so hold the three options apart. Continue and resume both pick up an existing session and add to it; the difference is only how they find it. Continue grabs the most recent session in the current directory with no identifier to track. Resume takes a specific session ID and reopens that exact thread, appending new messages to the same history under the same ID.
Fork is the odd one out. It does not continue an existing thread, it spawns a second one. In the Agent SDK you fork by combining a resume of the source session with the fork flag, set as forkSession in TypeScript or fork_session in Python, and the result message carries a new session ID for the branch. The exam trap is treating fork and resume as interchangeable: resume continues a single session, while fork produces an independent branch. Confuse them and you either overwrite the thread you meant to preserve or you expect a clean branch and instead keep writing into the original.
What forking does and does not copy
Forking branches the conversation, not the world around it. The copied thing is the history: prompts, tool calls, tool results, and responses up to the branch point. What is not copied is the filesystem. If a forked agent edits a file, that edit is real and immediately visible to any other session working in the same directory, including the original. The two branches share one working tree even though they no longer share one conversation.
This is the subtle failure mode to remember. People imagine a fork session as a safe sandbox where they can experiment without consequences, then are surprised when the branch's file edits leak into the original's view. If you need to snapshot and revert the actual files, that is a separate mechanism, file checkpointing, not forking. For the foundations exam, the clean statement is: fork branches history, files stay shared.
How forking relates to the rest of the pipeline
A fork session is one option in a broader toolkit of session management options, and it composes with the other task statement 1.3 ideas. Each branch you create is still an agent that needs a clear objective, so the same goal-based prompting discipline applies inside each fork. And forking is conceptually adjacent to parallel subagent spawning: both let you pursue several directions, but they are not the same move. Parallel spawning fans independent subtasks out to fresh workers; forking branches one rich conversation so each branch keeps the shared history.
Capturing the session identifier first
Forking and resuming both need a handle on the source session, so the practical prerequisite is capturing its identifier. The SDK exposes a session ID on the result message of a run, and you read it from there once the run completes. With that ID in hand you can later resume the exact thread, or branch it by resuming with the fork flag set. Without it you are limited to continue, which only ever grabs the most recent session in the directory and gives you no way to single out an older one. So the habit to build is simple: capture and store the ID of any session you might want to return to or branch.
One environmental detail trips people up and is worth knowing. Sessions are stored per working directory, keyed by the absolute path you ran in. If you try to resume or branch from a different directory than the one that created the session, the tooling looks in the wrong place and hands you a fresh, empty thread instead of the history you expected. The fix is to keep the working directory consistent across the original run and the branch. Knowing that the identifier plus a matching directory are what make branching possible is the kind of precise operational knowledge the exam likes to confirm.
Forking or parallel subagents: choosing the branch
Because both let you pursue more than one direction, candidates sometimes blur forking with parallel subagent spawning, and the exam exploits that. Reach for a fork when the alternatives must share a rich, accumulated history and you want each to continue that conversation independently, such as two strategies that both depend on a long analysis you already performed. Reach for parallel subagent spawning when the work splits into independent pieces that each start from a fresh, isolated context and report a summary back, such as auditing several unrelated services at once.
The distinction comes down to what each option carries. A fork copies the whole conversation so the branch inherits everything up to the split, whereas a spawned subagent starts blank and receives only the prompt you hand it. So forking preserves continuity; parallel spawning maximises isolation and concurrency. Designing well means asking whether the branches need the shared history or merely need to run at the same time, and picking the mechanism that matches. That deliberate choice, rather than treating the two as synonyms, is exactly the applied judgement this knowledge point measures.
How this is tested on the exam
Task statement 1.3 frames this as an applied choice between session operations. A scenario describes an agent that has built up valuable context and now needs to try a second approach, and asks how to do that without destroying the first. The correct answer forks the session so the original is preserved and the alternative runs on its own branch. A second common scenario presents a candidate who used resume expecting an independent copy and accidentally kept appending to the single original thread; you are asked to name the mistake, which is confusing resume with fork.
Watch for the filesystem distractor as well. A question may suggest that forking isolates file changes; it does not. Knowing that a fork branches only the conversation, and that file edits remain shared across branches, is exactly the kind of precise distinction the exam likes to probe.
Worked example
An engineer has used one Claude Code session to analyse a service and now wants to compare two testing strategies, unit-heavy versus integration-heavy, both starting from that same analysis.
The tempting but wrong approach is to keep resuming the single analysis session: try the unit-heavy strategy, then resume again and pivot to the integration-heavy one. Because resume appends to the same thread under the same ID, the second pivot is contaminated by the first attempt's messages, and the original clean baseline is gone. There is now one muddled history instead of two clean comparisons.
The right approach forks. From the baseline session that holds the shared analysis, the engineer forks once to create branch one and pursues the unit-heavy strategy there; the fork receives its own new session ID. The original session is untouched, so resuming it continues cleanly down the integration-heavy path as branch two. Each branch begins from the identical analysis baseline yet evolves independently, which makes the comparison fair.
One caution carries through the exercise: both branches edit the same repository on disk. Forking kept their conversations separate but not their files, so the engineer runs each strategy in a way that does not clobber the other's work, or uses file checkpointing to snapshot between them. The conversation forked; the working tree did not.
Common misreadings to avoid
Misconception
Forking a session and resuming with --resume do the same thing.
What's actually true
Misconception
Forking a session gives me a safe sandbox where file edits will not affect the original.
What's actually true
Putting it to work
Forking earns its place whenever you want to branch without backtracking: explore a risky idea while keeping a known-good thread, or run a deliberate A and B comparison from a shared baseline. Paired with the rest of task statement 1.3, it lets a coordinator preserve hard-won context and still chase divergent paths, which is precisely the kind of session-aware design the foundations exam expects an architect to reach for.
The mental model worth carrying away is the version-control analogy, handled with care. Branching a conversation is a lot like branching code: you split off a line of work that starts from a known point and evolves on its own, and you can always return to where you branched. The analogy breaks in exactly one place, and that break is the most tested point. Branching code isolates the files; branching a conversation does not, because the working tree is shared across branches. So treat a fork as a branch of the discussion, not a branch of the project on disk. Keep that one caveat in view and you will reach for forking confidently whenever you need two informed directions from a single baseline, and avoid the trap of expecting it to sandbox your files.
An agent has spent a long session building a detailed analysis of a codebase. The team now wants to compare two migration strategies, each starting from that exact analysis, without losing the original thread. Which approach fits best?
People also ask
What is the difference between fork session and resume?
Does forking a session also branch the files?
When should I fork a session?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
Forking Claude Code agents with Sculptor
Why watch: Demonstrates forking Claude Code agents to spawn independent parallel branches from a shared baseline, the exact use case fork_session enables for divergent exploration.
More videos for this concept
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.