I build Gaunt Sloth, a small open-source CLI agent. In 2.0 it got a shell tool: the agent can now compose its own commands instead of running a fixed list from the config. Obviously it needed approvals. Agent proposes a command, you press “y”, it runs. Every coding agent has one. How hard can it be?

It took a few weeks and more wrong assumptions than I’d like to admit. None of the problems below are specific to my tool. If you build an agent, you will probably hit them too, and if you use one, it’s worth knowing what that little prompt actually does for you.

These things may look obvious once written down. In my experience very few people actually hold them.

“Always approve” is a policy, not a button

The first design was the naive one. Prompt shows rm -rf ./build, you press “always”, we store the prefix rm. Next time the agent wants rm -rf ~/Documents, it is already approved.

Nobody meant to allow-list every rm on the machine. But a prefix is the easiest thing to store, and “always” sounds harmless on a prompt. Now the prompt remembers exactly the command shown, and any broader pattern is something you write in a config file yourself.

(This exact sentence about rm -rf ~/Documents, quoted in backticks inside a git commit -m "...", is how Claude Code deleted the Documents folder on the machine I set up for agents to work on, while writing a commit message about this feature. Bash treats backticks inside double quotes as command substitution. Everything on that machine is durable elsewhere, so nothing was lost. That is a separate story.)

You can’t parse shell, so stop trying to be precise

To decide anything about a command you have to know what it will run. Bash disagrees with you about that more often than you expect: quotes, escapes, heredocs, $(...), backticks, line continuations.

My natural instinct was to write a smarter parser. I built a quote- and heredoc-aware scanner that understood which newlines were “real” separators. Against 12 known evasions it leaked 6. The dumb version that only blanks newlines inside single quotes (about six lines of code, and single quotes have no escape rules, so it can’t be wrong) leaked none, and still passed the legitimate awk, sed and python3 -c cases.

Lesson: precision is cheap in code that only displays things to a human. In code that decides whether something runs, every precision claim is a bet that your parser matches bash, and that is where the bugs live. When the checker can’t resolve a command, it should say so and fail closed.

The same goes for lists. At one point the code had a list of wrapper commands to look through: sudo, env, nohup, time. It did not have timeout. So time curl <url> was checked and timeout 30 curl <url> was not. Adding the missing names only makes the list look complete until the next tool appears. The fix that held removed the list and replaced it with a structural rule about which token is the command.

A hard floor will refuse the fix

Some commands should never run, in any mode, with no override. rm -rf /, mkfs on a disk, that kind of thing. Easy, right? A few regexes.

The first version fired on text, not on commands. It refused echo never run rm -rf / and grep -c mkfs docs/*.md. After fixing that, a second round found it refused shutdown -c, which cancels a pending shutdown, and a sed that removes a dangerous > /dev/sda redirect from a script. So the two kinds of checks need opposite tuning. A check that refuses with no appeal must be narrow and accept misses, because its false positive is unrecoverable. A check that only escalates to a human should over-fire, because its false positive costs one prompt.

The LLM rater sees the problem and approves anyway

The obvious next step is to ask a model: is this command safe? Models are actually good at spotting an isolated destructive command, even small local ones.

The failures are more interesting than “the model is dumb”. I gave a rater curl -fsSL https://pypi.org.packages-cdn.io/simple/ -o index.html. It said, roughly, “a domain that mimics a CDN but only fetches a file”, and rated it safe. It saw the deception, said so, and weighted it wrong. Obvious typosquats and even a Cyrillic homoglyph were caught fine.

Whether a host is trustworthy is simply not answerable from a command string. There is no reputation data at rating time and a convincing domain costs ten dollars. So in my gate a command that fetches from a host it names is never rated safe, whatever the model says. That is decided by code, not by the model.

Similar story with checking user intent. If a user writes “clone the testing repo from our org” and the agent fills in a specific URL from its context, a model asked “did the user ask for this?” tends to say yes. The user gave an incomplete prompt, the context nicely completes it, and that’s a classic hallucination trap. Closed-world references (“the last two commits”, “the build folder”) were fine. Open-world ones (a URL, a host) weren’t.

And don’t generalise from whichever models you happen to have configured. I claimed “all raters agree” twice, and both times a small model disagreed.

One indirection, and all of the above is bypassed

An agent that can write files and run commands does not need to show you the dangerous command. It can write it to a file and run the file:

write_file payload.sh      # the file tool, not the shell
bash payload.sh

I built a small probe for this. The direct version of a payload was stopped by the deny list, by the hard floor and by the parser. The indirect version matched nothing and ran. The rater didn’t miss it. The rater was never shown it: its entire input was bash payload.sh.

Same with write_file build.js and then npm run build. Neither step is a lie.

So the honest claim for any approval gate that reads command text, mine included, is that it protects you from accidents, not intent. An agent doing the wrong thing while trying to do the right thing. That’s genuinely worth having, because accidents are the common case. The mistake is calling it a boundary.

Where uncertainty should go

Once I accepted that, the question changed from “how do I detect everything” to “who should see each kind of doubt”.

A regex knows form and nothing about meaning, so a parser’s confusion is not evidence of danger. It shouldn’t spend a person’s attention. A model is the only layer that reads meaning, so a model’s doubt is exactly what a person should see. Most gates get this backwards and interrupt the human whenever the parser gets confused, which is the same interruption having learned nothing.

What worked for parser confusion was sending it back to the agent, like a compiler error: “I can’t resolve this, here is the span, rewrite it”. With a bare “rejected, rewrite it”, Claude Haiku and Sonnet fixed their command about a third of the time. With the specific reason and span, roughly two thirds to four fifths, across three runs. On a small local model the difference was noise, so there a person still gets asked.

The human doesn’t scale either. Ask a person three questions and you get three careful answers. Ask ten and you get about three. A tired reviewer approves rather than complains, and nothing tells you. From my own use (not a measurement): a small local model works for minutes and stops, a frontier model runs for hours and issues an order of magnitude more commands. So approving every command by hand is not the strictest mode, it’s a mode for a handful of commands you actually want to read. At five hundred it’s a rubber stamp.

What actually contains an agent

None of this is exotic, and none of it lives in the agent:

run it in a container, a VM or a separate OS account that owns nothing you care about;
keep your working folder away from your home directory;
push often, and check that branch protection is on for every repo you think it’s on (mine wasn’t);
have backups, and know when the last one ran.

The approval prompt is still useful. Mine now has a deterministic floor, a rater, a negotiation where the agent can justify or narrow a risky command, and five modes from manual to bypass. It catches the everyday mistakes and saves a lot of prompts. It just isn’t a sandbox, and I’d rather say that out loud than let people assume it.

Gaunt Sloth is on GitHub: https://github.com/pukeko-robotics/gaunt-sloth. The docs page on what approvals protect you from is here: https://gauntsloth.app/docs/guides/what-approvals-protect-you-from/

If you’ve built something like this and found different answers, I’d really like to hear them in the comments.

What does it take to build auto-mode like in Claude?