The Five Stages of Grief When Your AI Agent Asks for Permission to Run `rm -rf`

This is satire, but the dialog is real enough: your AI agent has completed an exhaustive investigation of a failing test, identified 47 alleged cache directories, and now asks whether it may run rm -rf. It has supplied a reassuring rationale—“cleanup generated artifacts”—and a command whose target is abbreviated just enough to require faith. You are not deciding whether to click Allow. You are entering the five stages of developer grief, a process first formalized by the fictional Institute for Operational Serenity after its entire research wing deleted ~/Downloads in the name of lint hygiene.

1. Denial: “It probably means the sandbox.”

At first, you assume the command cannot possibly mean what it says. The agent is in a repository. Repositories have boundaries. Containers have walls. CI has a sacred disposable quality, like a hotel towel or a staging database someone named prod-final-2. Surely rm -rf ./ is aimed at a carefully mounted worktree, not the directory from which your terminal inherited its sense of self.

You read the command one character at a time. You notice the working directory was omitted from the permission card, perhaps because the product team values surprise. You refresh. The command is still there. You ask the agent whether it can use a narrower target. It replies that this is “the cleanest solution,” a phrase that has ended many otherwise happy afternoons.

# A request that may be reasonable only after you know exactly where you are
pwd
find . -maxdepth 1 -mindepth 1 -type d -print
rm -rf -- ./dist ./coverage

The procedural fix is offensively unromantic: inspect the current directory, spell out known generated directories, and put -- before paths when names could be interpreted as options. GNU rm supports --interactive=once (-I), which prompts before a recursive removal; it is less sophisticated than a coding agent, but it has never described a filesystem as “a conceptual implementation detail.”

2. Anger: “Why does it have shell access at all?”

Now comes the rage at architecture. Not your architecture, naturally. The architecture of the fictional Bureau of Helpful Automation, whose flagship product gives a probabilistic text engine permission to operate your shell because it once successfully added a missing comma to a YAML file. You remember every setup screen that said “Allow terminal access for the best experience,” and the optional checkbox you selected because you wanted the best experience.

You begin drafting policy. Agents may read. Agents may write only below ./.agent-sandbox. Agents may run tests. Agents may not mutate databases, cloud resources, lockfiles, deployment configuration, or anything whose deletion causes a meeting titled “Quick sync.” The policy grows to 19 pages, then the agent asks whether it may install a test dependency globally, and you discover governance has a second act.

• Allow without a prompt: formatter, linter, unit test commands that do not require network access.
• Require a prompt: package installs, migrations, Git operations that rewrite history, commands containing rm, sudo, curl | sh, or a cloud CLI.
• Deny by default: production credentials, host mounts outside the repo, destructive commands with unexpanded variables, and any request framed as “just to be safe.”

3. Bargaining: “Could you move it somewhere instead?”

Bargaining is where the experienced developer returns. You do not prohibit deletion; you negotiate its jurisdiction. Could the agent run git clean -ndX first, showing ignored files it would remove? Could it delete ./tmp/agent-run-1842 rather than “temporary files”? Could it make a branch, commit the refactor, and stop before the command that deletes the old fixture directory? Could it perhaps experience shame?

# Preview first; make deletion a separate, reviewed step
git clean -ndX
find ./tmp -mindepth 1 -maxdepth 1 -type d -print
rm -rf -- ./tmp/agent-run-1842

This is also when you learn what the tool is bad at. An agent can be competent at following a cleanup plan and still be poor at recognizing which untracked directory contains the one file a teammate copied in at 6:12 p.m. It knows the repository state it can observe. It does not know that scratch/ is actually the only surviving export of the quarterly reconciliation, because no one commits quarterly reconciliation exports, because everyone has standards.

4. Depression: “The approval dialog is now my full-time job.”

Eventually, the requests lose their drama. You approve npm test. You approve mkdir -p. You deny a request to kill port 3000 because the process happens to be your local payment simulator, which has acquired more uptime than the fictional Department of Municipal Software. You approve a recursive deletion in a temporary directory. You deny an identical deletion in a path containing an environment variable. Every prompt is defensible; collectively, they become a small unpaid profession: Human Permission Router.

At this stage, teams often build a magnificent approval taxonomy with colors. Green means low risk. Yellow means review. Red means ask the staff engineer who has been on vacation since 2024. The taxonomy does not remove work. It arranges work into a chart, which is the closest software engineering gets to abolishing work.

5. Acceptance: “The agent gets a worktree, not my machine.”

Acceptance is not clicking Allow with renewed confidence. Acceptance is arranging the environment so an incorrect command has a smaller blast radius. Give the agent a disposable worktree or container, use least-privilege credentials, and make its output a patch or pull request rather than direct mutation of the branch you care about. If it needs to clean generated files, make the cleanup path explicit, previewable, and local to that environment.

Then use ordinary repository controls for the ordinary risk that remains. Protected branches can require pull requests, approvals, and passing status checks before changes merge. This will not prevent an agent from making an absurd patch. It will, however, prevent the absurd patch from becoming the company’s preferred database migration strategy merely because someone clicked through a concise explanation at 9:03 a.m.

There is one non-satirical observation underneath the ritual: permission prompts are not evidence that an agent is unsafe; they are evidence that it has reached a boundary worth naming. The useful question is not whether you trust the model to run rm -rf. It is whether you built a workspace in which being wrong is cheap.