1.7 Session State and Resumption

What You Need to Know

Session management determines how an agent maintains continuity across work sessions. In long-running tasks — debugging a complex system, reviewing a large codebase, conducting multi-day research — the agent’s context accumulates tool results, file analyses, and reasoning chains. Task Statement 1.7 covers how to manage this accumulated state: when to continue it, when to branch it, and when to start fresh.

Three Session Management Options

The Agent SDK and Claude Code give you three approaches to session management. Each does a different job, and the exam expects you to pick the right one for the scenario in front of you.

Option 1: --resume <session-name>

Resume continues a specific named session from where it left off. The entire conversation history — including all tool results, analyses, and reasoning — is restored.

When to use: The prior context is mostly still valid. Files have not changed significantly since the last session. You want to pick up exactly where you stopped.

When NOT to use: Files have been modified since the last session. Tool results in the conversation history no longer reflect the current state of the codebase. This leads to the stale context problem (covered below).

Option 2: fork_session

Fork creates an independent branch from a shared analysis baseline. After the fork, each branch operates independently — changes in one branch do not affect the other, and branches cannot see each other’s results.

In the SDK you set it beside resume, not instead of it: resume picks the session, and fork_session: true starts a new session from a copy of that history rather than appending to it. The CLI pairs --fork-session with --resume the same way. (Agent SDK sessions guide, checked September 2026. Lesson 1.3 has the full note.)

When to use: You have completed an initial analysis and want to explore divergent approaches from that shared starting point. For example, after analysing a codebase, you fork to compare two refactoring strategies. Each fork builds on the same initial understanding but takes a different direction.

When NOT to use: You simply want to continue the same line of investigation. Fork is for divergence, not continuation. If you are not comparing alternatives, use resume.

Option 3: Fresh start with summary injection

Start a completely new session but inject a structured summary of the prior session’s findings into the initial context. The new session has no stale tool results — only the curated summary you provide.

When to use: Tool results from the prior session are stale (files have changed, APIs have been updated, dependencies have shifted). Context has degraded over a long session (too many irrelevant tool results cluttering the history). You need a clean baseline with preserved knowledge.

When NOT to use: The prior context is still valid and you want to maintain the full conversation history. In this case, resume is more efficient.

The Stale Context Problem

The stale context problem is the central concept of this task statement. It occurs when an agent resumes a session after code modifications and reasons from cached tool results that no longer reflect the current state of files.

How it manifests: A developer works with Claude Code to analyse a codebase. They make changes to 3 files and resume the session. Claude gives contradictory advice about those files — recommending changes that were already made, or referencing code that no longer exists — because it is reasoning from the old tool results still in its conversation history.

Why it happens: When you resume a session, the entire conversation history is restored, including every tool result from the previous session. If a file was read during the previous session and has since been modified, the old file contents are still in the conversation as a tool result. The model reasons from that stale data alongside any new data, leading to contradictions.

The naive fix (and why it is insufficient): Simply resuming the session and asking the agent to re-read the modified files. This is better than nothing, but the stale tool results remain in the conversation history. The model may still reference old information from earlier in the context, especially for tangential decisions that do not directly involve the modified files.

The correct fix: Start a fresh session with a structured summary of prior findings. Specify which files have changed so the agent can perform targeted re-analysis of those files. The fresh session has no stale tool results, and the injected summary preserves the knowledge from the prior session without the outdated data.

Targeted Re-Analysis vs Full Re-Exploration

When files have changed, the agent doesn’t need to re-analyse the whole codebase. That’s wasteful. Re-reading 50 files because 3 of them changed is time you don’t get back.

The correct approach is targeted re-analysis: inform the agent about the specific files that changed and let it re-analyse only those files. The summary from the prior session covers everything that has not changed.

What targeted re-analysis looks like in practice:

Start a fresh session.
Inject a structured summary: “Prior analysis found X, Y, and Z across the codebase. The following 3 files have been modified since: auth.ts, database.ts, and api-routes.ts.”
The agent re-reads and re-analyses only the 3 modified files.
It combines the fresh analysis of changed files with the preserved summary of unchanged files.

