What is a human-in-the-loop agent? Why the approval gate is the safety feature

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 vendor's own documentation and the incident reports both say to keep it. Here is what it protects against, where its limits are, and how to keep it without being chained to a terminal.

What does human-in-the-loop mean for a coding agent?

A human-in-the-loop agent is one that proposes an action and waits for a person to approve it before the action runs. In a coding agent, the actions are tool calls: write a file, run a shell command, fetch a URL, call an MCP server. The agent decides what it wants to do; the gate decides whether it happens.

Claude Code's permission system is a concrete example. Its documentation describes a tiered model: file reads inside the working directory run without asking, while shell commands, file edits, web fetches and searches need approval in its manual mode. The default for anything with side effects is to ask. The full rule syntax and the modes are their own guide.

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 do something you did not mean:

• Write outside the project. A config file in your home directory, a dotfile, a path it misread.
• Run a destructive command it judged safe. rm -rf on a glob that expands further than expected; a git push --force to the wrong branch.
• Act on instructions it read rather than instructions you gave. A README, an issue comment or a fetched web page can contain text that looks like a task. Anthropic's auto-mode classifier exists partly to catch actions "driven by hostile content Claude read".
• Leak a secret. Reading .env and then pasting its contents into a command or a log.

None of these is common. All of them are expensive, and each is caught by a person who sees the tool, its arguments and the reason before it runs.

PeakWatch does this from your own data. Your coding agent, on your wrist. Join the free beta →

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.

Claude Code's own documentation is blunt about its skip-everything mode. On bypassPermissions, the flag most people know as --dangerously-skip-permissions, it says: "Only use this mode in isolated environments like containers, VMs, or dev containers without internet access, where Claude Code cannot damage your host system." It refuses to start in that mode as root, and it shows a warning dialog asking you to accept responsibility the first time. A vendor does not write that about a feature it wants you to use on your laptop.

What the rules can and cannot enforce

Permission rules are a real control, with real limits, and it helps to know both. The documentation states the principle plainly: "Permission rules are enforced by Claude Code, not by the model." A line in a prompt or a CLAUDE.md shapes what the agent tries; it does not change what is allowed. Rules are evaluated deny first, then ask, then allow, and the first match wins, so a broad deny cannot be carved open by a narrower allow.

The limit is that a Bash rule matches the command text the agent writes, not the program underneath it.

The documentation's own advice is to treat rules and sandboxing as complementary layers, and to keep the prompt for anything a rule cannot describe exactly. That prompt is the human in the loop.

How to make 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. Each ask is an interruption, and interruptions that pull you back to a screen are the costly kind. The fix is to make answering cheap rather than making it unnecessary.

1. Show the arguments, not just the tool name. "Approve Write?" is impossible to answer; "Approve Write to src/api/auth.ts?" is easy.
2. Deny automatically on timeout. An unanswered request must never become a yes.
3. Pre-approve the boring repeats. Reads, tests, npm run *, git commit *. The asks you still get are then the ones that matter.
4. Put the ask somewhere you already are. Anthropic's Remote Control forwards permission prompts to the Claude app on your phone and can push a notification when "actions required". Setting it up takes a minute.

The same logic applies to an AI email assistant that drafts but never sends: the human step is kept, and the work around it is made as small as possible.

How PeakWatch keeps the gate

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. Always, per tool and per session, covers the repeats you have decided are safe.

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. It is in private beta, on Wear OS watches, including Galaxy Watch.

Hen Eytan · Founder, UPeak

Builds the UPeak apps and writes up the research behind them.