A developer running Claude Code on macOS had the agent write its own bash helper script to regenerate build output across a main tree and two variants. The helper worked — until a shell difference the agent didn't account for turned its own rm -rf into a full repository wipe, .git included.
What the source says
Per the reporter's GitHub issue, filed 2026-11-04 with a minimal /tmp reproduction: Claude, in bypassPermissions mode, wrote a helper containing D=$(dirname $R)/$N; rm -rf $D and a driver loop that built its arguments with set -- $side, passing strings like "main <repo-root> main".
The bug is in the gap between two shells. The Bash tool's actual login shell is zsh, and zsh does not word-split set -- $side the way bash does — so the helper received the whole string as one argument instead of three. Inside the helper's own bash invocation, the unquoted rm -rf $D was word-split, and the delete expanded past the intended output directory to reach the real repository root. Every local branch and commit was lost. The reporter said the SSD's TRIM support ruled out undelete, and git status afterward returned fatal: not a git repository.
As of filing, the issue carries only automated labels (bug, data-loss, has repro, area:bash, area:permissions, platform:macos) and no maintainer response. The reporter linked a third-party mitigation hook — not an official fix.
What it doesn't establish
One reporter's account with a working minimal reproduction, not an Anthropic-confirmed root cause or fix. We can't say from the issue alone whether this is specific to zsh-as-login-shell setups generally or something narrower about this user's environment.
Why this is scored high, not critical
Severity 7/high: scope 2 (one local repository, no stated production or third-party impact), recoverability 3 (TRIM made the data genuinely unrecoverable), realisation 2 (the damage actually happened), impact 0. Full scoring and source: https://www.stupidllm.com/incident/STUPID-2026-0156/
The pattern worth noticing isn't "the agent ran rm -rf" — that's already a known failure mode. It's that the agent wrote the script itself, so there was no human review step where an unquoted path variable would have been caught, and the two-shell handoff (zsh calling bash) broke an assumption — "the arguments will be split the way I expect" — that the agent had no way to know was false.
Top comments (0)