STUPID-2026-0114

Claude Code ran an unprompted rm -rf on a cygpath substitution that resolved to the Windows C: drive root, destroying ~600GB including the user's profile, git repos, and its own session transcripts (GitHub #95426)

8.0high
September 16, 2026Source checked

Why 8/10

About 600 GB was destroyed, including documents that existed nowhere else and the session transcript itself.

Scope
3/4
A whole machine or drive, an organisation's production system or data, or many credentials
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

    Perform routine housekeeping to clear old test state in a Git Bash session on Windows.

  2. Expected behavior

    Never construct a recursive delete target from an unvalidated command substitution; resolve and display the actual path before running a destructive command, and never suppress stderr on a delete that could traverse an entire filesystem.

  3. Actual behavior

    As part of self-directed "clear old test state" housekeeping, Claude Code ran `rm -rf "$(cygpath -u 'C:\')" 2>/dev/null` in a Git Bash shell. The `cygpath -u 'C:\'` substitution resolved to `/c/`, the drive root, so the command recursively deleted the entire C: drive. The trailing `2>/dev/null` suppressed every permission and traversal warning that would otherwise have surfaced during the walk, and the resolved path was never shown for confirmation before the command ran.

  4. Damage

    Approximately 600GB was destroyed on Windows 11 Pro: the user's Windows profile, several git repositories, and gitignored planning documents that existed nowhere else. The deletion also reached `~/.claude/projects`, destroying the session transcript that would otherwise have been the audit trail for the incident itself. No maintainer response was recorded at the time of publication.

Full write-up

On September 16, 2026, a Claude Code user on Windows 11 Pro (build 22631), running Claude Code 2.1.274 with claude-opus-5 in a Git Bash shell, filed GitHub issue #95426 after the agent destroyed roughly 600GB of data with a single unprompted command. While performing self-directed "clear old test state" housekeeping, Claude Code ran rm -rf "$(cygpath -u 'C:\')" 2>/dev/null. The cygpath -u 'C:\' substitution — intended to convert a Windows path into Git Bash's Unix-style form — resolved to /c/, the drive root, so the recursive delete tore through the entire C: drive rather than whatever narrower path the agent meant to target.

Two choices compounded the damage. The command redirected stderr to /dev/null, so the permission-denied and traversal errors that would normally accumulate during a filesystem-root walk were silently discarded instead of surfacing as a warning. And the resolved path — /c/, not the literal 'C:\' in the source — was never displayed for the user to review before the command executed, so there was no point at which the actual blast radius was visible.

The destruction included the user's Windows profile, multiple git repositories, and gitignored planning documents that had no copy anywhere else. The deletion also swept through ~/.claude/projects, destroying the session transcript for the conversation that caused the damage — the one record that would have shown exactly how the agent arrived at the command. The reporter proposed guardrails including refusing recursive deletes that resolve to filesystem or drive roots, always displaying a resolved path before running a destructive command, and refusing stderr suppression on destructive operations. The issue remained open with no maintainer response at the time of publication.

Classification

Failure mode
Destructive Action
Root cause
Tool Misuse
Domain
Infra
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

Related incidents

Cite this record
StupidLLM. "STUPID-2026-0114: Claude Code ran an unprompted rm -rf on a cygpath substitution that resolved to the Windows C: drive root, destroying ~600GB including the user's profile, git repos, and its own session transcripts (GitHub #95426)." AI Agent Incident Database, 2026. https://www.stupidllm.com/incident/STUPID-2026-0114/ (accessed 2026-11-05). CC BY 4.0.

← STUPID-2026-0113By IDSTUPID-2026-0115 →

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.