Session State, Resumption & Forking
Official Task Statement 1.7 — "Manage session state, resumption, and forking." Cross-references: see D1.4 for workflow enforcement, prerequisite gates, and human handoff; see D1.6 for task-decomposition strategies (prompt chaining vs dynamic decomposition).
1. Core exam idea
The exam tests whether an architect knows how to preserve useful state without accidentally preserving bad or stale state.
For long-running agentic work, Claude may accumulate: - user instructions - tool results - file contents - codebase analysis - decisions already made - subagent outputs - approval status - workflow progress - human handoff context
A strong architect knows when to: - continue the same session - resume a named prior session - fork a session - start fresh - inject a structured summary - persist durable memory - store workflow state outside the model
Claude Code and the Agent SDK treat a session as accumulated conversation history: prompts, tool calls, tool results, and responses. Returning to a session gives the agent full prior context, but sessions persist conversation state, not the filesystem itself.
2. Agent, environment, session: know the distinction
| Concept | Meaning | Exam relevance |
|---|---|---|
| Agent | Reusable, versioned configuration: model, system prompt, tools, MCP servers, skills, metadata | Defines capabilities and behavior |
| Environment | Sandbox or execution environment where the agent runs | Defines where tools execute |
| Session | Running instance of an agent inside an environment | Maintains task-specific conversation history and state |
Conceptually: an agent is a reusable configuration (model, system prompt, tools), an environment is where it runs, and a session references an agent and an environment while maintaining conversation history across interactions.
Exam trap:
Updating the agent changes future behavior/configuration. Resuming a session continues prior task state.3. Three major session-management options
The core options are: Resume, Fork, and Fresh start with summary injection.
Option 1: Resume
Use resume when continuing the same line of work and prior context is still valid.
Typical use:
Yesterday: Claude analysed the codebase.
Today: No files changed.
Need: Continue from where we stopped.
Best choice: resume.
Claude Code supports --continue for the most recent session and --resume / --resume <session_id> for selecting or resuming a specific session. Named investigation sessions can be continued across work sessions with --resume <name>.
SDK distinction:
| Option | Meaning |
|---|---|
| Continue | Pick up the most recent session in the current directory (--continue) |
| Resume | Pick up a specific session ID or name (--resume <session_id> / --resume <name>) |
| Fork | Copy prior history into a new session for an alternative direction |
The SDK docs state that continue and resume both add to an existing session, while fork creates a new session that starts with a copy of the original history. (Claude Code — Work with sessions)
Use resume when: - the task is the same - prior findings are still valid - files or external state have not changed - full prior conversation history is useful
Avoid resume when: - files have changed - dependencies changed - APIs changed - the session contains too much irrelevant history - old tool results may conflict with current reality
Option 2: Fork
Use fork when exploring alternative approaches from the same baseline. fork_session (SDK) / --fork-session (CLI) creates independent branches from a shared analysis baseline to explore divergent approaches.
Example:
Baseline: Claude analysed the architecture.
Branch A: Try event-driven refactor.
Branch B: Try database-first refactor.
Best choice: fork.
Forking creates a new session ID while preserving the original session unchanged. Claude Code supports forking with --fork-session or /branch. (Claude Code — How Claude Code works)
Use fork when: - comparing multiple refactor strategies from a shared codebase analysis - comparing two testing strategies - trying two debugging hypotheses - testing different implementation plans - preserving the original session while exploring a risky alternative
Do not use fork when: - you simply want to continue yesterday's work - the old session has stale file reads - you need a clean baseline - you need to remove bad context
Exam trap:
Fork is not the solution to stale context.Option 3: Fresh start with summary injection
Use this when old session context is partly useful but polluted.
Example:
Day 1: Claude analysed 50 files.
Day 2: Developer modified 3 files.
Problem: Old tool results still show the old versions.
Best choice: fresh session + structured summary + targeted re-analysis.
Start a fresh session, inject a structured summary of prior findings, list the changed files, and ask Claude to re-analyze only those changed files.
Use fresh start + summary injection when: - files have changed since the prior session - tool outputs are stale - session context is cluttered - long-running context has degraded - a clean reasoning baseline is needed
The injected summary should include:
Prior findings:
- File/module analysed
- Key issue
- Severity
- Decision made
- Current status
- Files changed since prior analysis
- What must be re-analysed
4. The stale context problem
This is likely the highest-yield exam pattern.
What happens
A session is resumed after external changes. Claude still has old tool results in its conversation history. It may reason from: - old file contents - old command outputs - old dependency state - old API responses - previous analysis that is no longer true
The Claude Code docs state that returning to a session gives the agent prior context, including files it already read and analysis it already performed; this is powerful, but it means old observations may remain in context. (Claude Code — Work with sessions)
Typical exam scenario
Claude analysed auth.ts yesterday.
Developer fixed auth.ts today.
Developer resumes the old session.
Claude recommends fixing code that no longer exists.
Root cause:
Wrong fixes: - "Ask Claude to re-read the changed files." - "Use fork_session." - "Use a larger context window." - "Add a stronger prompt telling Claude to ignore old data." - "Re-analyse the whole repo from scratch."
Best fix:
Start a fresh session.
Inject a structured summary.
Specify the changed files.
Perform targeted re-analysis.
Simply resuming and asking the agent to re-read changed files is insufficient because stale results remain in history and can still influence reasoning.
Choosing resume vs fresh start: resume when prior context is mostly valid; start fresh with an injected summary when prior tool results are stale.
5. Targeted re-analysis vs full re-exploration
When only a few files changed, do not re-analyze the entire codebase. Inform the resumed/fresh session about the specific file changes so it performs targeted re-analysis rather than full re-exploration.
Correct workflow:
1. Start fresh session.
2. Inject prior summary.
3. List changed files.
4. Re-read only changed files.
5. Validate whether prior conclusions still hold.
6. Update final recommendation.
Example:
Prior summary:
- Payment module had 5 findings.
- Auth module had 3 findings.
- Search module had 2 findings.
Changed files:
- auth.ts
- session.ts
- middleware.ts
Task:
Re-analyse only these changed files and verify whether prior auth findings are resolved.
Exam trap:
The exam usually rewards targeted re-analysis because it balances freshness and efficiency.6. Session state vs persistent memory
Distinguish session-local state from cross-session memory.
| State type | Scope | Use case |
|---|---|---|
| Conversation/session history | Current session | Tool calls, tool results, current task reasoning |
| External workflow state | Application/database | Verified customer, AML pass, approval status |
| Memory store | Across sessions | User preferences, project conventions, prior mistakes, domain context |
| Filesystem/sandbox | Runtime environment | Files being read/written during task |
| Handoff summary | Human escalation | Self-contained transfer of context |
Each session starts with fresh context by default; when the session ends, state built inside it is gone unless a memory store is used. Memory stores let agents carry information such as user preferences, project conventions, prior mistakes, and domain context across sessions.
Write access to a memory store should be used carefully: prompt injection from untrusted input could poison future sessions. Use read-only access when the agent does not need to update durable memory.
Exam rule:
Use session state for current-task continuity.
Use memory for durable cross-session knowledge.
Use external systems for authoritative business state.
Do not store high-risk business state only in model memory. For example:
AML check passed = external workflow/database state
Preferred report format = memory store
Current debugging hypothesis = session state
7. Pausing for external action
A session can pause mid-task to wait for an external action — for example, a tool needs to run, or a risky operation needs human approval — and then resume once the application supplies the result or confirmation.
Pattern:
Agent requests action.
Session pauses, waiting for external input.
Application performs approval / tool execution.
Application supplies result or confirmation.
Session resumes.
Exam trap:
A pause means the workflow is waiting for external input, not that the task is complete.8. Multi-agent sessions and continuity
In multi-agent sessions, each agent can run in its own isolated thread. Agents may share a workspace (filesystem, credentials), but each agent has its own context-isolated conversation history; threads are persistent, so the coordinator can later send follow-ups to an agent it previously called.
Exam implications: - The coordinator remains responsible for orchestration. - Subagents may retain prior turns in their own thread. - Tools, MCP servers, and context are not automatically shared. - Follow-up to the same subagent can use its persistent thread. - Cross-agent state must still be routed through the coordinator or external state.
Exam trap:
A subagent remembers its own prior thread, but that does not mean every other agent has that context.
9. Context management during long sessions (compaction & checkpointing)
Claude Code's context can include conversation history, file contents, command outputs, CLAUDE.md, memory, skills, and system instructions. As context fills, Claude Code compacts automatically, but early instructions can be lost; persistent rules should live in CLAUDE.md rather than relying on early conversation history. (Claude Code — How Claude Code works)
Exam implications:
| Problem | Better architecture |
|---|---|
| Long session getting cluttered | Fresh start + structured summary |
| Persistent coding rules lost during compaction | Put in CLAUDE.md |
| Need branch experiment | Fork |
| Need undo local edits | Checkpointing or version control |
| Need durable project facts | Memory store or project docs |
| Need valid current file state | Re-read changed files in clean session |
Checkpointing is useful for local undo and experimentation, but it is not a replacement for version control; it also does not track all bash-command file modifications. (Claude Code — Checkpointing)
10. Decision matrix
| Scenario | Best choice | Why |
|---|---|---|
| Continue same work, no files changed | Resume / continue | Prior context is valid |
| Continue most recent session in directory | --continue |
No need to track session ID |
| Resume specific named/known session | --resume <name> or --resume <session_id> |
Select exact prior context |
| Compare two refactor approaches | Fork (fork_session / --fork-session) |
Divergent exploration from shared baseline |
| Files changed since prior analysis | Fresh session + summary injection | Avoid stale tool results |
| Long session with cluttered context | Fresh session + summary injection | Clean baseline |
| Only 3 of 50 files changed | Targeted re-analysis | Avoid full re-exploration |
| Need durable user preference | Memory store | Persists across sessions |
| Need financial approval state | External workflow state | Must be authoritative |
| Tool requires human approval | Pause for external confirmation | Workflow resumes after decision |
| Multi-user app | Track session IDs explicitly | Avoid mixing user contexts |
| Autoscaled workers need resume | External session store | Local filesystem is insufficient |
The Agent SDK docs note that a specific session ID should be tracked when multiple sessions exist, such as one per user in a multi-user app. They also describe external session stores for multi-host deployments, durability, and compliance/audit use cases. (Claude Code — Work with sessions)
11. Exam anti-patterns
| Anti-pattern | Why it is wrong |
|---|---|
| Resume after files changed | Old tool results remain in context |
| Fork to fix stale context | Fork copies stale history |
| Full repo re-analysis after 3 files changed | Wasteful |
| Store approval state only in prompt text | Not authoritative |
| Use memory store for untrusted writable input | Risk of persistent prompt-injection poisoning |
| Treat a paused session as done | It is paused, not complete |
| Use one long session forever | Context degradation and compaction risk |
| Use bigger model/context as stale-context fix | Old facts remain old facts |
Scenario-Based Questions
Q1. Resume vs fresh start
A developer analysed a 50-file codebase yesterday. Today they modified 3 files and resumed the old session. Claude recommends changes that were already made. What is the best fix?
A. Resume again and ask Claude to ignore old results B. Fork the session C. Start a fresh session with a structured summary and re-analyse only the 3 changed files D. Re-analyse the entire 50-file codebase from scratch
Answer
C. The issue is stale tool results. Fresh session plus summary injection avoids stale history while preserving prior findings.
Q2. Fork use case
Claude has completed an initial architecture analysis. The team wants to compare a queue-based design and an event-sourcing design without losing the original analysis. What should they use?
A. Resume B. Fork C. Fresh start with no context D. PostToolUse
Answer
B. Fork (fork_session / --fork-session) is for divergent exploration from a shared baseline.
Q3. Fork as stale-context fix
A developer modified files after a session and wants to avoid stale context. A teammate suggests fork_session. What is wrong?
A. Fork does not preserve history B. Fork copies the old history, including stale tool results C. Fork deletes the original session D. Fork only works for human handoff
Answer
B. Fork branches from existing history. If the history is stale, the fork starts stale.
Q4. Resume use case
A developer stopped work yesterday after Claude analysed a module. No files or dependencies changed. They want to continue exactly where they left off. Best option?
A. Fresh start with summary B. Resume C. Fork D. Full re-analysis
Answer
B. Resume is appropriate when prior context is still valid.
Q5. Targeted re-analysis
A repo has 200 files. Claude previously analysed all of them. Since then, 4 files changed. What is the best workflow?
A. Re-analyse all 200 files B. Resume and trust old findings C. Fresh session, inject prior summary, re-analyse the 4 changed files D. Fork four sessions, one per changed file
Answer
C. This preserves useful knowledge while avoiding stale context.
Q6. Session vs memory
An agent should remember a user's preferred report format across future sessions. Where should this go?
A. Current session history only B. Memory store C. A paused session event D. Forked session
Answer
B. Durable preferences belong in cross-session memory.
Q7. High-stakes workflow state
An agent must verify identity before issuing refunds. Where should "customer verified" be stored?
A. Only in Claude's natural-language conversation B. In explicit workflow/application state used by a prerequisite gate C. In a final summary paragraph D. In a Markdown formatting rule
Answer
B. High-stakes state must be programmatically checkable (see D1.4 for prerequisite gates).
Q8. Paused for confirmation
A session pauses mid-task because a tool needs human confirmation before it runs. What does this mean?
A. The task is complete B. The workflow is paused until the application sends the required result or confirmation C. Claude has failed permanently D. The session should be deleted
Answer
B. A pause for external action is a wait point, not completion.
Q9. Memory poisoning risk
A memory store contains project coding standards. The agent processes untrusted web content. What access mode is safest if the agent does not need to update the standards?
A. read_write
B. read_only
C. fork_session
D. Store the standards in the prompt instead
Answer
B. Read-only prevents untrusted content from poisoning durable memory.
Q10. Multi-user app
A SaaS app has one agent per user conversation. The app needs to resume a specific user's prior session. What should it track?
A. Only the latest session in the directory B. The specific session ID per user/conversation C. Only the user's natural-language name D. A forked session for every message
Answer
B. Multi-user systems need explicit session IDs to avoid mixing contexts.
Q11. Context degradation
A debugging session has run for days. The context is cluttered with old command output and obsolete hypotheses. Files have also changed. Best next step?
A. Keep resuming forever B. Fresh start with structured summary and targeted re-analysis C. Add a longer system prompt D. Use PostToolUse
Answer
B. Clean context plus curated summary is the correct architectural reset.
Q12. Session vs filesystem
A developer resumes a session and assumes it snapshots/reverts file changes. What is wrong?
A. Sessions persist conversation history, not the filesystem B. Sessions cannot contain tool calls C. Resume deletes previous messages D. Fork always reverts files
Answer
A. Session history and filesystem versioning are different.
Q13. Checkpointing
A user wants to experiment with a code change and quickly undo Claude's edits if it fails. What is relevant?
A. Session resume only B. Checkpointing or version control C. Memory store D. Handoff summary
Answer
B. Checkpoints help with local undo; Git remains the durable version-control mechanism.
Q14. Branch switch trap
Claude Code remembers conversation history after a branch switch, but sees the current branch's files. What is the risk?
A. Claude cannot read files B. Conversation history may reference previous-branch assumptions C. Fork is impossible D. The session is deleted
Answer
B. Branch/file changes can create stale assumptions in conversation history.
Q15. External session store
An autoscaled worker system needs any replica to resume any agent session after redeploys. What should be used?
A. Local transcript files only B. External session store such as S3, Redis, or database-backed storage C. Fork every session D. Manual copy-paste summaries only
Answer
B. Multi-host deployments need shared session storage.
Memory hooks
- Resume = continue same valid context (
--continue= most recent;--resume <session_id>/--resume <name>= specific). - Fork (
fork_session/--fork-session) = branch for alternatives from a shared baseline. - Fresh + summary = clean baseline when old context is stale.
- Targeted re-analysis = inform the session about specific file changes; re-check changed files only, not the whole repo.
- Resume vs fresh: resume when prior context is mostly valid; fresh-start-with-injected-summary when prior tool results are stale.
- Fork does not fix stale context — it copies the stale history too.
- Session state is not durable memory.
- Memory persists across sessions but must be governed (read-only against untrusted input).
- Workflow/business state belongs in code or external systems, not prompt text.
- A paused session means waiting for external input, not finished.
- Sessions persist conversation history, not the filesystem; use checkpointing/Git for file undo.
- Multi-user and multi-host deployments need explicit session IDs and external session stores.