1.7 Session State, Resumption & Forking

Real work rarely fits in a single sitting. You investigate a codebase on Monday, go home, and want to pick up exactly where you left off on Tuesday. Or you reach a decision point and want to try two different approaches without losing your place. Task Statement 1.7 is about exactly this: how an agent's conversation — its session — is saved, resumed, branched, and, crucially, how to avoid a subtle trap where picking up an old session feeds the agent information that's no longer true.

A session is simply a saved conversation tied to a project. Everything the agent and you have said, plus the results of every tool it ran, is stored so you can return to it later. There are three distinct things you might want to do with a saved session, and the entire lesson hinges on choosing the right one for your situation. Get it wrong and you'll have an agent confidently reasoning from stale facts.

The three options are: resume (continue a conversation right where it stopped), fork (branch a copy to try a different direction while keeping the original), and fresh-start-with-summary (begin a brand-new conversation but hand it a written summary of where things stand). Think of a session like a saved video game. You can LOAD your save and keep playing (resume); you can COPY the save into a second slot and try a risky path without ruining your main game (fork); or you can START a new game but carry over a written recap of the story so far (fresh start). Same save, three very different moves.

Resuming is the simplest move: you reopen a saved conversation and continue, with the full prior history restored. The agent remembers everything it knew when you left — the files it read, the conclusions it drew, the half-finished plan. It's loading your saved game and pressing play.

In Claude Code this is a handful of flags. claude --continue reopens the most recent session in the current directory — the quickest 'pick up where I left off.' claude --resume opens a picker so you can choose among saved sessions, and claude --resume <name> jumps straight to a named one (you can name sessions so they're easy to find later). There's even claude --from-pr <number> to reopen the session that created a particular pull request.

Resume is the right choice when the prior context is still VALID — nothing important has changed since you left. If you were reasoning about code on Monday and that code is untouched on Tuesday, resuming is perfect: why re-do all that analysis? But hold onto that condition — 'when the context is still valid' — because it's precisely where the trap in section 1.7.4 springs.

Sometimes you reach a fork in the road — two reasonable approaches, and you want to try both without committing. Say you've spent an hour analysing a codebase and now face a choice: refactor it one way, or a completely different way. You don't want to lose that hour of shared analysis, and you don't want the two experiments to contaminate each other. That's what forking is for.

Forking takes everything up to this moment — the shared baseline — and creates an independent branch you can explore freely, leaving the original conversation untouched and available. It's copying your save into a second slot: you keep the hard-won progress, but anything you do in the branch can't ruin the original. You can fork from inside a session with /branch, or from the command line by combining --fork-session with --continue or --resume. Forked sessions even group neatly under their root in the picker, so you can see the family tree.

The keyword for fork is divergent exploration from a shared baseline. Use it to compare two refactoring strategies, two testing approaches, two designs — anything where you want to branch from a common starting point. And note the boundary carefully, because the exam tests it: forking is for exploring alternatives, NOT for escaping stale information. A fork copies the baseline as-is, including any out-of-date facts in it — so if your baseline is stale, both branches inherit the same staleness. Forking duplicates the problem; it doesn't cure it.

Here is the trap the exam loves, and it's worth slowing right down for. Picture this: on Monday your agent analyses a 50-file codebase and reads every file into its context. You then spend the afternoon EDITING several of those files. On Tuesday you resume the session to keep working. The agent dutifully reasons from what it remembers — but what it remembers is the OLD contents of files you've since changed. It gives you advice based on code that no longer exists, and worse, it can contradict itself, mixing old memories with any new reads.

This is the stale-context problem. The cached tool results from Monday's reads are now wrong, but they're still sitting in the conversation, exerting their pull. And here's the part that trips people up: the obvious fix — 'just resume and ask the agent to re-read the changed files' — is NOT enough. Why? Because the stale results are still in context, sitting right alongside the fresh reads, and the model has to somehow reconcile two contradictory versions of the same file. You haven't removed the bad information; you've just added good information next to it.

The reliable cure is the third option from section 1.7.1: start a FRESH session — one with no stale results at all — then inject a structured summary of where things stand, and explicitly NAME the files that changed so the agent re-reads exactly those. This gives you a clean slate plus precise, current information. Notice the efficiency too: if only 3 of the 50 files changed, you re-read just those 3 (targeted re-analysis), not the whole codebase again (full re-exploration). Clean context, current facts, minimal waste.

The 1.7 traps cluster around two confusions: mixing up which of the three moves fits a situation, and — most of all — treating fork as a staleness remedy when it only duplicates the staleness. Map the situation to the move and they're straightforward.

Two distractors show up again and again. The first: using fork to 'get a clean start' after edits — but a fork copies the stale baseline, so both branches are equally wrong. The second: re-exploring all 50 files when only 3 changed — wasteful when targeted re-analysis of the 3 changed files is precise and cheap. Keep the question 'is the old context still TRUE?' front of mind: if yes, resume; if you want alternatives, fork; if it's gone stale, start fresh with a summary.

You now have the three session moves, the flags that trigger them, and — most importantly — the stale-context trap and its cure. The exercise has you reproduce the trap deliberately, because seeing the agent give confidently wrong advice from a stale memory is what makes the fresh-start discipline stick.

This completes Domain 1. Step back and see the arc: you learned the loop you control (1.1), how to coordinate teams of agents and pass them context (1.2–1.3), how to guarantee behaviour with enforcement and hooks (1.4–1.5), and how to structure the work itself across decomposition and sessions (1.6–1.7). Every later domain — tools, Claude Code, prompting, context management — builds on this foundation of how agentic systems actually run.