[BUG] Edit tool silently destroys some files in OneDrive-synced folders via non-deterministic delete-then-rename race (Windows)

Preflight Checklist

• [x] I have searched existing issues
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code (2.1.161 CLI / 2.1.150 VSC extension)

Summary

CC's Edit (and presumably Write) tool implements file modification using two different write patterns non-deterministically:

• Safe pattern: atomic rename-over. Temp file is written, then atomically renamed over the original (single OS operation). No window where the file is absent.
• Unsafe pattern: explicit delete-then-rename. Temp file is written, then the original is explicitly deleted, then the temp is renamed to the original's name. There is a window of up to 1+ seconds where the file does not exist on disk.

For OneDrive-synced files in a certain sync-engine state (apparently: stable / long-quiescent / fully-synced — see "Trigger conditions" below), when CC happens to use the unsafe pattern, OneDrive's sync engine sees the explicit delete event before the rename completes. It then treats the operation as a user-initiated delete, propagates the delete to the cloud, and deletes the new local file to match the cloud state.

Net effect: the user's file is silently destroyed. CC reports the Edit as successful. No error, no warning. Only OneDrive's cloud recycle bin saves the user's data (time-bounded).

What Should Happen

CC's Edit should always use atomic rename-over (MoveFileEx / ReplaceFile with MOVEFILE_REPLACE_EXISTING), not explicit delete + rename. We observed CC's Edit using the safe pattern in some calls — so the safe implementation exists. The fix is to use it consistently.

Evidence

Original incident: file destroyed twice deterministically

Target file: a 182,397-byte markdown file in an OneDrive-synced workspace folder, last modified 10 days before the incident (long quiescent in OneDrive sync).

Two CC Edits performed (a normal substantive edit and later a tiny single-line edit). Both edits caused immediate file deletion. Captured via PowerShell FileSystemWatcher running in the directory during the second repro:

=== Second-repro kill on llm-errors.md (180KB) ===
01:51:43.447  Changed  llm-errors.md           ← OneDrive cloud-restore write
01:51:43.465  Changed  llm-errors.md           ← OneDrive cloud-restore write
01:52:21.822  Created  llm-errors.md.tmp.37680.c116f043d353   ← CC temp file
01:52:21.823  Changed  llm-errors.md.tmp.37680.c116f043d353   ← temp content write
01:52:21.824  Changed  llm-errors.md.tmp.37680.c116f043d353   ← temp content write
01:52:21.826  Deleted  llm-errors.md           ← ⚠️ CC explicitly deletes original
01:52:22.829  Renamed  llm-errors.md (was: temp)  ← 1003ms later
01:52:22.836  Created  unp14017203252260805487.tmp   ← OneDrive internal staging
01:52:23.844  Created  asw-e8c9af1c-5a7b-4335-b43e-f57b5c531552  ← OneDrive internal staging
01:52:23.845  Changed  llm-errors.md           ← OneDrive processing
01:52:23.846  Deleted  llm-errors.md           ← ⚠️ OneDrive DELETES new file
01:52:23.847  Deleted  asw-...                  ← OneDrive cleanup
01:52:24.855  Deleted  unp...tmp                ← OneDrive cleanup

Key observations:

• CC at 01:52:21.826 issues an explicit Delete on llm-errors.md BEFORE the rename. This is the trigger event.
• The Delete→Rename gap is ~1 second for this 180KB file.
• OneDrive emits its own internal staging files (asw-*, unp-*) and then issues Deleted on the file, propagating CC's delete event to the cloud.

Probe experiment: identical size, identical pattern, FAILED to reproduce

