Session State, Resumption, and Forking

The Claude Code session state surface is the hidden backbone of Domain 1.7 on the Claude Certified Architect — Foundations (CCA-F) exam. Task statement 1.7 — "Manage Claude Code session state, resumption, and forking" — sits inside Domain 1 (Agentic Architecture & Orchestration, 27% weight), and community pass reports consistently flag two to three scenario-based questions per sitting that turn on subtle differences between resuming, forking, and starting a fresh Claude Code session state. If you misread how Claude Code session state is persisted, replayed, or branched, you will misread the rest of the scenario — because every coordinator-subagent design, every CI/CD rerun, and every multi-day feature delivery built on top of Claude Code session state semantics.

This study note walks through the entire Claude Code session state surface an architect-level candidate is expected to master: the difference between --resume <session-name> and fork_session, what exactly gets persisted in Claude Code session state between turns, how stale tool results corrode a resumed Claude Code session state after code changes, when a structured summary plus a new Claude Code session state beats naive resumption, the parallel exploration pattern that fork enables on top of Claude Code session state, and how /compact and /memory interact with the Claude Code session state lifecycle. The Code Generation with Claude Code scenario and the Developer Productivity with Claude scenario both lean heavily on Claude Code session state — expect questions from either cluster to probe this Claude Code session state surface. A dedicated "Common Exam Traps" section and a Practice Anchors section translate the theory into the exact shapes the CCA-F exam tests around Claude Code session state.

What Is Claude Code Session State? Scope and Lifecycle

Claude Code session state is the durable, serializable representation of an in-progress conversation between you and Claude Code. A Claude Code session state contains every user turn, every assistant turn, every tool call Claude issued, every tool result your environment returned, any hooks that fired, and the metadata binding the Claude Code session state to a working directory and a set of available MCP servers. A Claude Code session state is what Claude Code writes to disk so that closing your terminal at 6 PM and reopening it at 9 AM the next morning does not erase three hours of careful Claude Code session state construction.

A Claude Code session state is not the same as the context window. The context window is the working-memory slice Claude currently sees during one inference call; the Claude Code session state is the complete transcript history, of which the context window is only a windowed view. When the conversation grows long, the context window compacts — but the Claude Code session state on disk remains the full-fidelity record of every turn in the Claude Code session state transcript.

Why Claude Code Session State Matters on CCA-F

The CCA-F exam draws the Code Generation with Claude Code and Developer Productivity with Claude scenarios from a pool of six. Both scenarios revolve around week-long feature deliveries, CI/CD reruns, incremental refactors, and multi-agent orchestration where Claude Code session state spans many terminal sessions, many branches, and many machines. The exam tests whether you can:

• Resume the right Claude Code session state instead of starting a polluted new one.
• Fork a Claude Code session state when two parallel approaches must be explored independently.
• Recognize when a Claude Code session state has become stale and must be discarded in favor of a structured summary plus a fresh Claude Code session state.
• Distinguish Claude Code session state from CLAUDE.md content and from the context window.

Miss any one of these and the distractors in Domain 1.7 questions on Claude Code session state will pick you off.

The Lifecycle of a Claude Code Session State

Every Claude Code session state moves through a predictable lifecycle:

1. Creation — a new Claude Code session state is created when you launch claude in a directory or start a new Agent SDK conversation. The Claude Code session state is given an auto-generated name unless you pass one explicitly.
2. Growth — user turns and assistant turns (with embedded tool calls and tool results) are appended to the Claude Code session state transcript.
3. Compaction — when the Claude Code session state transcript approaches the context-window limit, /compact or automatic compaction produces a condensed summary that stands in for older turns.
4. Persistence — the Claude Code session state is written to disk continuously, indexed by session name and working directory.
5. Resumption — --resume <session-name> (or the Agent SDK equivalent) rehydrates the Claude Code session state on a later day, terminal, or machine.
6. Forking — fork_session creates a divergent branch from a shared baseline Claude Code session state, leaving the parent Claude Code session state untouched.
7. Retirement — Claude Code session state records can be left dormant or explicitly abandoned; Claude Code does not automatically delete Claude Code session state on disk, which can accumulate.

The --resume Flag: What It Does and What It Does Not Do

The --resume <session-name> flag is the primary way to re-enter a specific prior Claude Code session state from the command line. It rehydrates the conversation transcript into Claude's context and lets you continue speaking as if you never left the Claude Code session state.

