Home › Study guides › CCAR-F › Domain 1 › Lesson 1.7

CCAR-F · Domain 1 · 27% of the exam · Lesson 1.7 · 20 min read

Sessions: resuming, forking and starting fresh

How a Claude session is resumed by name, forked from a shared baseline, told which files changed, and when a fresh session with a summary beats resuming.

Written against task statement 1.7 of the official CCAR-F exam guide (Version 1.0, effective July 2026). An independent resource, not affiliated with Anthropic; the practice questions are written from scratch.

1.7.1 Why an investigation needs a memory that outlives the terminal

Picture an engineer handed a legacy payments module: old code that charges customers, and that nobody on the team understands any more. Getting to grips with it is not an afternoon's work. It means reading dozens of files and tracing how a charge flows from the gateway (the part that talks to the card network) into the ledger (the record of what was paid). That map takes a day to build, and the engineer will need it all week.

Now imagine doing that work with a Claude agent. It explores the code with its built-in tools for reading files (Read), searching their text (Grep) and finding files by name (Glob), and it reports what it finds. Everything the agent learns lives in one conversation: the files it read, the searches it ran, the conclusions it drew. Close the terminal, open a new conversation tomorrow, and none of that is there. Tomorrow's first question would go to an agent that has never seen the module.

A session is the answer: the saved history of one agent conversation, written to disk as the agent works, so you can return to it later. Because it holds every tool call and result, returning to it gives the agent the context it had when you left. A session can be resumed (carry on where you stopped), forked (branch off a copy and try something different), or left behind for a fresh session when what it holds is no longer true. Knowing which to reach for is the skill this lesson teaches.

1.7.2 Resuming a named session

Here is the first question: how do you get back to yesterday's conversation, and not to some other one? A busy engineer might have three investigations open in the same project. "The most recent session" is no handle at all when the most recent one was a five-minute question about something else.

Start with what a session physically is. As the agent works, the conversation is written to a file on disk automatically: your prompts, every tool call, every tool result, every reply. That happens whichever way the engineer runs the agent: typing to it in Claude Code, the command-line tool, or driving it from a program built on the Agent SDK, which runs the same agent loop. Claude Code exposes the session controls as flags (switches typed after the claude command); the SDK exposes them as options in your code. Each session gets a unique id, a long random string, and you can also give it a human name. Names exist to tell several sessions in one project apart.

So on day one the engineer starts Claude Code with a name, claude --name payments-legacy-map (-n for short). The agent is asked to map the module: the path a charge takes from payments/gateway.py into payments/ledger.py, what payments/retry.py and payments/webhooks.py are for, and where the risky code is. By the end of the day the session holds a detailed picture. On day two, claude --resume payments-legacy-map reopens that exact conversation. The agent can answer "where did we say the double-charge risk was?" without reading a single file again, because the reading is already in its history.

Think of sessions as logbooks on a shelf. "Grab the top one" works only if nobody has used the shelf since; "grab the one labelled payments" always works. Precisely: --resume <name> (-r) continues one specific prior conversation by name, while --continue (-c) reopens the most recent conversation in the current directory, whatever it was. Inside a running session, /rename sets or changes the name and /resume <name> switches to another conversation. In the SDK the option is resume, and it takes a session id. Your code reads that id from the session_id field of the result message (the last message of every run) and stores it.

Memorise the two spellings the exam guide uses, --resume <session-name> and fork_session. Recognise the rest.

1.7.3 Telling a resumed session what changed

Resuming feels like magic until you ask an uncomfortable question. The agent's memory of payments/retry.py is not a link to the file. It is the text of the file as it was when the agent read it, sitting in the history as a tool result. If a teammate rewrote that file overnight, the resumed agent still "remembers" the old version, and nothing tells it the file changed. A session saves the conversation, not the files.

Left alone, this produces a quietly wrong agent. On day two the engineer asks "is the retry path safe to remove?" and the agent answers confidently from yesterday's retry code, which no longer exists. Nothing in the reply looks broken. The tempting fix is to make the agent re-read the whole module, which throws away the point of resuming. The right fix is to tell it exactly what changed.

