A Claude Code user on Windows asked the agent to remove two git worktrees from a pnpm monorepo. The agent ran a recursive delete on the worktree paths. The delete didn't stop at the worktree — it followed an NTFS junction out of it and tore through the user's Documents, Downloads, Pictures, Music, Videos and Favorites folders, permanently, with no Recycle Bin to recover from.
What the source says
GitHub issue #29249, filed February 27, 2026 and closed as not planned with no fix shipped. The instruction was ordinary: delete variant-a and variant-b, two git worktrees in a pnpm monorepo. Claude Code executed Remove-Item -Recurse -Force in PowerShell (and, via its MSYS-based Bash tool, rm -rf) directly against the worktree paths.
The mechanism is specific and verifiable. pnpm links a workspace's node_modules using NTFS junctions, not symlinks, to share packages across a monorepo. Windows PowerShell 5.1 — the build Claude Code's tooling shells out to — and MSYS's rm both follow a junction into its real target instead of deleting the link itself. That bug is already fixed in PowerShell Core 6+ (tracked upstream as PowerShell/PowerShell#621) but was never backported to the Windows PowerShell 5.1 that ships with the OS. So a recursive delete aimed at a worktree directory recursed straight through the junction and into whatever it pointed at.
What it pointed at, in this case, was the user's home folders. Documents, Downloads, Music, Pictures, Videos, and Favorites were all deleted outright — both Remove-Item -Force and rm -rf bypass the Recycle Bin, so there was no undo. Two other projects on the same machine, WAOK-MONOREPO and WAOK-LEGACY, were also partially wiped. WAOK-MONOREPO could be restored by re-cloning from the remote, but two unpushed commits and all uncommitted working-tree changes could not be — that history simply doesn't exist anywhere else.
The reporter confirmed the exact same prompt and environment reproduce the deletion every time, and listed the safe alternatives that would not have escaped the worktree: cmd.exe /c "rmdir /S /Q <path>", git worktree remove, or simply asking for confirmation before a recursive delete on Windows. The issue carries the bug, data-loss, and has-repro labels. It was closed as not planned.
What it doesn't establish
This is one filed, confirmed-reproducible report, not a claim that every Windows user running Claude Code against a pnpm monorepo will hit this. The failure needs a specific combination: pnpm's junction-based linking, a worktree inside (or adjacent to) a linked workspace, and a shell whose recursive-delete command follows junctions — PowerShell 5.1 or MSYS rm, not PowerShell Core 6+. It is not evidence of a vulnerability in Claude Code's model behavior; the agent did exactly what it was asked (remove the worktrees) using a command whose platform-level semantics it didn't account for.
Why it's still worth logging
This incident scores 8.5/high in our severity model, among the higher scores in the corpus, for a straightforward reason: the damage was permanent, outside the scope of the instruction, and the fix was known and available before the agent ever ran the command. git worktree remove exists precisely to delete a worktree safely; the agent reached for a general-purpose recursive delete instead, on a platform where that command's blast radius is wider than its surface syntax suggests. An issue closed "not planned" with a confirmed repro and no mitigation means this exact prompt, on this exact setup, still does this today.
Full incident record, including frontmatter fields and severity scoring: https://www.stupidllm.com/incident/STUPID-2026-0123/
Top comments (0)