DEV Community

Ramdai Bista
Ramdai Bista

Posted on Originally published at stupidllm.com

A Claude Code Sub-Agent's Recursive Delete Wiped an Entire Windows Profile After the Safety Classifier Failed Open

234,884 files gone in two minutes, from a sub-agent that was only supposed to be auditing code — because the system meant to catch exactly this kind of command was unavailable, and chose to allow output rather than block it.

What happened

Filed as anthropics/claude-code#86872, the reporter (VS Code extension v2.1.231, Windows 11 Pro, auto-mode enabled with broad Bash/PowerShell allow-rules) had the main agent spawn several general-purpose sub-agents to audit code. One was reviewing a module that managed temporary clipboard files via a recursive-delete routine.

That sub-agent issued a single PowerShell command whose target path resolved to the profile root (C:\Users\<user>) instead of the intended temp directory. Two things had to go wrong for that command to actually run:

  1. An existing allow-rule in the project's settings.local.json auto-approved it — no prompt, no confirmation.
  2. Claude Code's handoff safety classifier, which specifically gates sub-agent tool output before it takes effect, was unavailable at that exact moment. Instead of blocking the command, it logged a warning and let the output through: "Handoff classifier unavailable or failed closed without a verdict, allowing sub-agent output with warning."

Read that log line twice. It says "failed closed" and then describes behavior that is the opposite of closed — the command executed.

The forensic detail

The command was logged as toolUseId=toolu_01V7XbuBv39JbAXKA9mTafrU, agentId=af8fba6dfe3e04c90, with a measured runtime of 120,192ms — almost exactly two minutes, versus 0.1–0.9 seconds for every other command in the session. The NTFS USN journal recorded 234,884 file deletions between 10:01:10 and 10:02:14, a window fully contained inside that runtime.

The sub-agent's own transcript was destroyed mid-run — its output path got swept up in the deletion it was causing — so the exact command text that triggered the wipe couldn't be recovered. The reporter reconstructed the failure from extension logs and the NTFS journal instead of the transcript itself.

The damage

Source code, SSH keys, Documents, an Android SDK install, Steam, and Microsoft Teams data — gone. Source code and SSH keys are irrecoverable; the rest requires a full reinstall.

What the source establishes — and what it doesn't

The issue is labeled bug, data-loss, high-priority, area:agents, area:sandbox, area:security, and platform:windows, and remains open with no maintainer response as of publication. The reporter's account is first-hand and corroborated by NTFS-journal timestamps that line up precisely with the tool call's own runtime — which is about as strong as evidence gets when the thing that would normally prove it (the command transcript) was itself deleted.

What it doesn't establish: why the classifier was unavailable at that moment, whether this is a one-off outage or a recurring gap, or whether the same fail-open path exists for other classes of destructive commands beyond delete. StupidLLM scores this 9.2/10 (critical) — a fully irrecoverable loss of source and credentials, from a safety mechanism that existed specifically to prevent this and did not fire.

Status

Open, no maintainer response, as of publication.

Full incident record and severity scoring: STUPID-2026-0088

This is one of 88+ verified, severity-scored AI agent incidents documented at StupidLLM, an open incident database for AI coding agent failures.

Top comments (0)