An agent wiped 48,218 files in 103 seconds through Windows junctions
A developer's Claude Code session wrote a cleanup script, ran it, and lost a week's work plus the git history that could have restored it. The mechanism it tripped over was not new — and that is the part worth reading.
A developer says that an agent his Claude Code session launched deleted 48,218 live files in 103 seconds and wiped the git object store that could have restored them — and that the failure mode it used had already been reported twice this year before it reached him. The account is the one credible primary source, and it is now gone: the author deleted the Reddit post, so the archived copy of the thread is all that survives of the original. He was working on backtesting scripts for options data when the session went to rebuild a mirror of the project tree. The existing mirror could not refresh in place, so the agent wrote a remover for the old one and pointed it at the live directory.
The bug is one line of Python and a Windows detail almost nobody knows. The remover walked the tree with links disabled, on the reasonable assumption that this stops the walk at a junction. It does not: Python's link check returns false for an NTFS junction, so every directory sitting below one of the 614 junctions in that tree came back as an ordinary path and was deleted as one. The agent wrote a guard, but it only covered files directly inside a junction's root — one level too shallow. Its own log counted 55,550 files removed; subtract the 7,332 files that were genuine mirror copies and 48,218 live files were gone, in a deletion window the report timestamps from 10:10:31 to 10:12:14 p.m. Eastern. Then .git/objects, refs and logs came up empty. There was no remote repository. Then came the message every developer who runs agents eventually dreads reading: "Craig — stop and read this. I broke something."
Read the numbers as claims, not forensics. The 48,218 figure is the agent's own arithmetic, published alongside the incident by the person who lost the files; no outlet has independently verified it, and Anthropic has said nothing about the case. What has been verified is the mechanism — because it has its own paper trail. A PowerShell issue filed in February 2026 described a recursive delete that followed pnpm's junctions inside a project folder out into the user's home directory, taking Documents, Downloads, Music and Pictures with it, bypassing the Recycle Bin entirely and destroying two unpushed commits; the reporter named Claude Code's command-line tool as what triggered the command. Maintainers closed it in late September without a code change, after a commenter argued PowerShell was not following the junctions — the package manager's link layout was. A separate Claude Code bug report from March 2026 describes the same traverse-and-delete outcome through a different shell, at a scale that makes this month's incident look small: 165 GB, 1.59 million files and 276,382 folders gone from a business machine, closed as a duplicate.
What makes this a pattern rather than an anecdote is what the vendor has and has not fixed. Anthropic's Claude Code changelog does contain junction-safety work — a July release fixed worktree removal deleting files outside the worktree when an NTFS junction sat inside it, and another fixed background-job cleanup following junctions back into the main repository. Those patches correct Claude Code's own delete paths. They do nothing about a script the agent writes itself and runs with your filesystem permissions, which is what happened here. The gap is structural: the moment a coding agent gets shell access, it inherits your user account's rights to your whole disk, and the guardrails in the product do not reach the code it improvises.
The practical lesson is narrower than "use version control." Backups existed here — a NAS and a cloud drive — but they were nightly, and the primary target was a working tree the owner had never pushed. Treat an agent's scratch scripts as destructive-production code: no recursive delete outside a confirmed working directory, no followlinks-style shortcuts on Windows, and a remote push before any job that touches thousands of files. The alternative is being the fourth person to discover a known junction trap the hard way — the same way we have covered agents removing their own safeguards, as when DeepSeek's agent tool let the agent switch off its own sandbox: the failure is never the model deciding to be destructive. It is a permission that was never scoped.
What to watch: whether Anthropic ships a guard for agent-authored recursive deletes on Windows, or leaves it to the hooks users write themselves.
Is a coding agent with your filesystem permissions ever a safe default, or should every write-capable agent run inside a sandbox it cannot widen? Tell us in the comments.
Sources: PowerShell issue #26913 · Claude Code issue #36339