Continuing a Specific Prior Conversation

--resume is precise. You pass the session name, and Claude Code loads that exact Claude Code session state — not the most recent one, not a similar one, but the named one. If you routinely work on three features in parallel, claude --resume feature-auth-rewrite and claude --resume feature-billing-migration give you two distinct continuations of two distinct Claude Code session state records, one per session, without cross-pollution.

The flag is scoped to the working directory the Claude Code session state was created in. Resuming a Claude Code session state from a different directory may fail outright or produce path-mismatch errors when Claude tries to read files that have moved. Architects designing multi-repo workflows should keep Claude Code session state creation tightly bound to the repo root so the resume contract holds.

Why the Exam Tests --resume So Hard

CCA-F scenarios for Code Generation and Developer Productivity frequently hide the right answer behind a question like: "A developer spent yesterday afternoon walking Claude Code through a complex refactor of the authentication module. This morning they open a new terminal and want to continue where they left off. What should they do?" The correct action is claude --resume <session-name> pointing at the prior afternoon's Claude Code session state. Distractors typically suggest:

• Starting a brand-new Claude Code session state and re-pasting yesterday's context. Wrong — wastes context budget and loses tool-result fidelity.
• Using /compact in a new Claude Code session state. Wrong — /compact operates on the current Claude Code session state transcript; there is no transcript yet in a new Claude Code session state to compact.
• Forking yesterday's Claude Code session state via fork_session. Wrong — fork creates a branch, but the developer wants to continue the trunk of the existing Claude Code session state, not diverge from it.

The exam rewards candidates who can eliminate each distractor from first principles of Claude Code session state semantics.

fork_session: Independent Branches from a Shared Baseline

Where --resume continues a Claude Code session state, fork_session branches it. A fork takes the current Claude Code session state as a baseline and produces a new, independent Claude Code session state that starts with the same history but evolves separately. The parent Claude Code session state is left untouched; the child Claude Code session state can diverge without polluting the trunk.

The Canonical Fork Scenario: Two Testing Strategies from One Analysis

Imagine a Developer Productivity with Claude scenario: a senior engineer has spent an hour walking Claude Code through a large codebase, discussing its structure, pointing out module boundaries, and asking Claude to summarize the existing test coverage. This analysis lives inside a Claude Code session state called codebase-analysis. Now the engineer wants to explore two testing strategies:

• Branch A: property-based tests using Hypothesis, layered over the existing pytest suite.
• Branch B: snapshot tests using pytest-regressions, replacing integration tests.

Both branches share the same baseline Claude Code session state. Re-explaining the codebase twice would waste an hour and introduce inconsistencies between the two Claude Code session state records. Starting each branch in a fresh Claude Code session state would discard the analysis. The correct architectural move is to fork_session from the shared baseline, producing two independent Claude Code session state branches:

parent Claude Code session state: codebase-analysis (baseline)
├── fork: test-strategy-property-based
└── fork: test-strategy-snapshot

Each forked Claude Code session state evolves independently. The engineer can compare the two forks side by side, pick a winner, and optionally discard the loser without touching the trunk Claude Code session state.

Fork as a Context-Isolation Primitive

Fork also matters for context isolation across Claude Code session state boundaries. A subagent spawned from a coordinator can fork the coordinator's Claude Code session state up to a specific point, run its independent work inside the forked Claude Code session state, and return results without polluting the coordinator's transcript. The Agent Teams documentation describes this pattern explicitly: coordinator Claude Code session state stays clean because subagents operate on forked Claude Code session state, not shared Claude Code session state.

Parent-Child Independence Is Permanent

Once forked, changes in the child Claude Code session state never propagate back to the parent automatically. If the property-based-tests fork discovers a critical design flaw, the engineer must manually carry that insight back to the parent Claude Code session state or to a new fork. Fork creates independence between Claude Code session state records, not synchronization. This is an exam-level distinction: candidates who assume "fork changes flow back up through Claude Code session state" will design broken orchestration systems.

Resume vs Fork vs New Session: The Claude Code Session State Decision Tree

These three primitives — resume, fork, new — cover every Claude Code session state transition the exam tests. A decision tree makes the choice mechanical for any Claude Code session state question.

The Decision Tree

1. Does the new work continue the exact same trajectory as the prior Claude Code session state?
   • Yes → --resume <session-name>.
   • No → continue to step 2.
