Contesto obsoleto e ripartenza

Claude Code lets you continue work across days. --resume <name> reopens a named session with its full message history intact: the prompts, the model's reasoning, and crucially the tool results that were captured the first time.

That replay is powerful. But it hides a sharp edge: those tool results are a snapshot of the past, not a live view of your system. This lesson is about recognizing when that snapshot has gone stale and what to do instead.

Remember how the API works: the model keeps no state of its own. Every turn you send the full messages history — including prior tool_result blocks. The model reasons over whatever those blocks say.

A resumed session simply reloads that saved history. If a Read captured a file's contents last Tuesday, the model still believes Tuesday's version today — even if the file changed ten times since.

Stale context is when the resumed tool results no longer match reality. Common triggers:

• A teammate edited the same files between sessions.
• A migration changed the database schema the model had cached.
• A dependency bump altered an API the model read earlier.
• A build artifact or test output captured earlier is now obsolete.

The danger: the model proceeds confidently on outdated facts, producing edits that conflict with the current codebase.

You have two recovery levers when a session ages:

• --resume <name> continues the named session, replaying its full saved history.
• fork_session branches from a shared point — useful for exploring an alternative without disturbing the original.

Both inherit the old tool results. When the codebase has drifted substantially, neither is ideal. Sometimes a fresh session seeded with a structured summary beats resuming, because it forces every fact to be re-fetched against current reality.

Ask one question: has the ground truth changed since the session was captured?

• Little or no drift (you paused for an hour, no one else touched the repo) → --resume is fine and cheap.
• Significant drift (days passed, merges landed, schema migrated) → start fresh and re-summarize the goal, then let the model re-fetch live tool results.

This is a context-management reliability call — domain D5 on the exam.

"Summarize anew" means: carry forward the intent and decisions, but drop the frozen tool outputs so they get re-acquired. You write a compact, structured summary of where the task stands, then open a clean session with that summary as the opening prompt.

The model then runs Read, Grep, and Bash against the current codebase — no stale snapshot to mislead it.

Progressive summarization is lossy: it makes numbers, percentages, and dates vague. When your summary must preserve exact values — a version pin, a row count, a deadline, an order ID — don't fold them into prose.

Pull them into a separate "case facts" block kept verbatim, outside the narrative summary. The summary can compress the story; the facts block stays exact.

In a fresh session the discipline is simple: investigate before mutating. Use the incremental pattern — Grep entry points, Read the files, Grep usages, Read consumers — so every edit is grounded in current contents.

This is also why Edit uses a unique-match contract: if the file drifted and your expected text no longer matches uniquely, the edit fails loudly rather than corrupting the file. Re-Read and retry.

/compact compresses the current conversation to free context space. It is useful, but it carries the same lossiness risk: numbers and dates can become vague. It does not solve staleness — the compacted facts are still from the original captures.

Starting fresh is different: you discard the old tool results entirely and re-derive them live. Use /compact for a long but still-accurate session; start fresh when the underlying system has moved on.

This staleness lesson rhymes with multi-agent design. Subagents do not inherit the coordinator's conversation history — all context must be passed explicitly in each subagent prompt.

The same hygiene helps you: when you hand a fresh session (or a subagent) a structured summary plus a verbatim facts block, you are doing deliberately what resume does accidentally — except you control exactly which facts survive and you force live re-fetching of the rest.

Before resuming a stale session, run this gate:

• Drift? Did the repo/schema/deps change since capture? If yes → lean fresh.
• Summarize goal, decisions made, and remaining TODOs.
• Preserve exact numbers/dates/IDs in a verbatim facts block.
• Re-fetch live: Grep → Read before any Edit.
• Verify against current state, not the remembered one.

Cheap to resume when nothing moved; cheap insurance to start fresh when it did.

Test your judgment on the resume-vs-fresh decision.

Key takeaways:

• Resumed sessions replay frozen tool results because the model holds no state and reasons over the full saved history.
• When the system has drifted (merges, migrations, dependency bumps), those results are stale and can drive confident-but-wrong edits.
• When drift is significant, start fresh and summarize anew rather than --resume or fork_session, which both inherit the old snapshots.
• Keep exact numbers, dates, and IDs in a verbatim case-facts block; summarization makes those vague.
• Re-fetch live (Grep → Read) before any Edit; /compact saves space but does not cure staleness.