One Claude Code Tip a Day: Resume Only With a Fresh Brief

This post is part of the “One Claude Code Tip a Day” series — a daily guide to using Claude Code more effectively.

Resuming a Claude Code session feels efficient, but it is also one of the easiest ways to let stale assumptions write code. Yesterday’s context may include a failed test that has since been fixed, a branch that was rebased, a half-written plan, or a debugging theory you no longer believe. If you simply reopen the thread and say “continue,” Claude may preserve the wrong mental model with impressive confidence.

Today’s habit is to resume only with a fresh brief. Whether you use an in-app resume flow, `claude --resume`, or a saved project conversation, treat the first five minutes as a re-orientation pass, not a coding pass. The goal is to make Claude restate the current reality from the repo, the diff, and the latest command outputs before it edits anything.

The real task: a bug fix that spans two work sessions

Imagine you started fixing a flaky checkout test late at night. Claude inspected the Playwright spec, guessed that a toast animation was racing the assertion, and added a small wait. The test still failed once, so you stopped. The next morning, a teammate pushed a related change to the payment mock, your branch has two uncommitted edits, and the CI failure now points at a different selector.

A shallow resume prompt is: “Continue fixing the checkout test.” That is risky because it rewards continuity over truth. A better prompt is: “Resume this session, but do not edit yet. Rebuild the brief from the current repository. Read the uncommitted diff, the failing test output I paste below, and the relevant checkout files. Summarize what still seems true, what may be stale, and the next smallest verification step.”

Then paste the latest failure, not last night’s memory: `!pnpm test:e2e checkout --reporter=line`, the CI log excerpt, or the screenshot path. If Claude Code can run shell commands in your environment, ask it to collect the evidence itself: `!git status --short`, `!git diff -- tests/checkout app/checkout`, and the narrowest failing test command. The command examples matter because they force the resumed session to anchor itself in files and outputs instead of vibes.

Make Claude separate memory from evidence

The best first answer after a resume should sound cautious. It should say something like: “The prior theory was a toast animation race, but the current diff only changes the selector wait. The new failure shows the payment mock returns pending for 30 seconds. Before editing, we should verify whether the selector failure is a symptom of the mock never resolving.” That is the moment the resumed session becomes useful.

Ask for three buckets: confirmed facts, stale assumptions, and open questions. Confirmed facts come from the current repo or command output. Stale assumptions are what the earlier conversation believed but has not rechecked. Open questions are the minimum unknowns blocking the next patch. This format prevents Claude from blending old reasoning into new evidence.

Use the resume brief to control the next edit

Once Claude has rebuilt the brief, give it a narrow continuation instruction: “Patch only the smallest code path needed to test the current hypothesis. Keep the previous unrelated cleanup out of this pass. After editing, rerun the same failing command and review the diff for accidental scope creep.”

For the checkout example, that might mean adjusting the payment mock fixture, not touching the UI component. Or it might mean reverting last night’s wait because the selector was never the bug. Resumed sessions are especially vulnerable to patch accumulation: one small wait, one helper rename, one test fixture tweak, one refactor. The fresh brief lets you say which previous edits still deserve to exist.

Second-pass correction: verify the branch, not just the answer

After Claude proposes or applies a fix, run a second pass that is specific to resumed work: “Compare the current branch against main. Which changes are from the old session, which are from this pass, and which are still justified by the evidence? Identify anything we should revert before committing.”

This is where `git diff` becomes the honesty check. A resumed session can accidentally keep yesterday’s speculative changes even after the theory changes. Ask Claude to inspect `!git diff --stat`, then the actual diff. If it cannot explain why each changed file is necessary for the current failure signal, remove the file from the patch or split it into another task.

Also rerun the original proof command, not only a broader comfort command. If the checkout test failed, rerun that test. If a deployment log showed a missing environment variable, redeploy or fetch the new logs. A clean typecheck is nice, but it does not prove the resumed task is fixed unless typechecking was the original signal.

Failure modes to watch for

The first failure mode is “context loyalty.” Claude tries to honor the old plan even when the repo has moved. Fix it by asking what changed since the prior session. The second is “diff blindness.” Claude sees the final files but forgets why they changed. Fix it with a file-by-file diff review. The third is “verification drift.” The session starts with one failing command and ends by showing a different green command. Fix it by making the original proof command part of the resume brief.

Another common mistake is resuming with too much pasted history. Do not paste the whole transcript unless necessary. Give Claude a compact brief plus current evidence: goal, branch, failing signal, relevant files, and constraints. Let it read the repo for details. Long transcripts can make stale reasoning feel more authoritative than the current code.

Rule of thumb

Never let a resumed Claude Code session edit from memory. First ask it to rebuild the brief from today’s repo, today’s diff, and today’s failure signal. If the old plan still survives that check, continue. If it does not, you just saved yourself from polishing yesterday’s wrong answer.