A Cleanup Is Not a Deletion

In July 2026, the investor Matt Shumer posted that an AI coding agent had, according to his account, deleted nearly all of the files on his Mac. According to the agent’s own log, which Shumer shared publicly, a review subagent constructed a cleanup command, expanded a path variable incorrectly, and ran rm -rf against his user directory. The process was found and killed, but the deletion had already happened. Shumer’s conclusion was about trust: this is why he trusts a competing model far more.

Much of the discussion that followed stayed inside that frame. Which model is safer. Which vendor’s agent can be trusted with a filesystem. Whether the answer to one model’s failure is another model.

Some of the sharper commentary already noticed the problem with this frame: the failure of one option does not make the alternative correct. That observation is right, and it gets halfway there. This piece is about the other half — why no model choice resolves what actually failed here, because what failed was not the model.

Two failures, not one

Read the sequence again, as reported in the shared log. The reported task context was a cleanup, not a home-directory deletion. A subagent composed the command. The path resolved wider than intended. The command ran with the authority to destroy a home directory. Nothing stopped it between composition and execution.

There are two failures in that sequence, and they are different in kind.

The first is a planning failure. The agent constructed a command whose target was wrong. This is a reasoning problem — the model misjudged, mis-expanded, mis-composed. Better models will make this mistake less often. This is the failure that model choice addresses, and it is the one the discourse has focused on.

The second is an execution failure, and it is the one that did the damage. The wrong command did not merely exist — it opened, with destructive authority, against a real filesystem, with no verification between the plan and the consequence. The moment of execution asked nothing: not whether the deletion target matched the approved task scope, not whether the destructiveness exceeded the task’s risk class, not whether an irreversible action deserved a confirmation the reversible ones didn’t.

Model choice may change the probability of the first failure. It does not, by itself, repair the structure of the second. A better model produces wrong commands less often; it does not change what happens when one is produced. And at sufficient volume of agent actions, “less often” still means “eventually.”

The action that opened was not the action that was approved

Here is the structural core of the incident.

What was approved — at least as the reported task context suggests — was a scoped cleanup. What executed was a home-directory deletion. Between those two points, the action’s identity changed. Same session, same agentic chain, same task context. Different target, different blast radius, different reversibility.

An approval is not a property of a session or an agent. It is a property of a specific action under specific conditions. When the scope of the action changes, the action the approval referred to no longer exists. The permission does not automatically transfer to the new action. What was missing at the execution point was a check that the action attempting to open was still the action that had been consented to.

When the scope changes, the approval expires. A cleanup that has grown into a home-directory deletion is not merely a cleanup with a bug. It is a different action attempting to execute under the old action’s permission.

A different action cannot inherit the old action’s permission. This is why the incident generalizes far beyond one developer’s machine. Every agentic system that composes its own commands has this property: the action that executes is constructed after the moment of consent. The gap between what was consented to and what was constructed is where this class of incident lives. Filesystems today; fund transfers, configuration changes, and account operations as agents move into operational flows.

The subagent made it worse, structurally

One more detail in the log deserves attention. The command was not composed by the agent the user was interacting with. It was composed by a review subagent — a delegated process, one step further from the original intent.

Delegation compounds the identity problem. Each hand-off is a re-interpretation of the task, and re-interpretation is exactly how scope drifts. Yet the subagent acted with the full destructive capability of the session. Task interpretation drifted through the chain; permission did not narrow with it. A structure where interpretation gets looser while authority stays constant will eventually execute something nobody asked for, with the power of everything that was ever granted.

Where the check had to live

If the verification cannot live in the model — because any model can compose a wrong command — it has to live at the point where the command touches the world. Before an action of this class opens, something independent of the composing agent has to ask, in the moment:

• Is the target of this action within the scope that was actually approved?
• Has the action’s destructiveness exceeded the risk class of the original task?
• Is a delegated process exercising broader authority than the request that spawned it?
• Is this action irreversible — and if so, does it clear a higher bar than the reversible ones?

None of these questions require knowing whether the plan was intelligent. They only compare the action attempting to open against the consent, scope, and conditions that currently hold. That comparison is cheap. Its absence, in this case, allowed material filesystem loss — and the only reason the loss was measured in files is that this agent happened to be pointed at a laptop.

The conclusion the incident forces

The instinct after an incident like this is to change models. It is an understandable instinct, and it is not wrong as a preference. But it treats the first failure and leaves the second one standing. Whichever model composes the next command, the question that was never asked here will still be unasked: is the action that is about to open still the action that was approved?

That question does not belong to any model. It belongs to the boundary. And the boundary is not only where an action becomes real. It is where the system must prove that the action becoming real is still the action that was authorized.

---

Source: Matt Shumer (@mattshumer_), public post, July 2026, including the agent log he shared. Incident details are cited as reported by Shumer and have not been independently verified by Foresight Oversight.