I gave Codex full access to my machine for one afternoon. It deleted about 300GB of files from my C and D drives.
This happened to a X user last week. They wanted to use up their Codex credits before a reset, so they asked the AI agent to remotely verify their project scripts and documentation. To avoid approval prompts interrupting the process, they enabled full access.
When they came back, the files were gone. The agent had deleted an estimated 200–300GB of data—millions of project files. They had cloud backups, so they didn’t lose everything permanently. But they came close.
Here’s what actually happened.
The Command That Went Wrong
The original command was supposed to do something simple: create a temporary directory, download an sshpass binary, copy it to a specific location, and then delete the temporary directory.
Here’s the command:
wsl.exe bash -lc 'set -e; d=$(mktemp -d); cd "$d"; apt-get download sshpass >/dev/null; dpkg-deb -x sshpass_*.deb extracted; cp extracted/usr/bin/sshpass /tmp/xxx-semantic-bin/sshpass; chmod 700 /tmp/xxx-semantic-bin/sshpass; cd /; find "$d" -depth -delete; /tmp/xxx-semantic-bin/sshpass -V'The problem was at the very end: find "$d" -depth -delete.
When Codex on Windows invokes wsl.exe through PowerShell, parameter passing and quote handling frequently break. In this case, the quotes around the variable "$d" were lost when the command was actually passed to the operating system.
So instead of find "/tmp/tmp.XXXXXX" -depth -delete, the system executed find /tmp/tmp.XXXXXX -depth -delete—wait, no. Even worse: the variable $d was empty. So it executed find "" -depth -delete, which in WSL means “start from the root”.
And since the command had already run cd / earlier, the find command started traversing from the WSL root.
Why It Spread to Windows Drives
WSL mounts Windows drives under /mnt/c, /mnt/d, and so on. The find command didn’t use -xdev or -xmount to restrict traversal to a single filesystem. So it kept going—into the C drive mount, then the D drive mount.
The agent deleted everything it could reach. The user estimated millions of files gone in a single command.
The user said something along the lines of: if they didn’t have cloud backups, they’d probably be turning themselves in. That’s not an exaggeration.
Full Access Made It Worse
This is the key takeaway. Codex and similar tools (Claude Code, Cursor, etc.) all have safety mechanisms built in. There’s an approval mode where commands go through a review model first. If a command looks dangerous, it gets blocked automatically.
Full access bypasses all of that.
With full access enabled, the agent doesn’t ask for permission. It doesn’t pause for review. It just executes. In normal situations, that speeds things up. In edge cases like this one—where a quoting bug turns a harmless cleanup command into a system-wide deletion—it’s catastrophic.
OpenAI’s official documentation advises against running Codex without sandboxing. The “danger-full-access” mode is only recommended in isolated environments like containers or VMs.
What You Should Do
I’m not saying don’t use Codex. I use it myself. But here’s what I’ve learned from this incident:
Don’t give full access. Use the default workspace-write mode with approval prompts enabled. The agent can still work on your project files. It’ll just ask before touching anything outside the project or making network requests.
Back up your data. The user in this story had cloud backups. That’s the only reason they didn’t lose everything. If you’re working on important projects, make sure you have off-machine backups. Git pushes to remote repositories count. Cloud sync counts. Just have something.
Be careful with cleanup commands. This specific incident was triggered by a find -delete command inside WSL. Those commands are dangerous even when you run them yourself. When an AI agent runs them with full access? The risk multiplies.
Use isolated environments for risky operations. If you absolutely need to give an agent broad permissions, do it inside a VM or a container. Not on your main machine.
The Bigger Picture
AI coding agents are incredibly useful. They can automate tasks that would take hours. But they’re also capable of doing real damage—not because they’re malicious, but because they’re tools that follow instructions, sometimes with unexpected results.
The user who lost 300GB of files didn’t do anything obviously reckless. They just wanted to use their credits before a reset. They enabled full access to avoid approval delays. And a quoting bug in PowerShell’s parameter handling turned a routine cleanup into a disaster.
That’s the thing about these tools: the failure modes aren’t always obvious. The command looked fine. The intention was harmless. But one missing pair of quotes, combined with full access, and suddenly millions of files are gone.
I’ve started treating full access the same way I treat rm -rf /—something I never type, never enable, and never assume is safe.