2. Does the new work share substantial context with the prior Claude Code session state but needs to diverge independently?
   • Yes → fork_session from the prior Claude Code session state.
   • No → continue to step 3.
3. Has the environment changed materially since the prior Claude Code session state (files modified, dependencies upgraded, branch switched) such that the prior transcript is stale?
   • Yes → start a new Claude Code session state, seed it with a structured summary.
   • No → continue to step 4.
4. Default — start a new Claude Code session state without a summary. This is the right move only when no prior Claude Code session state is relevant.

Why the Decision Tree Matters

The CCA-F exam presents scenario stems where the naive choice on Claude Code session state is wrong. A developer "resumes" a Claude Code session state from three days ago after a major rebase — and the Claude Code session state is full of references to files that no longer exist. The correct architectural move is not to resume; it is to produce a structured summary of the prior Claude Code session state's decisions, start a new Claude Code session state, and feed the summary in as context. Stale tool results inside the old Claude Code session state will otherwise mislead Claude for the rest of the new Claude Code session state.

Naming Claude Code Session State for Discoverability

--resume requires a session name. A Claude Code session state called session-2026-04-23-afternoon is hard to find a week later. Architects designing team-wide Claude Code workflows should adopt naming conventions: feature/auth-rewrite-v2, bugfix/billing-rounding-issue, refactor/user-service-split. Consistent naming turns Claude Code session state persistence into a discoverable knowledge base across a team of engineers sharing Claude Code session state records.

Stale Tool Results: The Silent Killer of Resumed Claude Code Session State

The single highest-severity failure mode of Claude Code session state resumption is the stale tool result. When Claude reads a file with the Read tool, the tool result — the file's contents at that moment — is embedded in the Claude Code session state transcript forever. When you resume the Claude Code session state a day later, that tool result is still there. But the file on disk may have changed since the Claude Code session state was last written.

How Stale Tool Results Corrode a Claude Code Session State

Scenario: Yesterday you asked Claude Code to read src/auth/session.py. The Read tool returned the file's contents, which got pinned into Claude Code session state. Overnight, you (or a colleague, or a rebase) edited that file — added a new function, removed a parameter, refactored a helper. This morning you --resume the Claude Code session state and ask Claude to add a new test case. Claude, looking at its internal record of src/auth/session.py inside the Claude Code session state, generates code that:

• References a helper that no longer exists.
• Expects a parameter that was removed.
• Misses the new function entirely.

The generated code fails. Claude did not hallucinate — Claude was reading the Claude Code session state, which contained yesterday's truthful Read result. The tool result is stale; the Claude Code session state is compromised.

Informing the Agent About File Changes

When you resume a Claude Code session state after code modifications, you must explicitly inform the agent about what changed. Options for refreshing a Claude Code session state:

• Re-read affected files — the simplest fix. Ask Claude to run Read on the files that changed. The fresh Read result supersedes the stale one in context (though the stale one is still present in the Claude Code session state transcript).
• Run git diff or equivalent — give Claude a tool-result that shows the exact change, so it can reconcile internal Claude Code session state with the live filesystem.
• Provide a prose changelog — for large rebases, a paragraph summarizing "I rebased onto main and resolved conflicts in X, Y, Z" gives Claude enough to re-orient inside the resumed Claude Code session state.
• Abandon the Claude Code session state — if too much changed, resuming is a losing proposition. Start fresh with a structured summary and a new Claude Code session state.

Why Resumption After Major Changes Is Often Wrong

The Agent SDK documentation is explicit: resumption of a Claude Code session state preserves transcript fidelity but does not re-validate it against the live environment. Architects who design automation around --resume without a change-detection step on Claude Code session state will ship broken pipelines. The exam tests this directly — it will present a scenario with hours of gap plus a mention of rebases or upgrades, and the correct answer will be "start a new Claude Code session state with a structured summary" rather than "resume the old Claude Code session state."

Structured Summaries: When New Claude Code Session State Beats Resume

The structured summary is the architect's escape valve from a stale Claude Code session state. When a Claude Code session state has accumulated hours of history but the environment has moved on, the right move is to produce a concise, structured summary of what was learned, start a new Claude Code session state, and seed it with that summary.

What Goes in a Structured Summary Handoff

A well-formed structured summary for a coding Claude Code session state handoff typically includes:

• Goal — one to two sentences on what the prior Claude Code session state was trying to achieve.
• Decisions made — architectural choices, patterns adopted, libraries selected during the prior Claude Code session state.
• Current state of the code — which files were modified and in what way during the prior Claude Code session state.
• Open questions — unresolved ambiguities the prior Claude Code session state flagged.
• Next steps — the specific action the new Claude Code session state should take first.