This is faster than full re-exploration and more reliable than resuming with stale context.

When to Use Each Option: Decision Matrix

Scenario	Best Option	Reasoning
Continuing work from yesterday, no files changed	`--resume`	Prior context is valid, full history is useful
Comparing two refactoring approaches	`fork_session`	Divergent exploration from shared baseline
Resuming after modifying 3 of 50 files	Fresh start + summary	Stale tool results for modified files would cause contradictions
Long session with cluttered history	Fresh start + summary	Degraded context benefits from a clean baseline
Exploring a testing strategy vs a documentation strategy	`fork_session`	Two independent approaches from the same analysis
Resuming after dependency updates	Fresh start + summary	Multiple files may have changed indirectly

Practical Example: The Contradictory Advice Bug

A developer uses Claude Code to analyse a 50-file codebase over two days. On Day 1, they analyse the authentication module and identify three issues. Overnight, they fix all three issues by modifying auth.ts, session.ts, and middleware.ts.

On Day 2, they resume the session. Claude recommends fixing the three issues that were already fixed — because the old tool results showing the unfixed code are still in the conversation history. Worse, when asked about the current state of auth.ts, Claude gives contradictory answers: sometimes referencing the old code (from the stale tool result) and sometimes referencing the new code (from a fresh read).

The fix: start a fresh session with a summary. “Prior analysis identified three authentication issues in auth.ts, session.ts, and middleware.ts. All three have been fixed. Please re-analyse these three files to verify the fixes and check for any new issues introduced by the changes.”

The fresh session has no stale tool results. The agent reads the current files, verifies the fixes, and provides consistent advice based on the actual current state.

Exam Traps

Practice Scenario

A developer resumes a Claude Code session after modifying 3 files in a 50-file codebase. The agent gives contradictory advice about the modified files — recommending changes that were already made and referencing code that no longer exists. What is the most appropriate approach?

A. Start a completely new session with no carried-over context and re-analyse the entire 50-file codebase from scratch before continuing the work
B. Resume the existing session and ask the agent to re-read the 3 modified files, keeping the rest of the conversation history available for continuity
C. Start a fresh session with an injected summary of prior findings and inform the agent about the specific 3 file changes for targeted re-analysis
D. Use fork_session to branch the existing session so the file changes can be incorporated in a separate line of work

Answer & explanation

Correct: C

A — Re-analysing the entire 50-file codebase is wasteful when only 3 files changed. The prior analysis of the other 47 files is still valid. Targeted re-analysis is more efficient.
B — Resuming preserves the stale tool results in the conversation history. Even after re-reading the 3 files, the old file contents remain in context and can still influence the agent reasoning for related decisions. This leads to continued contradictions.
C — A fresh session with summary injection avoids stale tool results entirely. The injected summary preserves knowledge from the prior session. Specifying the 3 changed files enables targeted re-analysis without re-exploring the entire codebase.
D — fork_session creates a branch from the existing session, which still contains the stale tool results. The fork inherits the same stale context that caused the contradictions. Fork is for divergent exploration, not for resolving stale data.

Sources

Claude Code Documentation — Anthropic
Claude Code in Action (Skilljar) — Anthropic
Claude Agent SDK Overview — Anthropic
Agent SDK: Work with sessions — Anthropic

Exam Simulator

Five exam-style multiple-choice questions on Session State and Resumption. Pick an answer, then open the explanation.

Question 1

A developer resumes a Claude Code session after modifying 3 files in a 50-file codebase. The agent gives contradictory advice — recommending changes that were already made and referencing code that no longer exists. What is the most appropriate approach?

A. Start a completely new session and re-analyse the entire 50-file codebase from scratch
B. Resume the session and ask the agent to re-read only the 3 modified files to update its understanding
C. Use fork_session to create a new branch that can incorporate the file changes independently
D. Start a fresh session with a summary of prior findings and the 3 changed files listed

Answer & explanation

Correct: D

