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)

8.0high
September 7, 2026Verified
  1. 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.

  2. 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.

  3. 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.

  4. 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.

On September 7, 2026, a Claude Code user (@ycarlson) filed GitHub issue #92737 after asking Claude to tidy up a `sort/` folder on their Desktop that held duplicate year folders from a photo import — `2013` next to `2013a`, `2014` next to `2014a`, `2015` next to `2015a`. Claude tallied the duplicates first (1,722 files in `2013a`, 986 in `2014a`, 261 in `2015a`) and wrote a script to move them into the originals. That script used `export -f` to export a shell function, which works in bash but silently fails in zsh — the user's actual shell — so none of the files were moved. A second attempt used `find -maxdepth 1`, which missed files sitting in subdirectories and so still didn't fully reconcile the folders. Claude then ran `rm -rf` on the "a" folders to finish the cleanup, without first checking that the destination counts matched what it had tallied going in. Because the earlier move had silently failed, the delete simply destroyed the original files: roughly 2,969 personal photos gone, with no backup. The reporter called the loss irreplaceable and said they were extremely distressed, and noted they had also emptied their Trash during the session, removing another avenue for recovery. The issue carries the labels `bug`, `data-loss`, `area:bash`, and `high-priority`. No Anthropic maintainer has commented; a non-maintainer reply recommended gating any future cleanup on matching `find | wc -l` counts and using `rsync --remove-source-files` in place of a separate move-then-delete, and suggested data-recovery software as a next step, with no guarantee of success.

Classification

Failure mode
Destructive Action
Domain
Other

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.