That is what informing the agent about changes to previously analysed files means in practice. When you resume after code has been modified, your first message names the files that changed and asks for targeted re-analysis: "Since yesterday, a teammate changed payments/retry.py and payments/webhooks.py. Re-read just those two and update your map. Everything else you read is still current." The agent re-reads two files, reconciles them with a map that is otherwise valid, and carries on. Two file reads instead of forty.

Think of briefing a colleague back from leave: you do not make them re-read every ticket, you say "these two things changed while you were out". Precisely: a resumed agent has no signal that any earlier tool result is out of date. You name the files that changed, and it re-analyses only those instead of re-exploring the whole codebase.

Where does the list of changed files come from? Not from the agent. It comes from the engineer, or from something the engineer runs: the version-control command git diff --name-only, which lists every file changed since a given point, a pull request's file list, or a teammate's message. The agent does not know what happened while it was closed; at the resume point you are its eyes for the gap.

1.7.4 Forking: two futures from one past

By day three the map is trustworthy and the real question arrives: how should the module be refactored (restructured without changing what it does)? Two strategies are on the table. Strategy A is a strangler: build a new front door for the module and move its callers, the other code that uses it, across one at a time. Strategy B is an in-place split: pull the ledger and the gateway apart inside the existing code. The engineer wants the agent to explore both in depth and compare them.

Doing both in one session is a mess. Once the agent has argued for the strangler approach for twenty turns, every answer about strategy B is coloured by that reasoning. Starting two new sessions from scratch is worse: each would redo the day of mapping, and the two would likely build slightly different maps, so the comparison would not be like for like. What you want is one shared starting point, the baseline, and two independent continuations.

That is a fork. Forking creates a new session that starts with a copy of the original's history and then goes its own way. The original session and its id stay unchanged. In the SDK you resume the baseline with fork_session=True (Python) or forkSession: true (TypeScript), and the fork gets its own session id, reported in its result message. Do it twice, once per strategy. In Claude Code the same thing is claude --resume payments-legacy-map --fork-session, or /branch <name> inside the session.

Here is the fork in Python with the Agent SDK. Look at the options line, which resumes the SAME baseline both times and asks for a fork, and at the last line, which keeps each fork's own id.

briefs = {
    "strangler": "Plan a strangler refactor: new front door, migrate callers one by one",
    "split": "Plan an in-place split: pull the ledger apart from the gateway",
}
fork_ids = {}
for strategy, brief in briefs.items():
    # Both forks start from the day-one map; neither changes it
    options = ClaudeAgentOptions(resume=baseline_id, fork_session=True)  # FORK, not plain resume
    async for message in query(prompt=brief, options=options):
        if isinstance(message, ResultMessage):
            fork_ids[strategy] = message.session_id  # the fork's OWN id, not baseline_id

The everyday picture is a photocopy of the logbook: each copy carries every page written so far, and from here on nothing written in one appears in the other. Precisely: the forks share everything up to the fork point and nothing after it, so they compare two approaches from an identical starting analysis. One thing to hold onto: the fork copies the conversation, not the files. If a forked agent edits code, that edit is real on disk and visible to the other fork.

1.7.5 When resuming is the wrong move

Now the situation that separates understanding sessions from knowing the flags. On day five a large merge lands: forty files under payments/ changed, ledger.py was split in two, and half the map's file paths no longer exist. The engineer's instinct is to resume payments-legacy-map and list what changed. Is that still right?

It is not. Resuming carries forward every old tool result. When two files changed, those stale results were a small island in a sea of valid context, and one sentence could patch them. When forty files changed, the stale results ARE the context. The agent would be reasoning over a long history of file contents that are mostly wrong, with a note at the end saying "ignore most of the above". A model cannot be relied on to ignore what is in front of it. Old reads contradict new reads, the conclusions come out hedged or wrong, and you cannot tell which era each part of an answer came from.

