A Claude Code sub-agent's temp-dir cleanup chained `find $T -type f -delete` after a failed command that skipped only the `T=$(mktemp -d ...)` assignment, leaving `$T` unset and collapsing the find to the repo root, deleting ~5,200 files and the project's git history (GitHub #102901)

On October 17, 2026, a Claude Code user on Arch Linux filed GitHub issue #102901 after a background cleanup step destroyed an entire git repository. Running Claude Code 2.1.300 with claude-opus-5-5 in bypass-permissions mode with the bash sandbox on, the model had just finished a `cd /home/vtf/projects/homelab-ops && git add ... && git commit ...` chain, which left the persistent shell's working directory at that repo's root. The next turn, still reasoning as though it were in a subdirectory several levels down, built a one-line test-and-cleanup command for a Lua mod: compile a script, run a test harness into a fresh temp directory, then wipe that temp directory — `find $T -type f -delete` — once done. The compile step failed, because the script it was looking for didn't exist at the drifted working directory. That failure sat on the near side of an `&&`, which meant only the following `T=$(mktemp -d $TMPDIR/pmh.XXXX)` assignment was skipped; everything after the next semicolon ran anyway, including the cleanup line, with `$T` never set. Unquoted, an empty `$T` makes `find $T -type f -delete` equivalent to `find -type f -delete` with no path argument at all — which `find` defaults to the current directory. That directory was the repository root, so the command walked and deleted every file it found: roughly 5,200 working files, plus the `.git` directory's objects and refs. Only the handful of paths the sandbox mounted read-only survived. The user recovered everything, but not because of anything Claude Code did right: a Syncthing mirror to a home NAS hadn't yet picked up the deletion, and the last commit had already been pushed to a remote. The reporter's bug report is explicit about why this isn't a one-off typo: the same unguarded-variable pattern would run unconstrained under their NOPASSWD sudo, or inside the unsandboxed `ssh host '...'` commands Claude Code also issues — and the product's own "dangerous rm" approval gate never triggered, because the command is `find ... -delete`, not `rm`, and its target string was only empty at runtime rather than visibly dangerous in the command text itself. The reporter asked for a built-in check, independent of permission mode, that blocks deletion commands whose target is an unguarded expansion, an implicit or relative cwd, or a git checkout root — under sudo and inside `ssh`/`bash -c` strings as well as bare shell. The issue was labeled `data-loss` and `high-priority` by automation on filing and remains open with no maintainer response or fix.