[BUG] Rewind said it couldn't restore, but still overwrote ~20h of edits across the project and deleted files created since (conversation not rewound)

Based on the transcript and file-history evidence in this report, this appears to be a particularly serious failure mode: the restore reports failure while still changing files on disk, without rewinding the conversation. Could the team investigate the restore failure path and ensure it is atomic (or preserves a recoverable pre-restore snapshot) before it mutates files? I have not independently reproduced this, so I am relying on the reporter’s evidence.

Thanks for flagging it. Here are reproduction steps, put together from the session's own transcript and file-history records. The rewind action itself isn't recorded in the transcript, so the two UI details in step 6 are from memory and marked "not sure".

The session

• Claude desktop app, Code tab (entrypoint: claude-desktop), Claude Code 2.1.212, Windows 11 (10.0.26200)
• Permission mode: bypassPermissions. Model: Opus 5.5
• Project folder inside a OneDrive-synced folder, mostly not under git

How big it was at the moment of the rewind

| | |
|---|---|
| Session length | 26 hours (2026-10-10T03:01Z to the rewind at 2026-10-11T05:06Z) |
| Transcript (.jsonl) | 494 MB, 23,991 records |
| Human prompts | 104 |
| Assistant records | 8,142 (4,445 with tool calls) |
| file-history-snapshot records | 105 |
| file-history-delta records | 133 |
| Files tracked by file history | 135 in the project (the largest snapshot lists 276 entries) |
| ~/.claude/file-history/<session> | 756 backup files, 32 MB |
| Auto-compactions | 5 (10-05 05:35Z, 10-10 04:03Z, 10-10 09:21Z, 10-10 13:59Z, 10-11 00:55Z) |

Steps

1. Run a long session in the desktop app that edits many files with Edit and Write, long enough to auto-compact several times.
2. Send a user message right after one of those compactions. In my session that is d9a26ecd-e314-4aa5-81b3-c47e8b3a46f5 ("Okay its been restarted", 2026-10-10T09:53:56Z), the first message after the compact boundary at 09:21:12Z. Its file-history-snapshot is empty (trackedFileBackups: {}, 0 files). The previous non-empty snapshot is for 039124d7-1685-434a-ab87-f07ad7a0f7c0 (276 entries, 09:09:05Z), before that compaction.
3. Keep working past at least one more compaction (mine: 13:59Z and 2026-10-11T00:55Z), editing files and creating new ones with Write.
4. Get stuck on safeguard refusals. Three responses in a row were stopped (model_refusal_no_fallback, category reasoning_extraction, at 05:02:59Z, 05:04:47Z and 05:05:23Z). After the first I kept talking to Opus: two more messages (05:04:30Z, 05:05:04Z), both refused the same way. So the conversation's last entry was a synthetic API-error message (f0a986e5-f277-4cb4-9d2b-bd83f3eaf101), not a real response.
5. About a minute later, open rewind and choose one of my "restarted" messages, most likely d9a26ecd above. All three candidates are from before the latest compaction:

• 8e3abbf8 (10-10 08:05Z, its snapshot lists 264 files)
• d9a26ecd (10-10 09:53Z, 0 files, first message after a compaction)
• 8e42ce7b (10-10 12:21Z, 18 files)

1. How rewind was opened: not sure. Which option was chosen (code and conversation, or code only): not sure.
2. The UI says it can't do it. The conversation is not rewound.

Result

• At 05:06:00Z the tracked files were rewritten in the same second, to the snapshot of 039124d7 (09:09:05Z): 102 of 135 files are byte-identical to it. That is about 45 minutes before d9a26ecd, and 20 hours of work after it was lost.
• 8 files created with Write after that point were deleted.
• Files saved by other programs (not tracked) were left alone, so the project became a mix of old and new files.
• Nothing about the restore is written to the transcript. The next turn just carries the reminder "The user restored files to how they were at an earlier point in this conversation, without rewinding the conversation to that point."

What I think is happening (not confirmed)

1. The file restore isn't cancelled when the conversation rewind fails. The target is before the latest compaction, so the conversation part can't be done ("can't do it"), but the files are restored anyway.
2. The first message after a compaction has an empty snapshot, so restoring to it seems to fall back to the previous non-empty snapshot from before the compaction. That would explain the files landing 45 minutes before the message I picked.

After the rewind

• I switched to Sonnet 5.5 (/model at 05:06:21Z). It worked normally straight away: no refusals from its first reply at 05:07:08Z onwards.
• I switched back to Opus 5.5 at 05:23:35Z, and Opus was fine again too: normal replies from 05:23:53Z, same session. So the refusals didn't persist.

I can share the snapshot and file-history records privately if they'd help.

Thanks @AlexC1991 for reconstructing the sequence from the transcript and file history. The empty post-compaction snapshot and the byte comparisons provide concrete cases for the core team to investigate.

One qualification to my earlier comment: because the exact target and selected action were not recorded, the unchanged conversation alone does not establish that the conversation rewind failed; a code-only restore would normally leave it unchanged. The reported failure message, overwritten files and missing new files still warrant investigation. The two proposed causes should remain hypotheses until reproduced.

A controlled test in a disposable project could compare code-only and code-and-conversation restores across a compaction boundary, including an empty target snapshot, files created afterward and externally edited files. For each action, it should verify the resolved target, final files and conversation, and that a failed restore preserves or can recover the pre-restore file state. I have not reproduced this on Windows or in the desktop runtime, so the incident evidence remains your reconstruction.