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 user on X last week. They wanted to use up their Codex credits before a reset, so they asked the 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, 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 before the command reached the operating system.
So instead of find "/tmp/tmp.XXXXXX" -depth -delete, the system ran 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 started traversing from the WSL root.
Here’s the detail I keep coming back to. The script had set -e, which stops on error, but not set -u, which stops on an undefined variable. One extra flag and the empty $d would have aborted everything before find ever ran. That’s a one-character difference between a cleanup and a catastrophe.
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.
They said something like: if they hadn’t had cloud backups, they’d probably be turning themselves in. That’s not an exaggeration.
And notice what the original task even was. “Verify my project scripts and documentation.” That sounds read-only. Nothing about it suggests deletion. But the agent needed a tool to do the verification, wrote a command to install that tool, and the cleanup step at the end of that command is what did the damage. Harmless-sounding tasks can have destructive sub-steps, and you never see them coming from a prompt that says “verify the docs.”
Full access made it worse
This is the key takeaway. Codex and similar tools — Claude Code, Cursor, and the rest — all have safety mechanisms built in. There’s an approval mode where commands go through a review pass first, and if something looks dangerous it gets blocked automatically.
Full access bypasses all of it.
With full access enabled, the agent doesn’t ask. It doesn’t pause for review. It just executes. Most of the time that saves you a lot of clicking. In an edge case like this one — where a quoting bug turns a harmless cleanup into a system-wide deletion — it’s catastrophic.
OpenAI’s own 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 taken from this.
Don’t give full access. Use the default workspace-write mode with approval prompts on. 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. Git pushes to a remote count. Cloud sync counts. Just have something that isn’t sitting on the same machine.
Be careful with cleanup commands. This incident was triggered by find -delete inside WSL. Commands like that are dangerous when a human types them. When an agent runs them with full access, the risk multiplies — because a human would have noticed that $d was empty.
Use an isolated environment for risky work. If you really need to hand an agent broad permissions, do it in a VM or a container. Not on the machine with your tax returns on it.
Add belts you’ll never notice. If you write shell scripts by hand, use set -euo pipefail. It’s the difference between “the variable is empty, stop” and “the variable is empty, delete the filesystem.”
The bigger picture
AI coding agents are genuinely useful. They automate things that used to take hours. But they can also do real damage — not because they’re malicious, but because they’re tools that follow instructions, sometimes with unexpected results.
The user who lost 300GB didn’t do anything obviously reckless. They 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 obvious in advance. The command looked fine. The intention was harmless. Then one missing pair of quotes, plus full access, and millions of files are gone.
I’ve started treating full access the way I treat rm -rf / — something I never type, never enable, and never assume is safe.
If you’re still deciding how much rope to give one of these agents, the mode matters more than the brand. I went through the AI coding tools I actually tested and the one I kept, and the honest answer is that none of them are safe by default. The mode you run them in is the safety feature.
