STUPID-2026-0145
Claude Code ran rm -rf on duplicate photo folders before verifying an earlier move had actually worked, destroying ~2,969 irreplaceable personal photos (GitHub #92737)
Instruction given
Organize photos in a `sort/` folder on the user's Desktop, which contained duplicate year folders — `2013` alongside `2013a`, `2014` alongside `2014a`, `2015` alongside `2015a` — by merging the "a" duplicates into the originals and removing the now-redundant "a" folders.
Expected behavior
After moving files out of a folder, verify that the destination file count matches the source count before deleting the source. If the counts don't match, stop and investigate rather than deleting. Never run `rm -rf` on user data without that verification, and prefer staging the files or keeping a backup over an immediate destructive delete.
Actual behavior
Claude wrote a move script that used `export -f` to export a shell function — a construct that works in bash but silently fails in zsh, the user's actual shell, so the intended file moves never happened. A second script it tried had its own bug: `find -maxdepth 1` missed files sitting in subdirectories. Without checking that the destination counts (1,722 files for `2013a`, 986 for `2014a`, 261 for `2015a`, by Claude's own earlier tally) actually matched what had landed in the merged folders, Claude ran `rm -rf` on the "a" folders.
Damage
Approximately 2,969 irreplaceable personal photos were permanently deleted, since the move that was supposed to precede the delete had silently failed. The reporter described being extremely distressed, and separately emptied the Trash during the same session, compounding the loss. The files may be partially recoverable with data-recovery software, but that isn't guaranteed. The issue is labeled `bug`, `data-loss`, `area:bash`, and `high-priority`, and remains open with no maintainer fix at the time of writing; a non-maintainer commenter suggested count-gated cleanup and `rsync --remove-source-files` instead of move-then-delete.
Classification
- Agent
- Claude Code
- Failure mode
- Destructive Action
- Root cause
- Confidence Miscalibration
- Domain
- Other
- Source
- Github Issue
Related incidents
Get told when an agent breaks something
We document AI agent failures daily, severity-scored against a published scale. When one lands at 7.0 or above — deleted data, leaked secrets, broken production — you get an email with the source. When nothing does, you get nothing.
This database is callable over MCP — query it from inside your agent.