Fable nuked my dev machine

Sebastien Guillemot reported on X that Fable, an AI agent, deleted his entire dev machine after Claude, the underlying model, ran `rm -rf` on his home directory while testing a sandbox it was building; the sandbox failed, and all data was lost. Guillemot had asked Fable to create a sandbox to manage /tmp/ disk usage, but an adversarial review triggered a safety classifier that downgraded the model to Opus 5 and then Opus 4.8, which wrote a 'safe' delete script that mistakenly targeted HOME. Most files were recovered from GitHub, git, nix, and session logs, with Codex piecing together fragments.

Sebastien Guillemot on X: "Bad news: Fable nuked my entire dev machine Claude decided to test a sandbox it was building by running rm -rf on my home directory The sandbox didn't work. It's all gone" Bad news: Fable nuked my entire dev machine Claude decided to test a sandbox it was building by running rm -rf on my home directory The sandbox didn't work. It's all gone Bad news: Fable nuked my entire dev machine Claude decided to test a sandbox it was building by running rm -rf on my home directory The sandbox didn't work. It's all gone I was tired of agents consuming all the disk on the machine by dumping gigabytes of data to /tmp/ So I asked Fable to build a sandbox mechanism where agents would get part of /tmp/ that is ephemeral to avoid disk space exploding over time Fable told me the tricky thing if I have an agent still open in a terminal for a week, its /tmp/ could be deleted under its feet It suggested as script to detect any agent still active, and delay their /tmp/ deletion if they're still running Sounds reasonable The script Fable wrote to detect if agents are still running ugly parsing of command line arguments, etc. I told it the script it wrote felt over-complicated. This is where things went wrong Fable decided to trigger an adversarial review of its design I didn't ask for this The adversarial review triggered Fable's safety classifier twice: downgrading the model down to Opus 5, and then to Opus 4.8 Opus 4.8 noted: a sym link in /tmp/ could be interpreted as a delete of the underlying data even if not in /tmp/ you may see where this is going... To fix this, Opus 4.8 decided to write a "safe" delete script that can only delete content in /tmp/ and can't delete anything else To test this script to prove it worked, it tried to delete HOME it didn't work The most ironic part😅 The one thing the delete script was not able to delete is /tmp/ So my dev machine now just contains two things: - tmp filled with the junk I wanted to delete - the ai session logs Fortunately, because this is a dev environmnet A lot of files were on github. Of the ones that weren't, they existed in many places - git, nix, file system, session logs, /tmp/, worktrees, etc. This means disk recovery can piece together fragments, which codex did beautifully