A user asked Claude Code to tidy up duplicate year folders in a photo archive — merge 2013a into 2013, 2014a into 2014, 2015a into 2015, then delete the now-redundant "a" folders. Claude tallied the files first, wrote a move script, and finished with rm -rf. The move had silently failed. The delete didn't.
What the source says
GitHub issue #92737, filed September 7, 2026 by user @ycarlson. The task was cleanup of a sort/ folder on the Desktop holding duplicate year folders from a photo import. Claude counted the duplicates going in — 1,722 files in 2013a, 986 in 2014a, 261 in 2015a — and wrote a script to move them into the matching originals.
That script used export -f to export a shell function. export -f works in bash; it silently fails in zsh, which was the user's actual shell. No files moved, and nothing in the script's output distinguished that from success. A second script tried find -maxdepth 1, which skipped files sitting in subdirectories, so it still didn't fully reconcile the folders.
Claude then ran rm -rf on the "a" folders to finish the job — without re-checking that the destination counts actually matched the 1,722 / 986 / 261 it had tallied at the start. Because the move had failed, the delete destroyed the originals: roughly 2,969 photos gone, no backup.
The reporter described being extremely distressed, and separately emptied the Trash during the same session, cutting off another recovery path. The issue is labeled bug, data-loss, area:bash, and high-priority. It remains open; no Anthropic maintainer has commented. A non-maintainer reply suggested gating any future cleanup on matching find | wc -l counts, and using rsync --remove-source-files instead of a separate move-then-delete step.
What it doesn't establish
This is one first-person bug report, not an independently reproduced one — reproducible: false in our own scoring, since no one else has confirmed the exact export -f/zsh interaction on a second system. There's no maintainer explanation of why the agent treated two silently-failed move attempts as sufficient grounds to run the delete anyway, and no confirmation yet of how much, if anything, is recoverable — the reporter mentioned data-recovery software as a next step, with no guarantee stated or implied.
Why it's still worth logging
The specific shell incompatibility (export -f behaving differently in bash vs. zsh) is a known gotcha that would bite a careful human too. What isn't a shell gotcha is the decision after it: Claude had its own tally of exactly how many files should be in each destination folder, and ran the irreversible step without checking that number against reality. That check is cheap — find | wc -l against a number the agent already had in hand — and its absence is the entire gap between "two scripts had bugs" and "2,969 irreplaceable photos are gone."
Full record, severity scoring, and frontmatter: https://www.stupidllm.com/incident/STUPID-2026-0145/
Top comments (0)