D is correct because a fresh session with summary injection avoids stale tool results entirely. The injected summary preserves knowledge from the prior session. Specifying the 3 changed files enables targeted re-analysis without re-exploring the entire codebase.
A is wrong because re-analysing all 50 files is wasteful when only 3 changed. The prior analysis of the other 47 files is still valid. Targeted re-analysis is more efficient.
B is wrong because resuming preserves the stale tool results in conversation history. Even after re-reading the 3 files, the old file contents remain in context and can still influence reasoning for related decisions.
C is wrong because fork_session creates a branch from the existing session, which still contains the stale tool results. The fork inherits the same stale context that caused the contradictions. Fork is for divergent exploration, not for resolving stale data.

Question 2

After analysing a codebase, a developer wants to compare two different refactoring strategies: one focusing on performance and another on readability. Which session management approach is most appropriate?

A. Start two completely new sessions, one for each strategy
B. Use –resume to continue the same session and try both strategies in sequence on one branch
C. Use fork_session to create two independent branches from the shared analysis baseline
D. Start a fresh session with summary injection for each strategy

Answer & explanation

Correct: C

C is correct because fork_session creates independent branches from a shared analysis baseline. Both branches build on the same initial codebase understanding but explore different directions independently. This is the exact use case for fork.
A is wrong because starting completely new sessions loses the initial analysis. Both strategies benefit from the shared baseline understanding of the codebase.
B is wrong because trying both strategies in the same session contaminates the exploration. The second strategy attempt is influenced by the first strategy’s analysis and decisions.
D is wrong because while summary injection preserves some knowledge, fork_session preserves the complete analysis context and is the purpose-built mechanism for divergent exploration.

Question 3

A developer completed a codebase analysis yesterday. No files have changed overnight. They want to continue where they left off today. Which approach is best?

A. Use --resume <session-name> to continue the named session
B. Start a fresh session with summary injection
C. Use fork_session to create a branch from yesterday’s analysis
D. Start a completely new session and re-analyse the whole module from scratch

Answer & explanation

Correct: A

A is correct because no files have changed, so the prior context is still valid. –resume restores the entire conversation history and lets the developer pick up exactly where they stopped. This is the ideal scenario for resume.
B is wrong because summary injection loses detail from the full conversation history. When context is still valid, resume preserves more information than a summary can capture.
C is wrong because fork is for divergent exploration, not for simple continuation. The developer wants to continue the same line of investigation, not explore alternatives.
D is wrong because re-analysing everything is wasteful when the prior analysis is still valid. Resume is more efficient.

Question 4

Why is resuming a session after file modifications more problematic than simply asking the agent to re-read the changed files?

A. The agent cannot re-read files during a resumed session
B. Stale tool results stay in history and still drive the agent’s reasoning
C. Resumed sessions have a reduced context window that cannot accommodate new file contents
D. The agent will refuse to provide analysis if it detects file modifications

Answer & explanation

Correct: B

B is correct because resuming preserves the entire conversation history, including old tool results showing the pre-modification file contents. Even after re-reading changed files, the old contents remain in context. The agent may reference stale data from earlier in the conversation, especially for tangential decisions that do not directly involve the modified files.
A is wrong because agents can re-read files during resumed sessions. The issue is not capability but context contamination from stale data.
C is wrong because resumed sessions do not have reduced context windows. The issue is stale data in the existing history, not context capacity.
D is wrong because agents do not detect or refuse analysis based on file modifications. They simply reason from whatever data is in their context, including stale results.

Question 5

A developer uses fork_session to handle stale context after modifying files. Why is this approach flawed?

A. fork_session is not available after file modifications
B. fork_session deletes the original session, losing all prior analysis
C. The fork inherits the same stale tool results
D. fork_session only works for comparing testing strategies, not for general use

Answer & explanation

Correct: C

C is correct because fork_session branches from the current session state, including all stale tool results. The fork inherits the same contaminated context that caused the contradictory advice. Fork does not create a clean slate — it creates a copy of the current state. For stale context, a fresh start with summary injection is the correct approach.
A is wrong because fork_session is available regardless of file modifications. The issue is not availability but the inheritance of stale data.
B is wrong because fork_session does not delete the original session. It creates an independent branch while preserving the original.
D is wrong because fork_session can be used for any divergent exploration scenario. However, it is specifically wrong for handling stale context because it inherits the stale data.