To isolate variables, a fresh 8KB probe file was created in the same OneDrive directory, then grown to 179KB via in-place PowerShell writes (which do NOT trigger CC's write patterns). Five CC Edits were then performed at various sizes from 18KB to 179KB.

| Test | File size | CC write pattern | Delete→Rename gap | OneDrive reaction | Survived? |
|---|---|---|---|---|---|
| TEST 09 | 99KB | Delete-then-Rename | 1008 ms | None | ✓ |
| TEST 10 | 149KB | Delete-then-Rename | 1014 ms | None | ✓ |
| TEST 11 | 179KB | Atomic rename-over | (operations within 1 ms, opposite order) | None | ✓ |
| TEST 12 | 179KB | Delete-then-Rename | 1 ms | None | ✓ |
| TEST 13 (60s quiesce) | 179KB | Atomic rename-over | (operations within 1 ms) | None | ✓ |
| Original kill (twice) | 180KB | Delete-then-Rename | 1003 ms | asw-+unp- staging, then Deleted | ✗ |

This shows three independent observations:

1. CC's Edit write pattern is non-deterministic. Across 5 probe Edits, three used delete-then-rename (with gaps of 1ms, 1008ms, 1014ms) and two used atomic rename-over. Same tool version, same file, same session — different patterns per call.

1. CC's unsafe delete-then-rename pattern is necessary but not sufficient. Probe TEST 10 used the same dangerous pattern with the same ~1s gap as the destroyed file, but OneDrive did NOT react — only Changed events, no staging, no delete propagation. The probe file survived.

1. The differentiator is OneDrive's reaction-state for the specific file. For the destroyed file, OneDrive's sync engine actively processed the delete event (emitted staging files, propagated delete to cloud). For the probe, OneDrive coalesced the delete+rename into a modification event and did not propagate any delete.

Trigger conditions (hypothesis — not fully verified)

The destroyed file had been quiescent in OneDrive for 10 days (last modified May 25, killed June 4). The probe was being actively modified throughout the experiment (created and grown over the preceding 20 minutes). A 60-second quiescence on the probe was insufficient to reproduce.

Working hypothesis: OneDrive's sync engine handles file events differently based on the file's tracking state. Stable / long-quiescent / fully-synced files get rigorous per-event processing (including treating CC's explicit delete as a real delete). Actively-modified files get debounced/coalesced event handling that masks the bug.

This means the bug:

• Is silent and deterministic for vulnerable files (the original was killed both times)
• Is not reproducible on a freshly-created probe even at identical size
• Likely affects any sufficiently-stable / long-untouched file in a OneDrive-synced folder
• Cannot be bisected on a fresh probe — would require letting a file sit untouched for hours/days before testing

Steps to Reproduce

Direct reproduction requires a file that has been quiescent in OneDrive for an extended period (exact threshold unknown; observed at 10 days). Not reproducible on a fresh-and-actively-modified file.

For Anthropic engineers attempting reproduction:

1. On Windows 11 with OneDrive sync active, identify a file in a OneDrive-synced folder that has not been modified for at least 24 hours and is fully synced.
2. Run CC's Edit tool against it with any string replacement.
3. Immediately check the file via Get-Item or Test-Path.
4. Observe: file is deleted. CC reported Edit as successful.

Indirect verification: capture file events with PowerShell FileSystemWatcher during a CC Edit on any OneDrive file. Observe that CC's Edit sometimes uses explicit Delete followed by Rename (unsafe) and sometimes uses an atomic rename pattern (safe). Independent of OneDrive: this inconsistency itself is the bug.

Environment

• OS: Windows 11 Home, build 26200
• CC CLI: 2.1.161
• VS Code extension: anthropic.claude-code-2.1.150
• OneDrive: 26.084.0504.0007
• Hydration state of affected file: locally hydrated (Offline attribute NOT set; all files in the test were Archive, ReparsePoint and locally present)
• Affected path: a markdown file in an OneDrive-synced workspace subfolder (specific path withheld; details available on request)

Suspected Regression

User reports having used CC on this OneDrive-synced workspace extensively in prior sessions without encountering this. Suggests recent regression in CC's Edit implementation introduced (or made more frequent) the explicit delete-then-rename pattern. Reviewer should be able to confirm via diff of the Edit tool's file-write implementation between recent versions.

Related Issues (different mechanisms, same area)

• #62140 (2026-05-25) — Cowork silently corrupts files in OneDrive folders with Files-On-Demand. Different surface (Cowork vs CC-VSC) and different mechanism (read-side placeholder confusion vs write-side delete-rename race), but same OneDrive context.
• #62085 (2026-05-24) — Files corrupted to same-size null bytes after Edit tool operations. Different observable (corruption to nulls vs deletion), but also Edit-tool-triggered data loss; may share a regression window.

Workaround Currently in Use

After each CC Edit on a OneDrive-synced path, immediately read-back-verify with PowerShell:

Get-Item <file> | Select-Object Name, Length, LastWriteTime, Attributes
(Get-FileHash <file>).Hash

For high-value files in OneDrive paths (especially large or long-lived), do not use CC's Edit — draft content in CC, paste manually via VS Code (whose save uses in-place writes and does not trigger this race).

Severity

P0 / Data Loss. The file is silently destroyed; CC reports success. The non-determinism makes it especially insidious — sometimes the same operation is safe, sometimes lethal. Saved only by OneDrive's cloud recycle bin (time-bounded).

The bug is harder to reproduce than the original incident framing suggested (a fresh probe could not be killed even at identical size). But the original incident reproduced 2/2 against the affected file, the mechanism is clearly captured in FSW logs, and the inconsistency of CC's write pattern is independently verifiable regardless of OneDrive's reaction.

Reporter Notes

Full diagnostic captured via PowerShell FileSystemWatcher during both the original kill and a 5-test probe experiment. Logs preserved locally. Original file size: 182,397 bytes. Probe file: incrementally grown from 8,142 to 179,616 bytes. CC's Edit write pattern observed in mixed forms (3 delete-then-rename, 2 atomic rename-over) across the 5 probe tests — suggesting the inconsistency is per-call non-determinism, not version-locked behavior.