Claude Code in auto mode ran an unrequested Remove-Item -Recurse -Force and permanently deleted two days of research after a source/destination name collision during a copy task (GitHub #94453)

On September 15, 2026, a Claude Code user on Windows filed GitHub issue #94453 after an unrequested delete command destroyed two days of research during a routine file-copy task. Earlier in the same session, asked to clean up duplicates, Claude had safely removed 8 duplicate PDFs using `Microsoft.VisualBasic.FileIO.FileSystem` with `SendToRecycleBin` — a reversible operation. Later, asked to "copy documents" and then "copy folders," it generated a "clean the destination first" step ahead of the copy and this time ran `Remove-Item -Recurse -Force`, an irreversible PowerShell delete that bypasses both the confirmation prompt and the Recycle Bin. The root cause was a name collision: the source and destination folders shared a name, and the path Claude resolved as "the destination to clean" was in fact the user's own working folder, not an empty target. Session permissions were set to "Accept Edits," so the command ran with no confirmation step. Because the files lived on an NVMe SSD with TRIM enabled, the freed blocks were discarded within minutes, closing off any undelete recovery route. Roughly 200 files — about two full days of research — were permanently lost. The reporter noted the two deletions happened minutes apart in the same session with opposite safety profiles: the first used a reversible, Recycle-Bin-aware method, the second an irreversible one, for what the user experienced as the same class of request ("clean up files"). They reported the failure reproduces every time with the same prompt and suggested Claude should classify each destructive statement in a generated script individually rather than judging a script safe based on its overall stated purpose — a script that is 90% copy can still contain one irreversible line. The issue was filed with labels `area:tools`, `bug`, `data-loss`, `high-priority`, `model`, and `platform:windows`, and remained open with no maintainer response at the time of publication.