A good summary is 200–600 tokens. A bloated summary defeats the purpose of starting a new Claude Code session state — if you need 5000 tokens to summarize, you are not summarizing, you are re-pasting.

The /compact Command and Its Limits on Claude Code Session State

/compact is the built-in Claude Code slash command that asks Claude to compact its own Claude Code session state transcript. It replaces older turns with a Claude-generated summary, freeing context window space inside the same Claude Code session state. Key differences between /compact and a cross-session handoff:

• /compact operates on the current Claude Code session state transcript in place. The original transcript inside that Claude Code session state is replaced with a summary.
• /compact cannot cross Claude Code session state boundaries — it is not a "copy this summary to a new Claude Code session state" primitive.
• /compact is best used as preventive maintenance when a Claude Code session state is approaching context limits, not as crash recovery after a Claude Code session state has become stale.

The /memory Command and Long-Term Knowledge

/memory is distinct from /compact and from Claude Code session state itself. Where /compact shortens the current Claude Code session state transcript, /memory surfaces the CLAUDE.md memory files that seed every new Claude Code session state. /memory is about durable, cross-session instructions; /compact is about ephemeral, within-Claude Code session state space management. Architects mixing the two primitives produce broken mental models of Claude Code session state. The exam rewards clean separation of /memory, /compact, and Claude Code session state persistence.

When Summary-and-New Beats Resume for Claude Code Session State

The exam tests five scenarios where a new Claude Code session state with a structured summary beats --resume on the old Claude Code session state:

• Major code changes between Claude Code session state writes (merges, rebases, refactors).
• Dependency upgrades that change APIs Claude had read inside the prior Claude Code session state.
• Branch switches where the working directory now shows different files than the Claude Code session state transcript reflects.
• Token-bloated Claude Code session state approaching the context limit even after /compact.
• Subagent handoffs where the subagent needs an isolated Claude Code session state, not the coordinator's full history.

If a scenario mentions any of these triggers, the answer is structured summary plus new Claude Code session state — not resume, not fork.

The Parallel Exploration Pattern: Fork Claude Code Session State for A/B Comparison

Fork enables a specific, high-value architectural pattern on Claude Code session state: parallel exploration. The engineer builds a shared analysis in one Claude Code session state, forks it into two or more branches, runs each branch to completion, and compares outcomes across the forked Claude Code session state records.

Two Testing Strategies from Shared Codebase Analysis

The canonical exam scenario: "A senior engineer spends an hour with Claude Code analyzing a legacy codebase inside a single Claude Code session state. The engineer wants to evaluate two testing strategies without re-running the analysis. What is the most efficient approach?"

Correct answer: fork the Claude Code session state twice from the shared analysis baseline, run each testing strategy in its own forked Claude Code session state, compare results. Distractors suggest:

• Run both strategies sequentially in the same Claude Code session state. Wrong — the first strategy's code will pollute the Claude Code session state for the second strategy.
• Start two new Claude Code session state records and re-paste the analysis. Wrong — wastes an hour of context-building and risks summarization errors.
• Use subagents without forking the Claude Code session state. Wrong — subagents can solve the isolation problem but introduce orchestration overhead; forking Claude Code session state is the simpler primitive.

Three API Design Options from Shared Requirements

Another common shape: "A product team wants Claude to generate three candidate API designs from a shared requirements Claude Code session state. Which approach minimizes context rebuilding?"

Fork the requirements-analysis Claude Code session state three ways, one per candidate design. Compare the three forked Claude Code session state records, pick the winner.

Migration-Path Exploration

For infrastructure scenarios: "An SRE needs to evaluate migrating from PostgreSQL to two different databases. The baseline analysis lives in a Claude Code session state. Which pattern?"

Fork the baseline PostgreSQL-analysis Claude Code session state, one fork per candidate target. Each forked Claude Code session state explores migration mechanics independently.

The pattern recurs across every Code Generation and Developer Productivity scenario that involves Claude Code session state. Memorize it as a reflex.

Plain-Language Explanation: Claude Code Session State

The abstract mechanics of Claude Code session state become intuitive when anchored to physical, everyday systems. Three analogies cover the full sweep of Claude Code session state behavior.

Analogy 1: The Kitchen Pantry and the Open Recipe Card

