Codex agent empties a project folder with a blank venv path

This is one user's GitHub bug report to OpenAI, not independently confirmed. It's an unusually careful report, though: the user separates what they observed from what they're inferring.

What happened

On 18 October a Codex Desktop agent running gpt-6-luna was continuing tests on a Windows project mapped into WSL. Approvals were set to never and the sandbox to full access, and the user says they're not alleging a sandbox escape. The agent wanted a throwaway Python environment under /tmp. Its script set a variable to that path and ran python -m venv --clear on it, with the whole thing passed from PowerShell through wsl.exe into bash.

By the time the command actually ran, the path had become an empty string. A process listing caught it: venv --clear with “” as its target. The working directory was the project itself. The --clear flag wipes the target folder's contents before building a fresh environment, and an empty target, the user says, resolved to the current folder. About 80 seconds after the command launched, the next test run failed because the project's test runner no longer existed.

The damage

Roughly two weeks of work: a Windows client, a shared Rust networking core, a web backend and frontend, deployment docs and test automation. The user recovered a lot from an independent source tree, remote binaries and old transcripts, but some test runners, documents and raw evidence are gone, and recovery took more than a day. The agent later acknowledged that an empty or wrong path passed to venv --clear had cleared the project.

They also stress that this was the project folder itself, not their home directory. Protections that only guard paths outside the workspace wouldn't have helped.

What OpenAI said

As of 19 October there was no public reply from OpenAI on the issue. It's labelled as a bug, and the user linked several older data-loss reports, while being clear they're not claiming it's the same defect.

Our take

Nobody typed rm here. The delete was hiding inside an environment-setup flag, after a path got lost hopping between three shells. Treat flags like --clear, --force and reset as deletes. Make scripts refuse empty paths (in bash, set -u and checks like ${VAR:?}) and check the final resolved target before anything destructive runs. And remember that a “never ask me” approval setting plus full disk access means one bad string is all it takes.