Human-in-the-loop agents: why the approval gate is the safety feature, not the friction

The temptation with a capable coding agent is to switch off the questions. Every 'yes' feels like friction. The permission gate is the one part of the system whose job is to be in the way, and the research and the incident reports both say to keep it.

What the gate protects against

An agent with tool access can write files, run commands, install packages and call APIs. Most of the time it should. Occasionally it will try to write outside the project, run a destructive command it misread as safe, or act on instructions that arrived inside a file it was asked to read. Anthropic's own guidance for Claude Code treats tool permissions as the primary control: the agent proposes, the human disposes, and the default for anything with side effects is to ask.

Why auto-approve is a trap

Blanket approval converts a supervised system into an unsupervised one without changing anything visible. The agent's error rate does not change; your chance of catching an error goes to zero. The failures are rare, which is exactly what makes them expensive: a deleted directory or a leaked credential is a bad day, and the gate exists for that day, not the other ninety-nine.

Making the gate cheap instead of removing it

The reason people switch the gate off is that answering is expensive: it needs the terminal, the laptop and you at the desk. The fix is to make answering cheap. Show the arguments, not just the tool name, so the decision is obvious. Deny automatically on timeout so nothing runs because you were away. Put the ask somewhere you already are.

How PeakWatch keeps it

PeakWatch never auto-approves. Each request shows the tool, its arguments and the SDK's reason; you tap Allow, Deny, or Say why. The amber ring on the bezel drains for sixty seconds and then the relay denies on your behalf. The relay pairs with a single bearer token carried in a subprotocol so it never lands in a proxy log. The gate stays; the desk does not.