Imagine you are cooking a week-long braise. The pantry is your Claude Code session state — the full inventory of ingredients, half-finished preparations, notes pinned to the fridge, and the open recipe card with your running annotations. The context window is the section of the counter where you are currently working: a subset of the pantry (the Claude Code session state) is within arm's reach at any moment.

When you step away Thursday evening and return Friday morning (--resume on the Claude Code session state), you pick up exactly where you left off. The braise is still in the oven, the mise-en-place is still laid out, your annotated recipe card is still on the counter. Continuing the Claude Code session state in place is efficient because nothing material has changed overnight.

Now imagine you want to test two variations of the same braise: one with red wine, one with stout. You don't empty the pantry twice; you fork the recipe. You copy the open recipe card, tape it to a second baking dish, and diverge from the shared starting Claude Code session state. Both dishes share the same mirepoix and the same meat cut; they diverge only in the liquid. Fork lets you evaluate both paths without duplicating an hour of prep on the underlying Claude Code session state.

Now imagine that overnight, a housemate reorganized your pantry. Jars moved, labels changed, one ingredient got used up. If you blindly continue the braise by reading the old recipe card's annotations ("the salt is on the second shelf"), you'll fail — stale tool results inside the Claude Code session state. The right move is to pause, inventory the pantry fresh, and write a one-paragraph structured summary ("using this meat, this wine, these vegetables") to hand to yourself as the opening instruction of a new cooking Claude Code session state.

Analogy 2: The Git Branch and the Working Tree

Claude Code session state maps cleanly onto git mental models, which most CCA-F candidates already carry.

• Claude Code session state transcript is the commit history of a branch.
• --resume <session-name> is git checkout <branch> — you re-enter the branch of Claude Code session state and continue adding commits linearly.
• fork_session is git checkout -b new-branch <base-ref> — you create a new branch of Claude Code session state from a specific point in another branch's history and evolve it independently.
• Stale tool results are like a working tree that was never git pulled — your local view (inside the Claude Code session state) is out of date with reality, and actions built on that view will conflict.
• Structured summary + new Claude Code session state is like archiving a long-lived branch, writing a concise changelog, and starting a new branch from main with that changelog pinned to the top.
• /compact is like squashing many commits into one summary commit — it preserves the essence of the Claude Code session state but loses the granular history.
• /memory is like the repo's shared README — every new Claude Code session state starts with the same README; it is not Claude Code session state–specific.

If you reach for this analogy mid-exam, the right Claude Code session state primitive usually becomes obvious.

Analogy 3: The Open-Book Exam with Two Different Problem Sets

Picture a student at an open-book exam. The student has spent three hours building up a notebook of worked examples on a specific topic — call it calculus of residues. That notebook is the Claude Code session state. The proctor now hands the student two different problem sets that both require the same background theory. The student wants to attempt both from the same Claude Code session state.

Option 1 (wrong): Solve problem set A, then use the same notebook to solve problem set B. The Claude Code session state is now cluttered with A's scratch work; B's solutions will be harder to read and may be contaminated by A's choices.

Option 2 (wrong): Throw away the notebook and start fresh twice. Wastes three hours of theory work inside the Claude Code session state.

Option 3 (right — fork): Photocopy the notebook twice. Label one copy "Problem Set A scratch," the other "Problem Set B scratch." Solve each on its own copy. Compare, pick a winner, archive the loser. This is fork_session on Claude Code session state in one picture.

Now imagine between exam halves, the proctor announces that a theorem the student had been relying on was updated — the statement has a new hypothesis. The student's notebook still has the old statement pinned in place. Continuing to use the notebook Claude Code session state without re-reading the new theorem statement will lead to wrong answers. The right move is to write a one-paragraph summary of what was accomplished in the first half, hand it to a new notebook (new Claude Code session state), and re-derive from the current theorem. Stale tool results plus structured summary handoff in one picture.

Context Window vs Claude Code Session State: Do Not Confuse Them

A surprisingly common CCA-F mistake is conflating the context window with Claude Code session state. They are related but distinct.

The Context Window

The context window is the live, in-memory representation of the conversation that Claude sees during one inference call. It has a hard token limit (model-dependent; Claude 4 models support very large windows but still finite). The context window is ephemeral — it is reconstructed every turn from the underlying Claude Code session state.

Claude Code Session State

