Rubric
Contents — domains, guide and mocks

Session state, resumption and forking

CCAR-F 1.79 min read · checked 21 September 2026

Task statementManage session state, resumption, and forking

Three ways back into work

What it doesUse when
ResumeContinues a specific session with its full historyPrior context is still mostly valid
ForkCopies a session's history into a new, independent sessionYou want to try an alternative without losing the original
Fresh start + summaryNew session seeded with a structured summaryPrior tool results are stale

A session is the conversation history the SDK accumulates while the agent works: your prompt, every tool call, every tool result, every response. The SDK writes it to disk automatically. Returning to it means the agent has everything it read and decided before — which is exactly why returning to it is powerful, and exactly why it can mislead when the world has moved on.

Choosing how to come back

Is the earlier context still true?
  • Yes, nothing has changed
    Resumecontinue with full history
  • Mostly — a few files changed
    Resume + name changestell it which files to re-read
  • No — much has changed
    Fresh + summarycarry over only what still holds
  • Yes, but try an alternative
    Forkbranch; original stays intact
Resume, fork and fresh-start answer different questions. The exam usually gives you enough detail to tell which question is being asked.

Resuming and forking in practice

In Claude Code, --resume continues a named or chosen session. In the Agent SDK you capture session_id from the result message and pass it back as resume; setting fork_session (Python) or forkSession (TypeScript) alongside it creates a branch with its own new id, leaving the original untouched.

WhereResumeFork / branch
Agent SDKresume=session_id; or continue_conversation=True / continue: true for the most recentresume + fork_session=True / forkSession: true
Claude Code CLIclaude --continue, claude --resume <name or id>/branch in a session, or --fork-session with --continue / --resume
Namingclaude -n <name> at start, /rename duringA branch gets its own session id

The session id is on every result message, including error results — so a run that stopped at error_max_turns can be resumed with a higher limit. Name sessions you expect to return to; the Claude Code best-practice advice is to treat named sessions like branches, one per workstream.

Fork to compare two approaches from one analysispython
# session_id holds an analysis of the codebase

# Branch A: explore one testing strategy in a fork
async for m in query(
    prompt="Propose a property-based testing strategy for the parser.",
    options=ClaudeAgentOptions(resume=session_id, fork_session=True),
):
    ...

# Branch B: the original session is unchanged; continue a different path
async for m in query(
    prompt="Propose a snapshot-testing strategy for the parser.",
    options=ClaudeAgentOptions(resume=session_id),
):
    ...

What a fork copies

Copied into the fork

  • The full conversation history
  • Every earlier tool call and result
  • A new session id of its own

Not isolated by a fork

  • Files on disk — edits are visible everywhere
  • External systems it writes to
  • In the CLI, session permission grants if forked into a new process
A fork is a copy of the conversation. The working directory is shared, so edits made in one branch are real in the other.

The stale-context problem

A resumed session still holds the tool results it gathered earlier — including the contents of files that have since been edited. The agent does not know they changed. Two remedies, and the exam wants you to choose correctly:

  • A few files changed: resume, and tell the agent exactly which files changed so it re-reads those rather than re-exploring everything.
  • Much has changed: start a new session and inject a structured summary of what still holds. This is more reliable than resuming with a history full of stale results.

The SDK documentation makes a related point about running on different machines: session files live on the machine that created them, and one supported approach is not to rely on resume at all — capture the results you need (analysis, decisions, diffs) as application state and pass them into a fresh session's prompt. It calls this often more robust than moving transcript files around. The alternative is a session-store adapter that mirrors transcripts to your own storage so another host can resume them.

Traps the wrong answers are built from

Tempting but wrongDo this instead
Resuming after large code changes without saying what changedName the changed files, or start fresh with a summary.
Exploring an alternative inside the original sessionFork, so the original stays intact.
Assuming a fork isolates file editsForks isolate history only; use checkpointing for files.
Throwing away a valid analysis to try a second approachFork from it instead of starting from scratch.
Expecting a session id to resume on a different machineUse a session store, or pass saved state into a fresh session.

You should now be able to

  • Resume named sessions to continue an investigation.
  • Fork a session to compare approaches from a shared baseline.
  • Choose between resuming and starting fresh with an injected summary.
  • Tell a resumed session which files changed for targeted re-analysis.
  • Capture and store session_id so interrupted or capped runs can continue.

Practice questions

Original questions written for this lesson, in the exam’s style. Answer first, then open the reasoning — every option is explained, including why the wrong ones are tempting.

  1. Question 1

    Yesterday an agent analysed a service in a session. Overnight, a teammate refactored most of the service's modules. You want to continue the work today.

    What is the most reliable approach?

    1. AResume yesterday's session and continue from where it stopped.
    2. BFork yesterday's session and continue the work in the fork.
    3. CStart fresh, seeded with a summary of findings that still hold.
    4. DResume the session and ask the agent to be extra careful.
    Show answer and reasoning
    1. AIncorrect. The session's tool results describe code that no longer exists.
    2. BIncorrect. A fork inherits the same stale history as the original.
    3. CCorrect. With most context stale, a fresh start with a summary is more reliable than resuming.
    4. DIncorrect. Caution does not tell the agent which results are out of date.

  2. Question 2

    You have a session containing a detailed codebase analysis and want to compare two refactoring approaches without losing either. What should you do?

    1. AFork the session and pursue one approach in each branch.
    2. BRun both approaches one after the other in the same session.
    3. CStart two brand-new sessions and redo the analysis in each.
    4. DCompact the session first, then continue with both ideas.
    Show answer and reasoning
    1. ACorrect. Forking gives two independent histories from one shared baseline.
    2. BIncorrect. The second approach inherits everything the first one did.
    3. CIncorrect. That throws away the analysis you already paid for.
    4. DIncorrect. Compaction shrinks context; it does not create separate branches.

  3. Question 3

    A developer forks a session to try an experimental refactor. The fork edits several source files. Later, resuming the original session, the agent finds the experimental changes in the code.

    What explains this?

    1. AThe fork was created without fork_session, so it was not a fork.
    2. BForks copy conversation history, not the files on disk.
    3. CResuming a session always merges the history of its forks back in.
    4. DSession ids are shared between a fork and its original session.
    Show answer and reasoning
    1. AIncorrect. The fork did get its own history; the issue is files, not conversation.
    2. BCorrect. Both sessions work in the same directory. Use file checkpointing or separate checkouts to isolate edits.
    3. CIncorrect. The original's history is unchanged; it is reading the edited files from disk.
    4. DIncorrect. A fork gets its own new session id.

  4. Question 4

    A CI job runs an agent on one ephemeral worker and saves only the session_id. A follow-up job on a different worker passes that id as resume and fails because no conversation is found.

    What is the most robust fix?

    1. APass the same id with continue_conversation=True instead.
    2. BRetry the resume a few times in case the store is slow.
    3. CSave the results as job state and seed a fresh session.
    4. DPin both jobs to the same working directory path.
    Show answer and reasoning
    1. AIncorrect. Continue looks for the most recent session on the current machine; the transcript still isn't there.
    2. BIncorrect. Nothing is slow; the transcript was never on the second worker.
    3. CCorrect. Session files are local to the host. The docs suggest capturing results as application state for a fresh session, or mirroring transcripts with a session store.
    4. DIncorrect. Matching the path on a different machine does not bring the transcript file with it.

Practise every question in Domain 1 →

Sources

Drafted with AI assistance and checked against the sources above; expert review is in progress. Spotted an error? Tell us and it gets fixed, dated and listed on how this is written.