AI coding agent deletes developer’s 700 GB home directory while testing deletion safeguards
Developers now have a working playbook for testing destructive scripts safely with AI agents, after a recent incident in which an agent deleted 700 GB of a user’s home directory while writing the very code meant to prevent that kind of deletion.
The damage occurred during an adversarial safety review, and an automatic model downgrade within the system probably worsened the incorrect call.
What the developer was actually trying to build
The setup started as a routine hygiene problem. AI coding agents were leaving behind large amounts of temporary data in /tmp, and the developer wanted each agent sandboxed into its own folder with automatic cleanup once it finished. The script itself had to do one hard thing well: never delete files that were still in use.
An initial suggestion added logic to detect running agents and postpone cleanup until they exited. The developer told the agent the code was too complicated. From there, the agent took a more aggressive path: it wrote a script that hard-deletes data, then ran an adversarial review, meaning a fresh copy of the agent tested its own output for safety problems before it ran.
How the safety harness turned a bad script into a data loss event
The safety test itself worked as intended. It identified that the deletion targets, /tmp and the user’s home directory, were both dangerous to remove.
The bug was in the cleanup that followed the test. The same variable name was reused for the targets during testing and for the cleanup that deletes test artefacts. Because the variable still pointed at the home directory when cleanup ran, the agent deleted the home directory along with the temporary test data. The developer stopped the process, but not before the bulk of the damage was done.
Two factors converged in the failure. First, reusing a variable across test and cleanup created the contradiction. Second, the automatic downgrade to a less capable coding model likely reduced the chance of catching that contradiction. The stronger model that wrote the script performs better at coding tasks than the model that reviewed it.
What was lost and what was recovered
The deleted data included the user’s entire data folder and roughly one week’s worth of work. The developer recovered most of the files by pulling data from git, nix, session logs, and other tooling that kept their own copies. There was no daily backup of the rest.
The /tmp folder the original cleanup script was meant to tidy was left untouched. After wiping the home directory, the agent did not actually finish its job.
What this means for anyone running AI agents on a workstation
Two practices would have limited the blast radius here. A simple variable rename between the test pass and the cleanup pass would have removed the contradiction the model failed to spot. And a daily backup would have turned a worst case into a minor inconvenience.
For developers letting agents run destructive commands, the broader lesson is that adversarial review is only as strong as the model doing the reviewing. A system that swaps in a weaker model for safety reasons during a destructive task can quietly remove the layer of reasoning that would have caught the bug. That tradeoff deserves to be visible to the user before the downgrade happens, not after the deletion command has already fired.
Workstation-level safeguards matter too. Sandboxing agents under their own filesystem root, or running them inside a container with a disposable home directory, would have kept the damage inside a folder that could be rebuilt with one command. None of that was in place here.
FAQ
What happened with Claude and the developer’s home directory?
A developer asked Claude to write a script that safely cleans up after AI agents in /tmp. The agent’s safety system downgraded the model during an adversarial review, and a variable name collision between the test phase and the cleanup phase caused the script to delete the user’s 700 GB home directory.
Why did the model get downgraded mid-task?
The system rated the deletion script risky enough to switch from a stronger model to Opus 4.8 before the safety test ran. The downgrade was automatic and was meant to make the review more cautious, but the replacement model is weaker at coding tasks, which likely reduced its ability to spot the variable reuse bug.
Was the data recoverable?
Most of it was. The developer rebuilt the lost work from git, nix, and session logs, which kept their own copies of the relevant data. There was no separate daily backup for the rest of the deleted files.