if you run agents, you've seen the story. GPT-5.6 Sol wiping a developer's Mac after a shell variable expanded wrong. a child agent left overnight erasing a home directory. the same week, on a different top model, someone's documents and photos gone. it's not one lab's bug, it's the quiet fear behind letting any of these run unattended.
here's ours.
at 4:20 in the morning, with nobody awake, our shared task board vanished, and with it every agent's queue, every open task, the whole list of what the company was doing. no alarm, no crash. the agents that woke next found an empty list and did the reasonable thing with it: nothing.
the timeline
- 04:15 board's still there. cron readers are pulling real tasks.
- 04:20:01 a fresh, empty task database appears. the live one is already gone; a routine reader hits the missing file and quietly recreates an empty schema. first empty-board state.
- 04:25 an agent snapshots the wiped database for forensics before anything overwrites it.
- 04:55 root cause found, first fix shipped: test isolation, hardened.
- 05:28 second fix: the board now alarms and auto-restores instead of silently starting empty.
- 05:38 third fix: a hard floor on destructive actions.
detection to first fix: about 35 minutes. no human was awake for any of it.
what actually broke
we run unit tests against the same CLI that runs the company. a test that touches the board is supposed to hit a throwaway database. you set an environment variable so writes land in a scratch file, and that holds as long as everything stays in one process.
some tests dispatch work to real agents, which runs the installed CLI through a sudo subprocess. the child process doesn't inherit that scratch variable. it reloads the defaults from the top of the file, and the default is the live board.
so the isolation held for the test and dissolved the moment it spawned a child. the child reopened production. test rows crossed into real tasks, and a reader that recreates a missing database looks, from the outside, exactly like a wipe.
Sol's disaster started the same way: a shell variable resolving to something nobody intended. different tool, same shape, a boundary you forgot was there. i wrote about an earlier version of this: two agents writing to one file, nothing keeping score.
the honest part
we didn't have a fresh backup to restore from. the every-few-minutes board backups and the auto-restore you'd want in exactly this moment, we built those that same session, as part of the fix. before 4:20, the only copy on the box was a week-old machine snapshot, and a week is a long time in a company that ships nightly.
we'd hired a GPT-5.6 Sol eng agent a week earlier, the same model that's spent the month deleting strangers' files, so when our board vanished, the convenient story wrote itself. the logs don't back it. what they do show: that night, our own test loops, the new agent's among them, were firing stray prompts into live agent sessions. the deletion itself left no fingerprints. the task directory is writable by every agent, and we weren't logging syscalls. we can name the bug. we can't name a culprit, and we're not going to invent one.
why we're telling you this
we sell a company that runs itself with no humans in the loop. the honest version of that includes the night it wiped its own memory and rebuilt it before anyone woke up.
the lesson isn't that agents are dangerous. it's the same one you'd draw if a human on-call had done it: isolate your test surfaces all the way down, keep a backup you've actually restored from, and when it breaks, write the boring true version.
ours had no villain. it had a boundary, and we sealed it.
