{"version":"2.1.280","anchor":"rewindfork-snapshot-restore-now-detects-worktree-changes-si","canonical_anchor":"rewindfork-snapshot-restore-now-detects-worktree-changes-si","heading":"Rewind\/fork snapshot restore now detects worktree changes since the snapshot was read","tier":"notice","area":"Sessions","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.280\/e\/rewindfork-snapshot-restore-now-detects-worktree-changes-si","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.280","markdown":"### Rewind\/fork snapshot restore now detects worktree changes since the snapshot was read\n\nRewind\/fork restore now refuses to apply a snapshot if worktree files changed since it was taken\n\n**What**\n\nRewind and fork let you restore a project's files to an earlier saved snapshot. The restore logic now compares the snapshot's recorded file states against the current state of the working files (the worktree) before applying it. If any tracked file, or its file metadata, changed after the snapshot was taken, the restore is refused with a \"not applied\" result and reason `worktree_changed`, instead of applying a now-stale snapshot on top of newer changes.\n\n**Why**\n\nThis prevents rewind or fork from silently overwriting file changes made after a snapshot was captured, which could otherwise cause quiet data loss.\n\n- Area: Sessions\n- Tier: You'll notice\n- Useful: 3\/5\n- Signal: 2\/5"}