Your project contains a config file that your dotfile manager symlinks in from elsewhere. Claude edits that file and two ordinary source files, then you restore the code from the rewind menu. What should you expect?

The principle — being tracked and being restorable are two different conditions, and a file can satisfy the first without the second.

Why the key is correct — Anthropic states that checkpointing doesn't rewind symlinked or hard-linked files, and names the outcome: skipped files keep their current contents. The two ordinary source files were edited through Claude's file editing tools, so they are tracked and they come back. The config file was edited the same way and is tracked too, but the restore step refuses to write through the link, so it is passed over and stays as Claude left it. What makes this worth knowing is how ordinary the setup is: a dotfile manager linking config into a project, or a package manager hard-linking files into place, produces exactly this shape without anyone having done anything unusual.

Why the others are wrong — assuming the editing tool decides everything conflates tracking with restoring; the skip happens later, at write time. Expecting the whole restore to abort misreads a skip as a failure, when the restore completes for every path it can write and tells you how many it passed over. And there is no whole-tree snapshot, though that is not even the obstacle here — the snapshot exists, and the write is what declines.

Remember this — after a restore, read the count of skipped files rather than the word restored. A linked config that silently kept its new contents is a config drift you will meet later.

Sources — Anthropic's checkpointing page.