Claude Code session state is the persisted, on-disk record of the full conversation. There is no hard practical limit on Claude Code session state size; it can grow indefinitely as a Claude Code session state accumulates turns. Claude Code session state is durable — it survives process exit, terminal close, and machine reboot.

How They Interact

Every inference call starts by loading Claude Code session state into a context window. If the full Claude Code session state transcript fits in the context window, the full transcript is loaded. If it does not, compaction kicks in: older turns inside the Claude Code session state are replaced by a summary before being fed to Claude. The full Claude Code session state remains on disk even if the context window only sees a compacted view.

The Exam Trap

A CCA-F question will describe a developer who has "run out of context" after a long Claude Code session state and ask what to do. The right answers involve /compact (shrink the current Claude Code session state transcript), a structured summary plus new Claude Code session state (full reset with preserved insight), or fork (branch the Claude Code session state for isolation). The wrong answer will suggest that --resume itself solves the context problem — resuming rehydrates the same Claude Code session state transcript that overflowed in the first place.

/compact and /memory: Adjacent Claude Code Session State Primitives

Two slash commands routinely appear as distractors on Claude Code session state questions. Know exactly what each does.

/compact

/compact compresses the current Claude Code session state transcript in place, replacing older turns with a Claude-generated summary. The Claude Code session state name and identity are preserved; only the transcript body changes. Use /compact when a Claude Code session state is still useful but is approaching context limits.

/memory

/memory surfaces and edits the CLAUDE.md memory hierarchy: global, project, directory. Memory files are seeded into every new Claude Code session state automatically; they are not Claude Code session state–specific. /memory is the right primitive for durable, cross-session instructions ("always use pytest," "never edit legacy/*.py without explicit permission"); it does not persist or restore any specific Claude Code session state.

Keyword Disambiguation

• "Current Claude Code session state is getting long, keep the same context but make it fit" → /compact.
• "Every new Claude Code session state should know our coding standards" → /memory, not /compact.
• "Bring back yesterday's Claude Code session state" → --resume, not /compact, not /memory.
• "Branch two approaches from today's shared Claude Code session state" → fork_session, not /compact, not /memory.

Exam writers routinely mix these four Claude Code session state primitives in a single question's answer choices. Candidates who do not practice the disambiguation fail.

Common Exam Traps: Claude Code Session State Pitfalls on CCA-F

CCA-F aggressively exploits five recurring trap patterns tied to Claude Code session state.

Trap 1: Resume After a Rebase

Answer choices pit --resume against "new Claude Code session state with structured summary." The scenario will mention a rebase, a merge, or a significant overnight change. Candidates who default to --resume on the old Claude Code session state fall into stale-tool-result failure. The correct answer is almost always new Claude Code session state with structured summary.

Trap 2: Fork When You Meant Resume

A developer wants to "continue" a Claude Code session state — the work is linear, not branching. A distractor suggests fork_session. Fork is wrong here because it creates a sibling Claude Code session state, not a continuation. If the engineer only wants one branch of the Claude Code session state going forward, --resume is correct.

Trap 3: /compact Presented as a Cross-Session Primitive

An answer choice claims that /compact can copy a summary from one Claude Code session state into a fresh Claude Code session state. False — /compact operates only on the current Claude Code session state transcript. Cross-session summary handoff between Claude Code session state records requires manually copying a summary into the opening message of a new Claude Code session state.

Trap 4: Assuming Subagents Inherit Full Claude Code Session State

CCA-F Domain 1.3 tests this explicitly; it bleeds into 1.7. Subagents do not automatically receive the coordinator's Claude Code session state. If a scenario describes a coordinator spawning a subagent and expecting the subagent to "know what we were just discussing," the correct architectural move is either fork_session at the spawn point of the coordinator's Claude Code session state or explicit context passing via the subagent's opening instruction inside its own fresh Claude Code session state.

Trap 5: Confusing /memory with Claude Code Session State Persistence

An answer choice suggests that /memory can be used to "save the current Claude Code session state for later." Wrong — /memory edits CLAUDE.md files, which are Claude Code session state–seeding instructions, not Claude Code session state storage. Claude Code session state is persisted automatically by Claude Code; there is no manual save command to invoke on Claude Code session state.

Practice Anchors: Code Generation and Developer Productivity Scenario Shapes

CCA-F practice questions tied to Claude Code session state cluster into six shapes, drawn from the Code Generation with Claude Code and Developer Productivity with Claude scenarios.

Shape A: Next-Day Continuation

