STUPID-2026-0111

Claude Code in auto mode ran an unrequested Remove-Item -Recurse -Force and permanently deleted two days of research after a source/destination name collision during a copy task (GitHub #94453)

7.0high
September 15, 2026Source checkedRepro reported

Why 7/10

About 200 files, two days of research, were permanently deleted; TRIM ruled out undelete.

Scope
2/4
One project, repository, server or service, or a cost above roughly $10,000
Recoverability
3/3
Permanently lost or irreversible, including data that was exposed
Did it happen
2/2
Happened in real use
Beyond the user
0/1
Only the user's own non-production work

The score is the sum of these four factors. How each factor is scored · scored 2026-10-29

Guardrail rules for this command

Recursive deletes: make your agent stop and ask before running these. Free to copy; written in each tool’s documented format.

Claude Code · the agent in this incident
{
  "permissions": {
    "ask": [
      "Bash(rm -r*)",
      "Bash(rm -fr*)",
      "Bash(rm -R*)",
      "Bash(find * -delete*)",
      "PowerShell(Remove-Item *)",
      "Bash(cmd /c rmdir *)",
      "Bash(cmd /c del *)"
    ]
  }
}
Add to .claude/settings.json in the project (or ~/.claude/settings.json for every project). Each matching command then asks you first, including in auto mode.

Stronger control: Turn on the sandbox (/sandbox): shell commands can then write only to the project, a temp folder and directories you add. It runs on macOS, Linux and WSL2; on native Windows Claude Code runs commands unsandboxed. Docs

Codex
prefix_rule(pattern = ["rm", ["-r", "-rf", "-fr", "-R"]], decision = "prompt", justification = "Recursive delete: confirm the target first")
Save as ~/.codex/rules/stupidllm.rules and restart Codex. Codex's docs describe rules as controlling commands run outside its sandbox, and mark them experimental.

Stronger control: Keep Codex's OS sandbox on (it limits writes, typically to the workspace) and leave approvals on for sessions that can reach data you cannot lose. Docs

Gemini CLI
[[rule]]
toolName = "run_shell_command"
commandPrefix = ["rm -r", "rm -fr", "rm -R"]
decision = "ask_user"
priority = 100
denyMessage = "Destructive command: needs a human to confirm (stupidllm.com)"
Save as ~/.gemini/policies/stupidllm.toml. Workspace-level policy files are disabled in Gemini CLI, so this must be the user-level folder.

Stronger control: Policies in ~/.gemini/policies apply in every approval mode unless a rule's modes field narrows them. Docs

Copilot CLI
copilot --deny-tool='shell(rm)'
Pass on the command line. Copilot CLI matches the program name (and git/gh subcommands), so this blocks the whole command, not just its dangerous form.

Stronger control: Avoid --allow-all-tools on a machine with data you cannot lose; --deny-tool takes precedence over it. Docs

What these cannot do: a pattern rule matches the command text the agent writes. In Anthropic’s words it “isn’t a security boundary around the program”: /bin/rm, sh -c or a script that runs the same thing gets past it (STUPID-2026-0124 got past a guard with cmd /c). Use the sandbox as well, and keep backups of what you cannot lose.

  1. Instruction given

    Copy documents, and later copy folders, on Windows with permission mode set to "Accept Edits" (auto-accepting changes without confirmation prompts).

  2. Expected behavior

    Before wiping a directory as a "clean the destination first" step in an idempotent copy operation, Claude Code should verify the path it is about to recursively delete is actually the intended destination and not a same-named folder that holds the user's own working files, and it should apply the same non-destructive deletion method (send-to-recycle-bin) it had already used earlier in the same session rather than switching to an irreversible one.

  3. Actual behavior

    Earlier in the session, Claude safely removed 8 duplicate PDFs using `Microsoft.VisualBasic.FileIO.FileSystem` with `SendToRecycleBin`, a reversible delete. Later, asked to copy folders, it generated a "clean the destination first" step and executed `Remove-Item -Recurse -Force` — a name collision between the source and destination folder names meant the path it deleted was actually the user's own working folder, not an empty destination. The `-Force` flag bypassed the confirmation prompt and the Recycle Bin. The user reports the failure reproduces every time with the same prompt.

  4. Damage

    Approximately 200 files — two full days of research — were permanently deleted. Because `Remove-Item -Recurse -Force` bypasses the Recycle Bin and the files lived on an NVMe SSD with TRIM enabled, the underlying blocks were discarded within minutes, ruling out any undelete recovery. Filed with labels `area:tools`, `bug`, `data-loss`, `high-priority`, `model`, and `platform:windows`; open with no maintainer response as of publication.

Full write-up

On September 15, 2026, a Claude Code user on Windows filed GitHub issue #94453 after an unrequested delete command destroyed two days of research during a routine file-copy task. Earlier in the same session, asked to clean up duplicates, Claude had safely removed 8 duplicate PDFs using Microsoft.VisualBasic.FileIO.FileSystem with SendToRecycleBin — a reversible operation. Later, asked to "copy documents" and then "copy folders," it generated a "clean the destination first" step ahead of the copy and this time ran Remove-Item -Recurse -Force, an irreversible PowerShell delete that bypasses both the confirmation prompt and the Recycle Bin.

The root cause was a name collision: the source and destination folders shared a name, and the path Claude resolved as "the destination to clean" was in fact the user's own working folder, not an empty target. Session permissions were set to "Accept Edits," so the command ran with no confirmation step. Because the files lived on an NVMe SSD with TRIM enabled, the freed blocks were discarded within minutes, closing off any undelete recovery route. Roughly 200 files — about two full days of research — were permanently lost.

The reporter noted the two deletions happened minutes apart in the same session with opposite safety profiles: the first used a reversible, Recycle-Bin-aware method, the second an irreversible one, for what the user experienced as the same class of request ("clean up files"). They reported the failure reproduces every time with the same prompt and suggested Claude should classify each destructive statement in a generated script individually rather than judging a script safe based on its overall stated purpose — a script that is 90% copy can still contain one irreversible line. The issue was filed with labels area:tools, bug, data-loss, high-priority, model, and platform:windows, and remained open with no maintainer response at the time of publication.

Classification

Agent
Claude Code
Failure mode
Destructive Action
Root cause
Scope Misunderstanding
Domain
Other
OWASP Agentic Top 10 (our mapping)
ASI02 Tool Misuse and Exploitation list
MIT AI Risk Repository (our mapping)
7.3 Lack of capability or robustness taxonomy
Source
Github Issue

Related incidents

8.0
Claude Code's rm -rf/Remove-Item followed an NTFS junction out of a pnpm worktree and wiped a user's Documents, Downloads, Pictures and two unpushed commits (GitHub #29249)
7.0
Claude Code permanently destroyed a local admin password with no recovery path, despite a standing "no data may be lost" rule (GitHub #94548)
7.0
Claude Code asked to "clean up scaffolding" deleted 2,229 untracked source files from a year-long OS project (GitHub #23913)
6.0
Claude Code's own `git worktree remove --force` followed NTFS junctions and destroyed their targets on an emergency disk reclaim, while shell-level Remove-Item, rm -rf and shutil.rmtree all left the same junctions untouched (GitHub #84162)
Discuss on Hacker News
Cite this record
StupidLLM. "STUPID-2026-0111: Claude Code in auto mode ran an unrequested Remove-Item -Recurse -Force and permanently deleted two days of research after a source/destination name collision during a copy task (GitHub #94453)." AI Agent Incident Database, 2026. https://www.stupidllm.com/incident/STUPID-2026-0111/ (accessed 2026-11-02). CC BY 4.0.

← STUPID-2026-0110By IDSTUPID-2026-0112 →

Get told when an agent breaks something

We document AI agent failures daily, severity-scored against a published scale. Each Monday, if any scored 7 or above that week — deleted data, leaked secrets, broken production — you get one email with the sources. When nothing did, you get nothing.

This database is callable over MCP — query it from inside your agent.