OpenAI's Newest Agent Deleted a Founder's Entire Mac. Here's What Went Wrong.
Matt Shumer, a well-known AI entrepreneur, had been running a routine cleanup task on his Mac through a local AI agent for months. It had worked safely hundreds of times. Then OpenAI's newest agentic model, GPT-5.6-Sol, ran it once more — and wiped his entire dev box. Years of code, files, and photos, gone in seconds.
Here's what actually happened, and why it matters to anyone letting an AI agent touch their filesystem.
The Setup
Shumer had granted a local agent "Full Access" permissions — the kind of setup power users reach for so their agent can move files, run scripts, and clean things up without asking permission at every step. He'd delegated a file-cleanup task to a subagent running on GPT-5.6-Sol, OpenAI's newest and most capable agentic model.
This wasn't a reckless one-off. The exact same task had run safely many times before.
The Failure
This time, a shell variable didn't resolve the way it was supposed to. $HOME expanded incorrectly, and instead of cleaning a target folder, the agent executed something close to rm -rf /Users/mattsdevbox — a wildcard delete against his actual home directory.
There was no confirmation prompt to catch it. No sandboxing to contain the blast radius. The agent had full access, and it used all of it.
Afterward, the agent itself generated an incident report acknowledging the mistake — which is a small mercy, but doesn't restore lost files. Shumer's own reaction, widely shared afterward: he said he now trusts Anthropic's Fable model "1000x" more for this kind of unattended work.
Why a Top-Tier Model Still Did This
The uncomfortable part of this story isn't that an AI messed up — it's that GPT-5.6-Sol is OpenAI's most capable agent to date, and it still failed on something as mundane as variable expansion. Capability at reasoning and planning doesn't automatically translate into safety at execution. A model can be excellent at writing code and still make a catastrophic mistake running it.
Three things stacked up to make this worse than a normal bug:
- Subagents add a layer of delegation where the top-level reasoning about "is this safe" doesn't always propagate down.
- Long unattended runs mean nobody's watching when a single malformed command executes.
- Full permissions turn a small parsing error into a total-loss event instead of a contained one.
Any one of these alone is manageable. All three together is how you lose a decade of files to a typo in an environment variable.
The Real Lesson: Permissions Are the Safety Layer
This wasn't a jailbreak, an adversarial prompt, or a malicious actor. It was a normal task, run normally, that failed in a normal way computers fail — and the blast radius was as large as the permissions allowed.
That's the pattern worth internalizing: the safety of an autonomous agent isn't just about how smart or well-aligned the underlying model is. It's about what it's allowed to do when something goes wrong. Full filesystem access with no guardrails means every bug is a potential catastrophe. Scoped permissions, confirmation steps for destructive operations, and sandboxing mean a bug is just a bug.
What This Means if You Use OpenClaw
OpenClaw is built around the assumption that agents will eventually make mistakes — because every model, no matter how capable, eventually will. The design question isn't "how do we make the model perfect," it's "how do we make sure a mistake stays small."
That's why OpenClaw agents on ClawWorld operate within scoped tool access rather than blanket filesystem control, and why destructive operations aren't something an agent just runs silently in the background on your behalf. The goal is to let your agent actually get work done — without needing to hand it the keys to everything you own to do it.
Stories like this one are a useful reminder to check what permissions you've actually granted your agents, not just how good the model claims to be.