"A developer ended yesterday's Claude Code session state mid-feature. Nothing has changed overnight. Which command?" Correct: claude --resume <session-name> on the prior Claude Code session state. Distractors: new Claude Code session state, fork, /compact.

Shape B: Post-Rebase Resumption

"A developer resumes a Claude Code session state; overnight another engineer merged a PR that touched three files the Claude Code session state had read. Claude now produces incorrect code." Correct: abandon the old Claude Code session state, produce a structured summary, start new Claude Code session state, re-read files inside the new Claude Code session state. Distractors: /compact, different session name, "ignore previous context."

Shape C: Parallel A/B Exploration

"An engineer wants to evaluate two testing strategies from a shared Claude Code session state of codebase analysis without rebuilding context." Correct: fork_session twice from the shared baseline Claude Code session state. Distractors: sequential in one Claude Code session state, two fresh Claude Code session state records, subagent spawning.

Shape D: Coordinator-Subagent Handoff

"A coordinator Claude Code session state has spent significant context building a plan; it now spawns a subagent to execute one step. The subagent must know the plan but should not pollute the coordinator Claude Code session state." Correct: fork the coordinator's Claude Code session state at the spawn point, or pass a structured summary as the subagent's opening instruction inside a fresh Claude Code session state. Distractors: assume subagent inherits the coordinator's Claude Code session state automatically, use /memory.

Shape E: Context-Limit Recovery

"A Claude Code session state has accumulated hours of turns and is approaching the context-window limit. The developer wants to continue the same linear work." Correct: /compact to shrink the current Claude Code session state transcript in place. Distractors: start new Claude Code session state, fork, /memory.

Shape F: Cross-Team Knowledge Handoff

"A developer wants to hand a complex feature off to a colleague who will continue the work tomorrow on their own machine and their own Claude Code session state." Correct: structured summary delivered as an opening instruction in the colleague's new Claude Code session state. Distractors: share Claude Code session state file directly (fragile, path-dependent), /memory (instructions, not Claude Code session state).

Memorizing these six shapes covers the vast majority of Domain 1.7 questions the exam will draw on Claude Code session state.

Distinction Note: What CCA-F Does Not Test About Claude Code Session State

CCA-F is foundational. Several adjacent topics are explicitly out of scope and should not consume Claude Code session state study time.

Out of Scope for CCA-F

• Fine-tuning, RLHF, and model-weight manipulation.
• Vision and computer-use API specifics.
• Streaming API implementation details.
• Rate limiting and token-counting algorithms on Claude Code session state.
• Cloud provider configurations — Bedrock, Azure AI, GCP Vertex bindings on Claude Code session state are all out of scope.
• Prompt caching internals.

If you catch yourself studying any of these in the context of Claude Code session state, redirect. The exam tests the architect-level behaviors of Claude Code session state primitives, not the underlying storage implementation or the cloud routing of Claude Code session state data.

What CCA-F Does Expect

• Recognize --resume, fork_session, /compact, and /memory as distinct primitives with distinct scopes over Claude Code session state.
• Apply the stale-tool-results test to decide between resume and new-with-summary on Claude Code session state.
• Design parallel exploration with fork_session on Claude Code session state.
• Hand off work between humans and between agents using structured summaries seeded into new Claude Code session state.
• Avoid the five trap patterns in Common Exam Traps on Claude Code session state.

Claude Code Session State Frequently Asked Questions (FAQ)

What is the difference between --resume and fork_session on the CCA-F exam?

--resume <session-name> rehydrates a specific persisted Claude Code session state and continues it in place — same Claude Code session state name, linear continuation, no branching. fork_session creates a new, independent Claude Code session state by branching from an existing Claude Code session state at a point in its transcript; parent and child Claude Code session state records evolve independently and never merge automatically. Use resume when the work is linear ("continue yesterday's feature" on the same Claude Code session state); use fork when the work diverges from a shared baseline Claude Code session state ("try two testing strategies from the same analysis"). The keyword disambiguation is continuation (resume) versus divergence (fork).

When should I start a new Claude Code session state instead of resuming?

Start a new Claude Code session state whenever the environment has changed materially since the prior Claude Code session state was written: files were edited by other contributors, dependencies were upgraded, a rebase or merge happened, or the git branch has switched. In those cases the prior Claude Code session state's tool results are stale — they pin an outdated view of files into the transcript — and resuming will cause Claude to generate code that references functions, parameters, or files that no longer exist. The right recovery is to produce a structured summary of decisions and current state, start a new Claude Code session state, and seed it with the summary as the opening user turn.

