- In short
- Claude Code session management is the set of mechanisms for saving, returning to, and branching an agent conversation. The three options are resume (continue a saved session with its full history), fork_session (branch a copy that diverges while leaving the original untouched), and a fresh start where you inject a structured summary of prior findings into a brand-new context.
The three Claude Code session management options
Claude code session management starts from one fact: every conversation is written to disk automatically as you work. A session is the accumulated history of a run, your prompts, every tool call the agent made, every tool result it received, and every response it produced. Because that history is saved, you are never forced to throw it away. You get to choose how you come back to it, and there are exactly three choices worth memorising for the foundations exam.
The first option is to resume the session and keep adding to the very same thread. The second is to fork it, branching a copy that diverges while the original stays intact. The third is to abandon the live transcript entirely and start fresh, seeding a brand-new session with a hand-written summary of what mattered. Each option answers a different question about the state of your work, and recognising which one a situation calls for is the whole point of this knowledge point.
- Session
- A saved conversation tied to a project directory. Claude Code stores it locally as a JSONL transcript so you can resume where you left off, branch to try a different approach, or switch between tasks. It persists the conversation, not the filesystem.
What each option actually does
Resume picks up an existing session and continues writing to it. From the CLI there are two entry points that confuse people, so pin the difference down now. claude --continue reopens the most recent session in the current directory with nothing to remember, which is perfect when you are hopping back into the thing you were doing an hour ago. claude --resume instead opens an interactive picker, or, when you pass a name or ID, jumps straight to that specific session. Use continue when "the last thing" is obviously right; use resume when several threads live in the same folder and you need to land on a particular one. In the Agent SDK the same idea appears as the resume option, which takes a captured session ID.
Fork is the option people reach for too late. Forking creates a new session that begins as a copy of the original's history and then diverges. The fork receives its own session ID; the original's ID and history are left untouched, so you end up with two independent threads you can return to separately. You trigger it with /branch inside a session, or by combining --continue or --resume with --fork-session on the command line, or with fork_session=True in the SDK. Forking is the right tool whenever you want to try a direction without burning the path you were on.
A fresh start with summary injection is the option with no flag. You deliberately do not reopen the transcript. Instead you open a clean session and paste a structured brief of the findings, decisions, and open questions that actually matter, then carry on from there. This deserves its own treatment, which is why it is covered in depth in summary injection for fresh sessions. For now, hold the idea that "start over" does not have to mean "lose everything."
Where sessions live and why it matters
Knowing the storage model removes most of the mystery. Claude Code writes each transcript as JSON Lines to ~/.claude/projects/<project>/<session-id>.jsonl, where the project folder is derived from your working directory. Every line is one message, tool use, or metadata entry. Two consequences fall straight out of this. First, sessions are scoped to a directory, which is why --continue only ever finds the most recent session in the folder you launched from. Second, the files are local to one machine and are removed after thirty days by default, so a session is a convenience, not a permanent archive.
The most exam-relevant consequence is what is not stored. A session persists the conversation history only. It does not snapshot your files. If the agent edited code during a session, those edits are real on disk right now, and resuming the session restores the transcript of what was said, not the state of the repository. Reverting files is a separate feature called checkpointing. Architects who conflate the two are surprised when resuming an old session does not undo yesterday's changes.
Managing context inside a live session
The three re-entry options decide how you come back to a session, but Claude Code also gives you controls for shaping context while a session is open, and the official session docs treat this as its own concern. These commands do not create or branch a session; they manage the context window of the one you are already in, which is why architects sometimes overlook them when they picture session management as only resume, fork, and fresh start.
Three commands cover it. /clear starts fresh with an empty context while keeping the previous conversation saved and resumable, so it is the in-session way to drop accumulated history without abandoning the thread on disk. /compact replaces the conversation history with a summary, and you can focus that summary by passing instructions, for example /compact keep the auth decisions. /context shows what is currently consuming the window, which is how you decide whether a clear or a compact is even warranted. Together they let you keep a long-running session healthy instead of being forced into a fresh start the moment the window fills.
It is worth separating all of this from persistent memory, because the exam likes the distinction. Every Claude Code session begins with a fresh context window; durable, cross-session knowledge does not ride along in the transcript but comes from CLAUDE.md files and auto memory, which are loaded at the start of every session and themselves consume context tokens. Resuming a session restores its conversation, but it is CLAUDE.md and memory, not session continuation, that carry standing facts about a project from one session to the next.
How resuming and forking differ under the hood
The cleanest mental model is to watch the session ID. When you resume, the ID stays the same and new turns are appended to the existing transcript, so the thread simply gets longer. When you fork, the runtime copies the history into a new transcript with a new ID and lets that copy evolve on its own; the source transcript is never written to again. That single difference, same ID versus new ID, is what makes resume a continuation and fork a branch.
This is also why the exam likes to test the pair together. A learner who only half-remembers the feature will say "they both reopen an old conversation," which is true but useless. The discriminating detail is that resume mutates one thread while fork creates a second one. If a question describes needing the original to remain available for later comparison, the answer is fork; if it describes simply carrying on, the answer is resume.
Naming and finding your sessions
Two practical mechanics make the three options usable at scale, and the exam expects you to know they exist. The first is naming. A bare session is hard to find later, so you can give one a descriptive name at startup with claude -n auth-refactor, rename it mid-flight with /rename, or let Claude Code name it for you when you accept a plan in plan mode. Once named, a session is resumable directly with claude --resume <name>, which is far less error-prone than hunting for a raw identifier.
The second mechanic is the picker. Running /resume inside a session, or claude --resume with no argument, opens an interactive list of sessions for the current worktree, each row showing the name or a conversation summary, the time since last activity, the message count, and the git branch it belongs to. Keyboard shortcuts widen the search when you need it: one widens to every worktree of the repository, another to every project on the machine. There is even a claude --from-pr <number> entry point that jumps straight to the session linked to a pull request. None of this changes the three options, but it is the connective tissue that makes resuming and forking ergonomic across a real working day.
The CLI surface and the Agent SDK surface
It helps to see that the same three options appear in two places. In the interactive CLI you reach them through flags and slash commands: --continue, --resume, --fork-session, and /branch. In the Agent SDK you reach the same behaviours through options on a query() call, where resume takes a captured session ID and fork_session branches a copy. One subtlety the SDK exposes is that sessions created non-interactively with claude -p or through the SDK do not appear in the interactive picker, yet you can still return to one by passing its ID to claude --resume. The lesson for the exam is that session management is a single concept with two front doors, and a question framed in SDK terms is testing the same judgment as one framed in CLI terms.
Why this knowledge point matters for the exam
Task Statement 1.7 sits inside Domain 1, Agentic Architecture and Orchestration, the most heavily weighted domain at 27 percent of the exam. Session management shows up most directly in Scenario 4, Developer Productivity with Claude, where an engineer is moving between tasks across a working day. At this knowledge point the Bloom level is remember: you are expected to recall the three options and state precisely what each does. The harder judgment calls, choosing between them and recognising when context has gone stale, build on top of this recall and are handled in the knowledge points this one unlocks.
Treat this page as the vocabulary you must own before the analysis questions make sense. Once "resume, fork, fresh start" is automatic, the decision framework in when to resume vs fork vs fresh start has somewhere solid to stand.
Worked example
An engineer wraps up a feature investigation on Friday and faces three different Monday-morning situations.
On Friday the engineer spent two hours in a Claude Code session named auth-refactor, reading code, running tests, and settling on a plan. Monday brings three possible situations, and each maps to a different option.
If nothing changed over the weekend and the engineer simply wants to keep going on the same plan, the answer is resume: claude --resume auth-refactor restores the entire thread, including the agent's earlier analysis, with no re-work. If instead the engineer wants to keep Friday's plan safe but try a bolder alternative approach in parallel, the answer is fork: claude --resume auth-refactor --fork-session branches a copy so both directions can be compared later, and the original auth-refactor thread stays exactly as it was. And if a colleague rewrote half the touched files over the weekend, the answer is neither, because the session now contains tool results that no longer match the code. The reliable move there is a fresh start with a short brief of the decisions that still hold.
Notice that the engineer's goal barely changed across the three situations. What changed was the state of the work: is the prior context still valid, do I need the original preserved, and have the files moved underneath me. Reading those signals is the skill; the three options are just the moves available.
Common misreadings to avoid
Misconception
--resume and fork_session do the same thing; they both just reopen an old conversation.
What's actually true
Misconception
A Claude Code session saves and restores the files Claude edited, so resuming rewinds my code to where it was.
What's actually true
How it shows up on the exam
Questions on this knowledge point rarely ask you to recite a flag. They describe a developer who wants to carry on, or to branch, or to escape a polluted thread, and ask which mechanism fits. The correct answer always comes back to the same three definitions: resume to grow one thread, fork to create a divergent second thread from a copy, and a fresh start to leave a stale transcript behind while keeping a curated summary. Lock those down and you will not be fooled by an option that sounds plausible but quietly does the wrong thing.
A developer ran a long analysis in Claude Code yesterday and now wants to try a different refactor today without losing the original thread, so the two approaches can be compared later. Which session option fits best?
People also ask
What is the difference between --continue and --resume in Claude Code?
How do you fork a session in Claude Code?
Where are Claude Code sessions stored?
Watch and learn
Official Anthropic Academy lessons first, then hand-picked walkthroughs. Videos load only when you press play.
Resume Claude Code Conversations FAST with One Simple Command
Why watch: Teaches the --resume/--continue commands to reopen a named session with its full prior context intact, the first of the three session-management options.
More videos for this concept
References & primary sources
Master this concept with Archie
Practice it inside an adaptive study session. Archie, your Socratic AI tutor, tracks your mastery with Bayesian Knowledge Tracing and schedules the perfect next review.