The reliable move is to start a new session and seed it with a structured summary: a short written record of what the investigation established, organised so the agent can use it. Not the transcript; the conclusions. For the payments investigation it has five parts:

• What the module does, and how a charge flows through it.
• Decisions made: strategy A chosen over B, and why.
• Known risks, such as the double-charge path.
• What the merge changed, in a paragraph.
• The next task.

Ask the old session to draft it ("summarise what we established about the payments module, as a briefing for a new session"), or write it yourself, and add the paragraph on the merge. Then paste it into the first prompt of a fresh session, which reads the current files for itself.

The rule that decides between the two is about proportion. Resume when the prior context is mostly valid, so a targeted correction is small. Start fresh with an injected summary when the prior tool results are mostly stale, so the correction would be bigger than the context worth keeping. The threshold is a judgement, but the signs are clear. A couple of files touched and the map's structure intact: resume and name the files. A wide refactor, with files moved or deleted and the map's shape itself changed: summarise and start over.

The middle three rows are the distinctions this task statement names; memorise those.

1.7.6 The exam traps

Each anti-pattern below gets one of the three moves wrong: resume, fork or start fresh.

• ✗ Using --continue to return to a specific investigation. ✓ Use --resume <session-name>. --continue reopens the most recent conversation in the directory, whatever it was; a name reaches the one you mean.
• ✗ Resuming after code changes and saying nothing. ✓ Name the changed files in the first message and ask for targeted re-analysis. The agent's memory of a file is a snapshot; it cannot notice that the file changed.
• ✗ Resuming and asking the agent to re-explore the whole module. ✓ Point it at the specific files that changed. Full re-exploration discards the value of resuming and costs about the same as starting over.
• ✗ Running two fresh sessions to compare two strategies. ✓ Fork the baseline session twice. Two fresh sessions redo the analysis and may not even reach the same baseline, so the comparison is not like for like.
• ✗ Resuming (or forking) after a large merge that made most tool results stale. ✓ Start a new session and inject a structured summary. Old file contents in context contradict the new code, and a fork inherits the same stale history.
• ✗ Pasting the whole old transcript into the new session. ✓ Write a structured summary of the conclusions. The transcript is the stale evidence you were trying to leave behind.

1.7.7 Put it together: run the investigation and break it

You now hold every piece. You know what a session saves, how to name and resume one, and why a resumed agent must be told what changed. You know how a fork gives two futures one past, and when to leave a session behind for a summary. The fastest way to make the judgement stick is to run a small version of the payments investigation and then deliberately mislead the agent.

Sessions close out the architecture domain, and their substance returns in the last domain of the exam. Context management and reliability (Domain 5) is about the same substance a session stores: what is in the model's context, how it grows and how it goes stale. It asks what to summarise, trim or hand over so the agent reasons from what is true now. The judgement you practised here, between patching context and replacing it, is the one that domain tests at every scale.

Key takeaways

• ✓ A session is the saved history of one agent conversation, tool calls and results included, written to disk so the agent can pick it up with its earlier context intact.
• ✓ --resume <session-name> continues one specific named conversation; --continue only reopens the most recent one. In the SDK, resume takes the session id captured from the result message.
• ✓ A resumed session's memory of a file is a snapshot. After code changes, name the files that changed and ask for targeted re-analysis of those alone.
• ✓ fork_session starts a new session from a copy of the baseline history and leaves the original untouched. Fork twice from one analysis to compare two approaches without redoing the analysis or letting them contaminate each other.
• ✓ Resume when prior context is mostly valid. When prior tool results are mostly stale, a new session seeded with a structured summary is more reliable, because the stale evidence stays out of context.
• ✓ A structured summary carries conclusions, decisions, risks and the next task, not the transcript.

Check your understanding

4 questions written for this lesson, then one from the CCAR-F question bank on the same topic. Every answer option is explained, including the ones you did not pick. Nothing is stored.

Sources

• Agent SDK sessions
• Manage sessions in Claude Code
• Claude Code CLI reference
• Claude Code common workflows
• Agent SDK overview
• The CCAR-F exam guide, summarised