During one turn, Claude Code renames a directory by running mv in a shell command, then edits three source files with its file-editing tools. You rewind to before that turn. What is on disk afterwards?

The principle — checkpoint coverage is decided per change by which tool made it, not per turn and not by how significant the change looks.

Why the key is correct — two rules settle this and they are stated separately. Before Claude edits a file, it snapshots the current contents, which is what allows the three source files to be restored. And checkpointing does not track files modified by bash commands, because only direct file edits made through Claude's file editing tools are tracked. The rename went through the shell, so no snapshot was ever taken for it and the rewind has nothing to put back. What you are left with is a partially reverted working tree: three files at their earlier contents, sitting inside a directory that still has its new name.

Why the others are wrong — treating the turn as the unit assumes the mechanism works chronologically, when it works by provenance; two changes seconds apart can land on opposite sides of the line. Reverting the rename while keeping the edits inverts the rule exactly, and it is worth noticing that this is the intuition most people start with, because a directory rename feels like the bigger event. And an untracked change does not invalidate a checkpoint for everything else; the tracked edits still revert normally.

Remember this — this is the failure mode that bites hardest, because the rewind reports success. Read what came back rather than trusting that everything did.

Sources — Anthropic's How Claude Code works and the checkpointing page.