Resume and Rewind Restore the Session, Not Your Experiment

Claude Code has two ways back into earlier work, and neither returns the repo to the state your results came from.

Resume brings back the conversation. Per the session documentation, claude --resume ablate-lr restores the conversation history and, in most cases, the model and permission mode it used. /branch copies the conversation so you can try another approach and keep the original. Files are not part of either, so two sessions in one checkout still edit the same files. The conversation returns with claims about your repo: "we are on ablate-lr," "the config uses a learning rate of 3e-4," "the last eval scored what it scored." Since then someone may have rebased, another session may have edited the config, or a run may have overwritten the results.

Rewind brings back some files. Checkpointing tracks edits made through Claude's file-editing tools, plus the conversation. The documentation lists what it does not restore: files changed by shell commands (rm, mv, cp and anything your training script writes), most subagent edits, changes made outside the session including other concurrent sessions, and symlinked or hard-linked files. Snapshots are limited to the 100 most recent checkpoints in a session and cleaned up about 30 days after the session last saved one, by default.

So Claude lowers the learning rate in config.yaml, runs the training script, which writes results.csv, and you rewind. The config comes back. The results file stays, holding numbers from a config that no longer exists, and nothing marks it as orphaned.

The documentation puts the fix in one line: checkpoints do not replace version control. Make every output name the code that produced it. Commit before a run, write outputs under runs/$(git rev-parse --short HEAD)/, and treat both the conversation and rewind as conveniences, not records.

The check, after every resume or rewind:

git rev-parse --abbrev-ref HEAD   # the branch the conversation names?
git status --short                # edits you did not expect?
git rev-parse --short HEAD        # the runs/<commit>/ you are about to cite?

Then rerun the last test or the smallest eval the session relied on and compare it with the number in the conversation. If they differ, trust the rerun and tell the session, so its later reasoning starts from the current state. A difference is also a finding: something changed between sessions, and you should know what before you report either number.

To see the rewind gap once before you rely on it, use a scratch repository. Ask Claude to change one line of a.txt (a file edit), then run echo new > b.txt (a shell command). Rewind to the prompt before both and choose Restore code. Per the documentation, a.txt reverts and b.txt keeps its new contents.

Sessions that run at the same time need separate worktrees, and even those share the GPU and the results directory: see worktrees separate files, not experiments. Reporting only numbers you can rerun is the habit Chapter 20 of the book builds.