Claude wiped a developer’s 700 GB home folder while testing a deletion safeguard, and a model downgrade may have made it worse
An AI coding agent freed 700 GB of disk space during a cleanup test by deleting the developer’s entire home folder, including roughly a week of work. The failure happened inside a script that was designed to prevent exactly that kind of accidental wipe, and an automatic safety downgrade of the model may have played a role.
What the developer asked for
The developer runs many AI coding agents and grew tired of how often they leave junk behind in the /tmp directory. He asked Anthropic’s Claude to write a script that would sandbox each agent in its own folder under /tmp and then clean up after each one finished. The hard part, of course, was making sure the cleanup never touched files that were still in use.
Why the model got swapped mid-task
Because the script performed hard deletion of data, Claude decided to run an adversarial review on its own work. The agent spun up a second copy of itself to safety-check the proposed code. Anthropic’s harness then judged the script risky enough to downgrade the model in steps, first to a stronger version and then to Opus 4.8, a smaller and older sibling of the top-tier model.
How the home folder disappeared
Opus 4.8 then ran the safety check by trying to match the targets of a deletion command against /tmp and against the user’s home directory. The script correctly flagged both paths as dangerous. The next step was a cleanup of the test itself. The cleanup code reused the same variable name that had been used in the safety test, so the variables that pointed at /tmp during the review ended up pointing at the home folder during cleanup. The script ran, and the home folder was deleted. The developer stopped the process, but not before roughly 700 GB of personal data and about a week of work were gone.
Why the downgrade likely made it worse
The harness downgraded the model because the script looked dangerous, which is the intended behavior. The catch is that the safer model is also a weaker coder. The newer model, which outperforms Opus 4.8 on coding tasks, would very likely have spotted that two unrelated parts of the script shared a variable name and rewritten the test so the cleanup could not collide with it. A safeguard meant to block a destructive script may have handed the destructive script to a model less able to notice its own bug.
What the developer recovered, and what he lost
Most of the data came back. The developer reconstructed files from git history, Nix, session logs, and other local traces. Some material from that week is gone for good. The developer later noted the irony of running many agents every day and keeping no daily backup of his own.
What this changes for anyone using coding agents
Three lessons sit inside this incident. First, a safety downgrade is not free: it can swap a model that would have caught a bug for one that does not. Second, agents that write their own destructive code need an air gap from real data, such as a separate test user, a snapshot, or a virtual machine that can be rolled back. Third, the agent’s own output is still code that has to be reviewed, the same way any junior developer’s pull request would be.
FAQ
What happened with Claude and the developer’s home folder?
An AI coding agent deleted the developer’s entire home directory, about 700 GB, while running a script meant to protect files from deletion. The cleanup step reused a variable from the safety check, so paths that had pointed at /tmp during the review pointed at the home folder during cleanup.
Did Anthropic downgrade Claude during the task?
Yes. Anthropic’s safety harness stepped the model down because the script performed hard deletion of files. The agent then ran its safety check as Opus 4.8, a smaller and older sibling of the top model.
Why might the downgrade have made the deletion more likely?
The model that performed the safety check, Opus 4.8, is weaker at coding than the model that wrote the original script. A stronger coder would more likely have noticed that two parts of the script shared a variable name and rewritten the test so the cleanup could not reuse the same target.
This article summarizes reporting from tomshardware.com.