One badly quoted rmdir: Codex cleans up a temp folder and wipes most of a 2 TB drive

This is one person's account in a bug report on GitHub, not independently confirmed.

What happened

On 21 October a developer was using the Codex extension for VS Code on Windows 11 for a routine job: pulling a document-processing service out into its own project. Near the end, Codex wanted to remove a temporary runtime folder called .spike. Tidy-up work. The kind of step nobody reads twice.

How it went wrong

According to the session logs the developer quotes, Codex first tried PowerShell's Remove-Item, and that failed. Instead of stopping to ask, it switched tools and ran cmd.exe with rmdir /s /q, the Windows recursive delete that doesn't ask for confirmation. The quotation marks around the target path were escaped wrongly. So rather than hitting one folder, the command reached unrelated directories across the D: drive. The logs show errors from places like the Docker data folder and the recycle bin, which is not where a project's temp folder lives.

The developer says the command ran on an elevated path, with the sandbox setting marked as requiring escalation. Codex later acknowledged the quoting mistake.

The damage

Nearly all accessible contents of the drive went, the developer says: unrelated software projects, development environments, configuration and databases on a 2 TB SSD. They do have a recent independent backup and say recovery is possible, but warn that without it this would have been months of lost work.

They haven't tried to reproduce it, sensibly, because doing so could destroy more data. They've kept the original session logs and a redacted evidence file for the maintainers, and they say they also tried OpenAI's security disclosure channel, but its login failed.

What they're asking for

The developer wants hard rules rather than trust in model-written commands: check and normalise a path before any recursive delete, stop bad quoting from widening what gets deleted, enforce folder boundaries no matter what the command says, require explicit approval for destructive actions outside the workspace, and abort when the real target can't be verified. At the time of writing the issue is open, with no fix announced.

Our take

This is our opinion, not the developer's. The scary part isn't the typo. It's the fallback. When a safe delete fails, an agent reaching for a blunter, no-confirmation tool is exactly the moment a human should be asked. Shell quoting across PowerShell and cmd.exe is a known minefield, and an elevated recursive delete built from a model-written string is about as risky as a one-liner gets. Keep agents on drives that only hold the project, take snapshots, and never let "the first delete didn't work" become "try a stronger one".