What you need to know
A session is the conversation history the agent has built: your prompts, every tool call, every tool result, every response. Returning to it means the agent has all of that again, including the files it already read and the conclusions it already reached. The exam tests three ways to go back, and when each one is right.
| Approach | What it does | Use it when |
|---|---|---|
| Resume | Continues an existing session, adding to its history | The earlier context is still mostly valid |
| Fork | Copies the history into a new, independent session; the original is untouched | You want to try two or more directions from the same starting analysis |
| Start fresh with a summary | A new session whose first message carries a structured summary of earlier conclusions | The earlier tool results no longer describe the code |
Resume by name
In Claude Code you can name a session and come back to it the next day with --resume:
claude --resume leak-huntIn the Agent SDK you capture the session ID from the result message and pass it to the resume option. Either way, the agent continues with full context.
Fork to compare approaches
After a long analysis of a module, you might want to compare two refactoring strategies. Running both in one session muddles them; repeating the analysis twice wastes the work. A fork branches the conversation:
options = ClaudeAgentOptions(resume=analysis_session_id, fork_session=True)Each fork gets its own session ID and diverges independently. Note that a fork branches the conversation, not the files: if both forks edit the same working directory, they edit the same files.
When resuming misleads
A resumed session trusts its old tool results. If teammates have since changed 15 of the 20 files the session read, those results describe code that no longer exists, and the agent will reason confidently from them. Two remedies:
- If a few files changed, resume and tell the agent exactly which files changed so it re-reads only those. That is targeted re-analysis, not full re-exploration.
- If most of the context is stale, start a new session seeded with a structured summary: the conclusions, decisions and open questions from the old one, without its out-of-date tool results.
In the exam
Stems usually give you the state of the code since the last session and ask what to do. Count how much has changed. Look for "compare two approaches from the same analysis" (fork), "continue yesterday's investigation" (resume by name) and "most files have changed since" (fresh session with a summary).
Check your understanding
You analysed a module yesterday and want to compare two refactoring strategies without repeating the analysis. What do you use?
Show answer
Answer: D. Forks start from the same analysis and diverge independently, so each strategy gets clean context and no work is repeated.
Since last week's session, 15 of the 20 files it analysed have changed substantially. What is the most reliable way to continue?
Show answer
Answer: C. Most of the old tool results now describe code that no longer exists. A fresh session with a structured summary keeps the conclusions and drops the stale evidence.
You resume a session after a teammate changed two of the files it read. What should you do?
Show answer
Answer: B. A resumed session trusts its earlier reads. Naming the changed files gives targeted re-analysis and keeps the rest of the valid context.
Apply it: Lakeshore's session playbook
Lakeshore's engineers run long investigations that span days. Write a one-page playbook for when to resume, fork or start fresh.
- Write the decision rule as three short conditions.
- Apply it to three situations: (a) continuing yesterday's "invoice rounding" investigation, nothing merged since; (b) comparing a strangler-fig rewrite with an in-place refactor of the booking module after a two-hour analysis; (c) returning after two weeks in which the billing module was restructured.
- Write the summary template used when starting fresh.
Done when: it keeps conclusions and drops stale evidence.
Show model answer
1. Decision rule
- The earlier context is still true: resume, by name or ID. If a few files changed, list them in the first message.
- You need two or more directions from the same analysis: fork once per direction.
- Most earlier tool results describe code that has changed: start fresh with a summary.
2. Situations
- (a) Resume:
claude --resume invoice-rounding. Nothing changed, so the context is valid. - (b) Fork twice from the analysis session, one branch per approach. Because forks share the working directory, keep both branches to analysis and plans, or give each its own worktree before editing.
- (c) Start fresh. The restructuring makes old reads misleading; seed the new session with the summary below.
3. Summary template
| Section | Content |
|---|---|
| Goal | What the investigation is trying to answer |
| Conclusions | Findings still believed true, each with the file or class it rests on |
| Decisions | What was decided and why |
| Open questions | What was unresolved |
| Known changes | What has changed since, so the agent re-checks those first |