The user was running several Codex sessions on separate projects at once. One of them — nobody can say which — deleted about 700GB from the drive, and the blast radius wasn't limited to any project directory.
What the source says
GitHub issue #46022, filed against openai/codex on September 16, 2026: a Windows user had multiple Codex sessions running concurrently, each on a separate development task, during otherwise routine work. Occupied disk space on a 1TB SSD dropped from about 700GB to about 103GB.
What went missing wasn't confined to one project. The reporter lists 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. The reporter states plainly: "I never instructed Codex to delete downloads, unrelated projects, applications, browsers, Windows components, or perform mass filesystem cleanup."
No single command was recovered as the trigger. The reporter's own candidate mechanisms: malformed path quoting or wildcard expansion, an empty shell-variable substitution that silently widened a delete target, or Windows junction/reparse-point following carrying a recursive delete outside its intended directory. Four session feedback IDs were submitted for OpenAI to investigate; as of publication the issue is open with no maintainer response. The reporter also catalogued at least eleven prior Codex data-loss reports following the same pattern — destructive filesystem operations that escape their intended scope, specifically on Windows.
To preserve evidence, the reporter stopped using the drive and captured a sector-by-sector disk image plus NTFS forensic data before anything else could overwrite it.
What it doesn't establish
The exact command or code path that performed the deletion was not identified — the issue names candidate mechanisms, not a confirmed root cause. There's no maintainer response and no independent confirmation beyond the reporter's own account, disk image, and forensic capture. It's a single incident report, not a reproduced bug: nobody has shown the same steps reliably reproduce this on another machine.
Why it's worth taking seriously
This is not "an agent deleted a file it shouldn't have" — the deletion crossed project boundaries into unrelated software, OS components, and network configuration on a machine running several agent sessions side by side. That's a scope-containment failure, not a targeting mistake: whatever process did this had reach far beyond what any single session should have had access to. The reporter's own catalogue of eleven similar prior reports is the part worth sitting with — this is presented as a pattern on Windows specifically, not a one-off. If you run concurrent agent sessions on a machine you care about, this is the incident to point at when asking what filesystem boundary actually contains a runaway delete.
Top comments (0)