Domain 1 · Task 1.7

Session State & Resumption

Manage session state, resumption, and forking.

Sessions are the persisted conversation history the SDK keeps on disk, enabling you to continue, branch, or discard prior context. Three levers matter: --resume <session-name> to continue a named investigation, fork_session to branch independent explorations from a shared baseline, and starting fresh with a structured summary when the old context has gone stale.

Key concept

Stale context → fresh start plus a structured summary. Divergent exploration → fork. Same thread with still-valid context → resume (and tell it which files changed).

What you need to know

Resume: same thread, valid context

Use --resume <session-name> to continue a named investigation across work sessions when the prior context is mostly still valid. Resuming replays the conversation history so the agent picks up where it left off. If you resume after edits, you must tell the agent which files changed so it re-analyzes the right things — resuming silently onto stale assumptions is how you get wrong answers.

Fork: divergent exploration from a shared baseline

Use fork_session to create independent branches from a shared baseline — the original session is untouched and the fork gets a new id. This is the tool for comparing divergent approaches from one analysis: for example, exploring a Redux refactor and a Context-API refactor from the same starting investigation, each in its own branch, without cross-contamination.

python

# Analyze once, then branch to compare two refactors independently
base = query(prompt="Analyze this component's state management.")

redux = query(resume=base.session_id, fork_session=True,
              prompt="Refactor to Redux.")     # new id, own history

context_api = query(resume=base.session_id, fork_session=True,
                    prompt="Refactor to the Context API.")  # separate branch

Fresh + summary: when context is stale

When files have changed substantially, the context has degraded, or there was a long gap, starting fresh with an injected structured summary beats resuming on stale tool results. Old tool outputs that no longer reflect reality will mislead the agent; a distilled summary of the current state gives it accurate ground truth without dragging along outdated history.

Choosing resume vs fork vs fresh

Pick from the situation, not a default:

Situation	Choice
Continue the same investigation, context still valid	`--resume <name>`
Explore two divergent approaches from a shared baseline	`fork_session`
Files changed / context degraded / long gap	Start fresh with an injected structured summary
Resuming after edits	Resume and tell it which files changed

Exam traps

The trap	The reality
To compare a Redux vs Context-API refactor you resume the same session twice.	Resuming the same session mixes the two explorations. Use `fork_session` so each approach runs in its own branch from the shared baseline.
After a large refactor you should just resume the session as-is.	Resume only works if you tell it which files changed — and if the results are stale, start fresh with a structured summary instead.
Resuming is always preferable to starting over because it preserves context.	Stale tool results actively mislead. When context has degraded, a fresh start with a distilled summary is more accurate.
Forking and resuming are two names for the same continuation mechanism.	Resume continues one thread; fork copies the baseline into a new independent session so branches don't affect each other.

Practice scenario

Real questions from the bank that test this topic — the correct answer is highlighted.

An engineer used Claude Code in a long --resume session to refactor a service. They paused at 4pm. Overnight, a CI job ran formatting auto-fixes (whitespace, indentation — no semantic changes) across the entire repo, and a teammate merged a PR renaming a helper function the engineer was actively using in their refactor.

What's the best way to continue the next morning?

ARun claude --continue ; Claude will discover changes naturally as it re-reads files

BResume the named session, then immediately /clear to start fresh with the current state

CResume the named session and tell Claude explicitly about the function rename; the formatting changes are non-semantic and can be ignoredCorrect

DStart a fresh claude session; the overnight changes mean the prior session's mental model is too stale to trust

Why: Formatting auto-fixes (whitespace, indentation) are non-semantic — they don't change what the code does or how Claude reasons about its structure. The function rename is semantic and will affect every reference. Tell Claude about the rename so it can update its mental model; let the formatting changes pass through silently when Claude re-reads files. Option A risks Claude referencing the old function name before re-reading. B and D both throw away a refactor's worth of accumulated context unnecessarily — the prior session's understanding of the architecture is still valid.

A user asks your multi-agent research system to "compare two competing approaches to renewable battery design" — they want the system to develop each approach in depth independently, then evaluate trade-offs. Your team is debating how to structure this.

What is the most effective approach?

AHave the coordinator spawn two subagents in sequence: the first develops approach A fully, then the second develops approach B with approach A's analysis in its prompt for comparison.

BUse fork_session to create two independent branches from a shared baseline analysis, exploring each approach in its own fork without cross-contamination, then synthesize.Correct

CHave the coordinator spawn both subagents in parallel by emitting two Task tool calls in a single response, then aggregate results for comparative synthesis.

DHave a single subagent develop both approaches in one prompt, with explicit instructions to keep its reasoning about each approach separate.

Why: The guide specifically describes fork_session for creating independent branches from a shared analysis baseline to explore divergent approaches (Task Statement 1.3 / 1.7). Option A (sequential) lets approach A's analysis bias approach B. Option C (parallel Task calls) is appropriate for independent tasks, but here you want each approach to develop from the same baseline analysis — that's exactly what forking is for. Option D (single subagent) makes contamination almost certain.

Build exercise

Practise resume, fork, and fresh-with-summary

~45 min

1
Run an analysis of a component's state management and capture its session_id.
Why: This shared baseline is what you'll resume from and fork.
2
Resume the session by name to ask a follow-up while the context is still valid.
You should see: The agent continues seamlessly with full prior context.
3
From the same baseline, fork twice with fork_session — one branch refactors to Redux, the other to the Context API.
You should see: Two independent session ids; neither branch's changes leak into the other or the original.
4
Make a large set of file edits, then resume and explicitly tell the agent which files changed.
Why: Resuming after edits without naming the changed files leaves the agent reasoning over stale state.
5
Simulate badly degraded context (many changes, long gap) and instead start a fresh session seeded with a structured summary of the current state.
You should see: The fresh session reasons from accurate ground truth rather than stale tool results.

Sources

Agent SDK — Sessions Manage Claude's memory (Claude Code)Claude Docs

Drill Agentic Architecture & Orchestration

Practice only this domain’s questions, untimed, with instant explanations.