What are stale tool results and why do they matter for Claude Code session state?

Stale tool results are persisted tool-call return values inside a Claude Code session state that no longer match the current state of the underlying resource. When Claude Code ran Read on src/auth.py yesterday, the file's contents at that instant were embedded in the Claude Code session state transcript. If the file was edited overnight, that embedded content is now outdated inside the Claude Code session state. Resuming the Claude Code session state replays the stale content into Claude's context, and Claude treats it as authoritative — leading to code that references removed functions, misses new functions, or assumes obsolete signatures. The CCA-F exam tests stale tool results directly: when a scenario mentions a rebase, a merge, or a dependency upgrade between Claude Code session state writes, the correct answer rejects resume and chooses a structured-summary handoff into a fresh Claude Code session state instead.

How do /compact and /memory differ from --resume and fork_session?

/compact and /memory are Claude Code session state–internal slash commands; --resume and fork_session are Claude Code session state–boundary primitives. /compact shrinks the current Claude Code session state transcript in place by summarizing older turns — useful for freeing context-window space mid-session, not useful for crossing Claude Code session state boundaries. /memory views and edits CLAUDE.md memory files, which seed every new Claude Code session state with durable instructions — useful for cross-session standards, not useful for preserving any specific Claude Code session state transcript. --resume reopens a specific prior Claude Code session state by name. fork_session branches a Claude Code session state into independent children. The CCA-F exam routinely mixes all four in answer choices; memorize the scope of each.

Can I use fork_session to create a subagent?

Yes — fork is one of the two primary patterns for coordinator-subagent context isolation on Claude Code session state. When a coordinator forks its own Claude Code session state at the spawn point and hands the forked Claude Code session state to a subagent, the subagent has the coordinator's full history as shared baseline but can evolve independently without polluting the parent Claude Code session state. The alternative is an explicit structured-summary handoff, where the coordinator writes a concise summary and the subagent starts a fresh Claude Code session state with that summary as its opening instruction. Fork is more accurate (nothing is lost in summarization between Claude Code session state records) but heavier (full transcript is duplicated); summary handoff is lighter but requires the coordinator to correctly identify what the subagent needs to know.

How should I name Claude Code session state records for long-running projects?

Adopt a naming convention for Claude Code session state that makes resumption discoverable across days and team members. Good patterns: feature/auth-rewrite-v2, bugfix/billing-rounding, refactor/user-service-split, exploration/property-based-tests. Avoid auto-generated names like session-2026-04-23-afternoon — they are impossible to match to intent a week later when you need to pick the right Claude Code session state to resume. Claude Code session state names are the key you will pass to --resume <session-name>, so treat them like short-lived branch names in a team convention for Claude Code session state.

Does resuming a Claude Code session state reset the context window?

No. Resuming rehydrates the full Claude Code session state into context, and if the transcript of that Claude Code session state exceeds the context-window limit, automatic or manual compaction kicks in. Resuming does not give you a fresh context budget; it restores whatever state the Claude Code session state had when last persisted. If a Claude Code session state was already bumping up against context limits before being paused, resuming the same Claude Code session state will reproduce the same constraint — sometimes immediately. For context-limit recovery, /compact shrinks the current Claude Code session state transcript; for a true fresh budget, start a new Claude Code session state with a structured summary.

Further Reading

• Agent SDK Session Management (resume, fork): https://docs.anthropic.com/en/docs/claude-code/sdk/sdk-sessions
• Agent SDK Subagents and Fork Semantics: https://docs.anthropic.com/en/docs/claude-code/sdk/subagents
• Orchestrate Teams of Claude Code Sessions: https://code.claude.com/docs/en/agent-teams
• Agent SDK Overview (hooks and session APIs): https://docs.anthropic.com/en/docs/claude-code/sdk/sdk-overview
• Context Windows and Compaction: https://docs.anthropic.com/en/docs/build-with-claude/context-windows
• Long-Context Prompting Tips: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/long-context-tips
• Claude Code Features Overview: https://docs.anthropic.com/en/docs/claude-code/overview

Related ExamHub topics: Agentic Loops for Autonomous Task Execution, Multi-Agent Coordinator-Subagent Patterns, Context Management in Large Codebases, CLAUDE.md Hierarchy and Modular Organization, Plan Mode vs Direct Execution.