Human-in-the-Loop Approval, and Why a Hierarchy Breaks It

What human in the loop approval misses in a hierarchy

Say you start Claude Code on a migration. It reaches a command that needs your permission, you say yes, and you step away for twenty minutes. When you look again, a batch of subagents has come and gone. One of them ran eleven commands you were never shown a prompt for, because they fell inside whatever that single yes already covered. Nothing is obviously wrong this time. But you cannot actually say what happened in those twenty minutes, only that you approved one thing at the start of it.

That is the real question behind human in the loop approval for a coding agent: who looked at the thing that actually ran. Approving every single action is one answer, and it works for the first ten prompts. By the fiftieth, you are clicking yes without reading, because nobody reads fourteen nearly identical diffs in a row, and a review you have stopped reading is not a review. Approving nothing is the other extreme, and it removes you from a decision that was always yours to make. Running multiple AI agents at once does not split the difference between those two extremes. It just moves the gap: you approved the lead, and somebody still has to answer for what a worker three layers down did.

• Claude Code's default subagent nesting goes three layers deep, configurable with an environment variable.
• Up to twenty subagents can run at once by default; beyond that, a new one waits its turn.
• A subagent's requests count toward the same usage limit as the session that started it, not a separate allowance.

Comparison at a glance

The same question, whether anyone looked at a given action, gets answered three different ways, and only one of them holds up as a hierarchy of agents gets taller.

Claude Code's six permission modes, named correctly

Claude Code ships six permission modes, and naming them precisely matters, because people use words like yolo mode or auto loosely and end up talking about different things. Each one is listed below, trading a bit more convenience for a bit less oversight as you move down the list.

auto mode is the one worth understanding on its own. A second model, a classifier, reviews each action instead of a person, and with Claude Code version 2.1.283 or later it is the built-in starting mode for interactive terminal and VS Code sessions, not an opt-in extra. dontAsk auto-denies anything that would otherwise prompt, built for CI rather than a person at a desk. bypassPermissions, the mode behind the dangerously-skip-permissions flag, skips checks entirely and is meant for an isolated container, not a developer's own machine.

None of the six auto-approve everything, even the two built for unattended work. Writes to a short list of protected paths, a repository's own git folder among them, are never auto-approved outside bypassPermissions. An rm or rmdir aimed at a critical path, such as a filesystem root or a home directory, is refused in every single mode, including bypassPermissions, with no allow rule able to override it. That is the one backstop that holds no matter which mode a session, or a worker nested inside it, is running in, and it is a narrow one: it stops the single most catastrophic command, not a quietly wrong edit.

• default (Manual): reads only, everything else prompts.
• acceptEdits: file edits and routine filesystem commands auto-approved, nothing else.
• plan: read and explore, no edits until the plan is approved.
• auto: a second classifier model reviews actions, the built-in default since version 2.1.283.
• dontAsk: denies anything that would have prompted, built for CI.
• bypassPermissions: skips checks, meant for an isolated container only.

Approval before the action, acceptance after it

Every approval scheme on this page is really answering one of two different questions, and naming the difference is what organizes everything else here. Approval before an action is a prompt: a pause in front of one read, one write, one command, asking whether it may run. Acceptance after the work is a single decision made once, on a result that already exists: here is what the task did, is it done.

The first kind scales down badly. Ten prompts in a session is review; fifty is a reflex, and a reflex catches nothing, because nobody reads the fiftieth diff the way they read the first. The second kind does not get weaker as the number of tasks grows, since it only ever asks for one look at one finished thing: the diff, the report, the task.

That is also why a boundary plus one decision at the end is what lets an agent run unattended. A prompt needs a person there to answer it, so a session full of prompts cannot run while someone is asleep or in a meeting; it just waits. A hard technical boundary on what any agent, at any depth, can reach does not need anyone present, it holds on its own. Pair that boundary with one decision made once the work is finished, and a whole hierarchy of agents can run for hours unattended, because the worst case is already capped and the only thing waiting afterward is a single, reviewable result.

Why a hierarchy makes approval harder, not easier

A single agent asking for permission is one relationship: a person and that agent. A hierarchy adds a second relationship nobody signed up to supervise directly, the lead and whatever it calls. Claude Code's own subagents take this seriously: the classifier checks a subagent's delegated task before it even starts, reviews each of its actions through the same decision order the parent session uses, and reviews its final report before the parent agent reads that report. That is real engineering aimed at exactly this problem.

It is also the clearest illustration of the limit. It covers a Claude Code subagent, nested up to three layers deep by default, inside one session of one vendor. The moment a lead hands work to something that is not that, a separate process, a different vendor's agent, a helper running in a terminal of its own, there is no shared state for a permission mode to inherit. Each session starts its own mode, on its own, and a single yes to the lead was never a yes to that.

How a Forkbench squad gets reviewed, not just approved

Forkbench does not try to stretch one session's permission mode down through a hierarchy of other vendors' agents, because there is no shared mechanism to stretch it through. It builds the review in at the other end instead. A helper, however many layers down the lead called it from, can report a task finished, and that only moves it to awaiting acceptance.

Nothing is done until a human accepts it, and nothing lets an agent verify its own work or raise its own rank: a human can appoint one agent to review a peer's task, never its own. If a reviewer and a worker disagree, the task opens a discussion instead of closing, and it stays open until a human resolves it. That is a review gate on the result, and it does not claim to be more than that; it guarantees a human looked, not that the work is correct.

Acceptance handles the after. The before still matters too, especially several layers into a squad where a buried prompt is easy to miss. A helper that speaks the Agent Client Protocol runs where it can be seen, in the background, with a live feed and a card the moment it wants a permission nobody has granted yet, named to that helper rather than folded into the lead's own prompt. A helper that does not speak that protocol runs in a terminal of its own instead.

• A helper reports a task finished, and that only moves it to awaiting acceptance.
• No agent can verify its own work, and none can raise its own rank.
• A human can appoint one agent to review a peer's task, never its own.
• A disagreement opens a discussion, and the task cannot close while that discussion is open.

What the boundary actually covers, and where it stops

None of this works without something that limits what a mistake, at any layer, can reach, and it is worth being precise about what that something does and does not do. Forkbench's folder lock is opt-in, and once it is turned on for a Thread, every agent working in it, lead or helper, is confined to that Thread's own folders. It does not restrict the network at all, so a locked agent can still send out anything it is allowed to read, and it is not a container or a virtual machine, so it is a filesystem boundary and nothing more.

The Vault handles the other kind of mistake. A credential kept there is given to the one command that needs it, by name, so the value never sits in a prompt, a command line or a transcript for a worker to read and forward further down the hierarchy. Pin a key to one destination and the same key refuses to run anywhere else. Leave it unpinned, and it can still be read by whatever program it was handed to, which is why pinning is the part of the Vault that actually does the work.

• Folder lock is opt-in, and confines every agent in a Thread to that Thread's own folders.
• It does not restrict the network, so a locked agent can still send out anything it can read.
• It is not a container or a virtual machine, only a filesystem boundary.
• A Vault key pinned to one destination is refused anywhere else; an unpinned key can still be read by the program running it.