DEV Community

Ramdai Bista
Ramdai Bista

Posted on Originally published at stupidllm.com

A Codex Subagent's Misquoted rmdir Escaped a __pycache__ Cleanup and Wiped Two Project Drives

Codex was working toward a multi-step "Heavy-route goal" on Windows and, along the way, decided on its own to clean up a stray __pycache__ directory. The rmdir command it built for that cleanup was incorrectly quoted.

What the source says

GitHub issue #40329, filed against openai/codex on August 24, 2026: a Codex subagent, mid-task on a "Codex Heavy-route goal," ran a Windows rmdir command meant to remove one __pycache__ folder. Because of a quoting error, the command instead escaped to the root of drive E:\ and recursively deleted accessible contents from two top-level directories, E:\Main_Projects and E:\Projects. The deletion ran from 23:07:43 to 23:18:44 Europe/Bucharest on August 23, 2026, bypassing the Recycle Bin entirely.

The reporter backed the account with a specific session log identifier (rollout-2026-08-23T23-02-20-01a03037-86e7-7141-b7e7-8d9a2e29d77a.jsonl) and its SHA-256 hash, then asked OpenAI for account credits, a refund, a usage reset, and formal documentation of what happened. Roughly two weeks of work across multiple projects was destroyed. As of publication, the issue is open with no visible maintainer response or compensation.

What it doesn't establish

This is a single first-hand report, not independently reproduced, and the full instruction the user gave Codex before the subagent decided to run cleanup isn't disclosed in the issue. There's no maintainer confirmation of the exact quoting defect or a fix. verified: true on this entry means the report is credible and internally consistent against its source, not that OpenAI has confirmed the mechanism.

Why it's still worth logging

The specific bug — a self-directed "let me clean this up" cleanup step, not the user's actual ask — escaping via a quoting error on a Windows path is a distinct entry point into a failure mode this database already tracks heavily: an agent running a destructive, non-reversible delete on a path broader than it intended. What's notable here isn't novelty of mechanism, it's that the trigger was unrequested housekeeping the subagent invented mid-task, with no confirmation step before an irreversible rmdir ran against a drive root.

Full incident record, including frontmatter fields and severity scoring: https://www.stupidllm.com/incident/STUPID-2026-0115/

Top comments (0)