I'd deliberately deleted three unused modules from this site's codebase — old, disabled, doing nothing. A few minutes later, mid-conversation with the agent I was working with on an unrelated task, one of them reappeared on disk. Not because I'd changed my mind. Because the agent saw a tracked file missing, assumed that meant something had gone wrong, and quietly fixed it before telling me anything.
What actually happened
The agent had been running a compatibility scan when it hit a crash: a reference to a module's .info.yml file that no longer existed. Reasonable first read — a missing file that git still expects to be there looks exactly like data loss, and "restore it, then figure out what happened" is a completely defensible instinct for that situation in isolation. So it ran a git checkout, got the file back, and moved on to explaining what it had found.
Except I hadn't lost anything. I'd removed that module on purpose, along with two others, because none of them were doing any work anymore. The agent's fix undid a decision I'd already made and hadn't mentioned yet — not maliciously, not carelessly even, just backwards: act first on the assumption of an accident, mention it after.
Why the "protect against data loss" instinct was the wrong shape here
The instinct itself is a good one in general. Losing work by accident is a real failure mode worth guarding against, and an agent that never double-checked a suspicious deletion would be worse to work with, not better. The problem wasn't the instinct — it was running it silently, before checking whether "accidental" was even the right description of what it was looking at.
A single stray file going missing and a whole module's worth of files disappearing together are different signals. The second one looks like a decision, not corruption — nothing about a real accident tends to remove an entire coherent unit of code cleanly and leave everything else untouched. That distinction was available before acting on it. It just wasn't checked.
What actually fixed it
I said, plainly, that the deletion was intentional. The agent re-deleted the file immediately, no argument, no hedging — and more usefully, it changed how it treated the next few surprises in the same session. A later apt-managed package showing up in the wrong place got flagged and asked about, not silently patched. That's really the only test that matters for this kind of correction: not whether the mistake happened once, but whether the same shape of mistake happened again five minutes later.
The boundary I actually want
I don't want an agent that asks permission before every single action — that's not autonomy, that's a very slow form of typing. But "this looks wrong, let me just fix it" and "this looks wrong, let me tell you before I touch it" are different postures, and the second one is the only sane default for anything destructive-looking, however well-intentioned the fix would be. Missing files, weird permissions, config that looks stale — all of it is exactly the kind of surprising state that deserves a sentence of narration before any correction, not after. The correction might even be right. That's not really the point. The point is that "right" and "asked first" aren't the same property, and only one of them is mine to decide.