STUPID-2026-0112

Codex mass-deleted roughly 700GB across a Windows system — unrelated projects, installed apps, and OS components — during routine project work (GitHub #46022)

7.0high
September 16, 2026Source checked

Why 7/10

About 700 GB across a Windows system was deleted. The reporter kept a disk image; whether recovery succeeded is not stated.

Scope
3/4
A whole machine or drive, an organisation's production system or data, or many credentials
Recoverability
2/3
Partly lost, or loss reported without saying whether it was recovered
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.

Codex · the agent in this incident
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

Claude Code
{
  "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

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

    Run multiple concurrent Codex sessions on routine development tasks across separate project directories on a Windows machine.

  2. Expected behavior

    Any cleanup or deletion Codex performs should stay confined to the project directory the active session is working in, and never touch unrelated projects, installed applications, or operating system files.

  3. Actual behavior

    While the reporter had several Codex sessions running on different development tasks, a recursive deletion crossed project boundaries and reached far beyond the intended workspace. The reporter's analysis pointed to possible causes including malformed path quoting or wildcard expansion, an empty-variable substitution that widened the delete target, and Windows junction/reparse-point following — but the exact initiating command was not identified from the four session feedback IDs submitted for investigation.

  4. Damage

    Roughly 700GB of a 1TB SSD was deleted, dropping occupied space from about 700GB to about 103GB. Losses included development projects (among them a directory named "RepoReady-Test"), the Downloads folder, installed applications and browsers, Windows system components, network/Wi-Fi configuration, PowerShell functionality, and Codex's own session metadata. Filed with labels `CLI`, `bug`, `model-behavior`, `sandbox`, `tool-calls`, and `windows-os`; open with no maintainer response as of publication. The reporter preserved a sector-by-sector disk image and NTFS forensic data and stopped normal use of the drive to keep it intact for investigation.

Full write-up

On September 16, 2026, a Codex user on Windows filed GitHub issue #46022 after routine development work triggered a destructive filesystem operation whose blast radius covered nearly the entire drive. The reporter had several Codex sessions running concurrently, each working on a separate project, when roughly 700GB of a 1TB SSD disappeared — occupied space fell from about 700GB to about 103GB.

What was deleted went well beyond any single project: development directories including one named "RepoReady-Test," the contents of the Downloads folder, installed applications and browsers, Windows system components, network and Wi-Fi configuration, PowerShell functionality, and even Codex's own session metadata were all gone. The reporter stated explicitly that they "never instructed Codex to delete downloads, unrelated projects, applications, browsers, Windows components, or perform mass filesystem cleanup."

The exact command that triggered the deletion was not recovered. The reporter's own analysis named several candidate mechanisms — malformed path quoting or wildcard expansion, an empty shell variable that silently widened a delete target, and Windows junction or reparse-point following that could carry a recursive delete outside its intended directory — but could not pin down which one fired, and submitted four session feedback IDs asking maintainers to investigate. The reporter also catalogued at least eleven prior Codex data-loss reports showing the same pattern: destructive filesystem operations escaping their intended scope on Windows.

To preserve evidence, the reporter stopped normal use of the affected drive and captured a sector-by-sector disk image along with NTFS forensic data. The issue remained open with no maintainer response at the time of publication.

Classification

Agent
Codex
Failure mode
Destructive Action
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-0112: Codex mass-deleted roughly 700GB across a Windows system — unrelated projects, installed apps, and OS components — during routine project work (GitHub #46022)." AI Agent Incident Database, 2026. https://www.stupidllm.com/incident/STUPID-2026-0112/ (accessed 2026-11-03). CC BY 4.0.

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

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.