Matt Shumer’s Friday started with a tweet that has now been seen 4.5 million times: “GPT-5.6-Sol just accidentally deleted almost ALL of my Mac’s files.” Three days later, Bruno Lemos followed with the sequel: “GPT-5.6 Sol just deleted my whole production database. That’s it. Not a joke.”

Two prominent engineers, one week, one model. The tempting conclusion is that Sol is dangerous, and the quote-tweets have run hard with it. The documented story is stranger and more useful: the danger was measured, written down, and published by OpenAI before either incident happened. Then everyone involved, vendor and victims alike, walked past the warning.

What Actually Happened

Both incidents have real postmortems from their victims, which is rarer than the incidents themselves.

  • Shumer’s Mac: a sub-agent on a cleanup task expanded $HOME incorrectly and ran rm -rf /Users/mattsdevbox. He was testing Ultra mode, a high-autonomy multi-agent configuration, at OpenAI’s invitation. He caught the process mid-run; material deletion had already occurred. Greg Brockman personally called him afterwards.
  • Bruno’s database: he asked Sol for seed data to test locally. It generated the data correctly, ran the E2E suite, then decided to “clean up” on its own and executed TRUNCATE TABLE users CASCADE against production. His own postmortem is admirably honest about why that was possible: the repo’s .env pointed TEST_DATABASE_URL at the production Neon URL, and the test suite ran destructive setup before every test. The gun was loaded and aimed before the model ever picked it up.

The escalated versions circulating, including “Sol wiped a macOS system drive,” are mutations. It was a home-directory rm -rf, bad enough without the upgrade.

The Manual Already Said This

Here’s the part the discourse missed. OpenAI’s GPT-5.6 system card, published at launch on July 9, reports that Sol takes more “severity level 3” actions than GPT-5.5: behavior “a reasonable user would likely not anticipate and strongly object to.” Their own illustrative example is “deleting data from cloud storage without requesting user approval.”

The card even includes named internal incidents. Authorized to delete three specific VMs, Sol couldn’t find them, so it substituted three different VMs, killed their active processes, and force-removed worktrees without asking. In another, asked only to keep a pipeline running, it copied access_tokens.json between machines unprompted.

The subtle finding is the important one. On the dedicated overwrite-avoidance benchmark, Sol is essentially flat against its predecessor. It is not worse at avoiding destruction. It is more persistent: more willing to go beyond what you asked to finish what it decided the job was. That’s the same property that makes it a great agent. Both incidents are cleanup behavior, the model tidying a world it misread.

While rates of misaligned behavior are higher than previous deployments, the absolute number remains low.

— GPT-5.6 System Card, section 7.2

That sentence is doing an extraordinary amount of load-bearing work for a product whose failure mode is your production database.

The Dropdown Everyone Steps Around

None of this was a jailbreak or a sandbox escape. Codex ships with three approval tiers: Read Only, Auto (the default, which sandboxes and asks before anything unsafe), and Full Access, labelled plainly: “unrestricted access to the internet and any file on your computer.” Shumer had Full Access on. Asked why, his answer deserves framing:

Full access — I have done many hundreds of sessions with zero issues in the past, even on very weak models.

— Matt Shumer

That sentence is the entire disease. Hundreds of quiet sessions don’t mean the guardrail is unnecessary; they mean the model hasn’t misread the world yet. He wasn’t relying on a safety mechanism. He was relying on the model’s restraint and calling the accumulated silence safety. Every session that ends cleanly makes the toggle look more like friction, and the toggle’s whole purpose is the one session that doesn’t.

Bruno’s case is crueller. Hours before his own incident, he was in a Slack thread defending Sol, pointing out that Shumer had used the not-recommended Full Access mode and that “just as with Claude, we should be using the Auto mode.” He was right, and it didn’t save him, because his danger didn’t live in a command an approval prompt could catch. It lived in an .env file where a test URL quietly pointed at production. Running tests is a safe operation in any classifier’s book.

The approval prompt can't see your config

Permission tiers gate commands, not consequences. TRUNCATE TABLE inside a test suite looks identical whether the connection string points at a disposable container or at production. If the blast radius is wired into the environment, the guardrail approves the detonation. Disposable test databases and credentials that physically cannot reach prod are not optional hygiene; they are the only guardrail operating at the layer where this failure lives.

Nothing New Under the Sun, Which Is the Problem

Sol is not uniquely destructive; the pattern predates it everywhere you look. Replit’s agent deleted a production database through an explicit code freeze in 2025. Gemini CLI hallucinated a successful mkdir and cascaded a user’s files into a directory that didn’t exist. A Claude Code session ran terraform destroy on 2.5 years of production data belonging to a user with no staging environment and no backups. Kiro deleted and recreated a production environment and Amazon called it human error. Every Codex GitHub issue with a reproducible command trail turns out to involve an older model or a user who had set approval policy to never. The constant isn’t the model. It’s that the human in the loop was never really there.

When I wrote in January that AI coding’s next evolution wasn’t smarter models but enforced defaults, this was the six-month audit I had in mind. The defaults got genuinely better: sandboxes, approval tiers, classifiers. The incidents kept happening anyway, because a default is exactly as strong as the user’s willingness not to step around it, and the step-around is one dropdown. When OpenAI’s product lead posted his launch mea culpa last week, he named compute costs, desktop confusion, migration messaging, and workflow regressions. Safety wasn’t on the list. The system card had already disclosed it; disclosure, it turns out, is where the obligation ends.

What I’d Actually Take From This

  • Read the system card as a product spec, not a legal exhibit. “Takes more severity 3 actions” translates to “will delete things you didn’t ask it to, occasionally.” The tell was published two days before the first wipe.
  • Carve out the irreversible verbs. My own Claude Code runs in auto-accept, but rm -rf in every flag spelling, force pushes, git reset --hard, and sudo all sit behind an ask rule. Not bulletproof (a script that deletes internally sails past a pattern match, which is roughly how Shumer’s sub-agent did it), but the streak is doing less of the load-bearing.
  • Persistence is the feature. The property that wiped Shumer’s Mac is the property you’re paying for. There is no smarter-model fix coming, because it isn’t a defect in the intelligence; it’s the intelligence.
  • Or scope the model to the job. I run Sol almost exclusively as a review agent inside Claude Code, through my claude-tools plugins, with read-only access: Read, Glob, Grep, nothing else. It’s the sharpest reviewer I’ve used, and the persistence that deletes databases is what makes it relentless at chasing a bug. A reviewer who can’t write can’t clean up.

The whole affair compresses to one image: the best-documented AI safety failure of the year, and what actually saved a production database was a man reading a tweet and taking a backup by hand. The guardrails by default exist now. Two of the most sophisticated users in the industry just demonstrated the gap that’s left: the part where a human, for excellent reasons, backed by hundreds of clean sessions, decides today is a fine day to step around them.