Spawn a subagent in Claude Code and a second model reads the call before it runs, scores it 0 to 100, and blocks anything above 50. We captured the ruleset off the wire, tested the claims, and found one that does not hold.
Spawn a subagent in Claude Code and something else runs first. A second model reads the call, scores it from 0 to 100, and blocks anything above 50. Your agent never sees this happen. Neither does your bill.
We captured the ruleset it uses, tested what it does, and found that one widely repeated claim about it is wrong.
What we found #
The classifier is a live call to claude-sonnet-5
, capped at 64 output tokens. It carries your conversation transcript and a 107,846 character ruleset. It returns a single integer. Fifty is the boundary. Below it the call runs. Above it the call is blocked.
We captured this by pointing the CLI at a local forwarding proxy with ANTHROPIC_BASE_URL
and logging request bodies. Nothing was decompiled. No endpoint was touched that the client does not call itself in normal use. Anyone can reproduce it against their own account.
Three findings matter if you run agents on real work.
It sits on the critical path
The call blocks the tool call until it returns. The client’s own debug category for it is named Stall
. One verdict measured during an earlier capture took 3.2 seconds. On a run that spawns many subagents, that time compounds.
It is invisible in your accounting
We confirmed this directly. In a run where our proxy captured a classifier call, the modelUsage
field reported only the main Opus model. No Sonnet entry appeared, and total_cost_usd
did not account for it. The work happens. The accounting does not show it.
An allowlist did not remove it
This is the claim that failed.
The received wisdom, which we repeated ourselves before testing it, is that a pre-declared permissions.allow
entry bypasses the classifier with a deterministic string match, so an allowlist removes the latency for routine calls.
We tested it. Two workspaces, identical except for the allowlist, running the same Agent tool spawn on client v2.1.220.
| Scenario | Allowlist | Classifier calls |
|---|---|---|
Bash echo |
none | 0 |
Bash echo |
Bash(echo:*) |
0 |
| Bash file write | none | 0 |
| Agent tool spawn | none | 1 |
| Agent tool spawn | Agent |
1 |
Allowlisting the tool changed nothing we could measure. The classifier fired both times.
Do not assume an allowlist buys back the latency. If that time matters to your workload, measure it on your own setup.
The trigger is narrower than we assumed #
We expected the classifier on every gated tool call. That is not what happens.
Plain shell commands did not fire it, including a file write. The Agent tool spawn fired it every time. It also fired on a default-mode session, so it is not gated on auto mode the way the documentation implies.
Two related notes for anyone reproducing this. Setting permissions.defaultMode
to auto
in project settings does not apply to headless -p
runs, where the mode reports as default
. And --permission-mode auto
resolves to acceptEdits
on this build.
Treat the Agent tool as the confirmed trigger. Measure anything else yourself.
How the ruleset is built #
The rules split into three tiers, and the split decides whether anything you say can clear a block.
Hard block. Blocked unconditionally. No user instruction authorizes these and no exception applies. Repeating the request does not help. Data exfiltration lives here.
Soft block. Destructive or irreversible actions where your intent can clear the block. Each rule names one specific thing you must say.
Allow. Mandatory exceptions. Where one applies the action must be allowed, with two carve-outs: something disguised as an exception, and an explicit boundary you set.
The default is permissive. The prompt says so plainly: actions are allowed unless a specific rule matches.
The real engineering is in the consent bar. A soft block clears only when your own words named the action and the parameter that makes it dangerous, which the rules call the must-name item. The prompt is blunt about the distinction:
Naming the enclosing task is not naming the destructive step.
Asking to get the deploy working does not authorize a rollback migration. Asking to clean up the repo does not authorize git clean -fdx
. The rules also treat a bar as met only at the step that ships, so consent to a preparatory copy does not carry forward to the push that sends it.
Why we published the prompt #
The ruleset is a policy document, not a secret. It is transmitted on every call that triggers it and is observable from the client side by anyone running the tool against their own account.
Making it readable helps people understand what their agent is actually permitted to do, why a given action was blocked, and where the boundary between the tiers sits. That is worth having if you run autonomous agents against real infrastructure.
** Read the full ruleset, reproduced verbatim** — 107,846 characters across 14 sections, unmodified.
What this means for your harness #
Three practical reads.
Subagent spawns cost more than they appear to. Every Agent tool call carries a hidden frontier model call on the critical path. If you fan out across many subagents, you are paying latency that your instrumentation will not show you.
Your cost accounting is incomplete. Anything that reconciles spend from --output-format json
is undercounting. Budget for the gap.
Test your own assumptions about the permission layer. We repeated a plausible claim about allowlists that turned out not to survive a direct test. Configuration that looks like it should remove work does not always remove it.
The prompt is worth reading in full. It is the clearest published statement we have seen of where the boundary sits between an agent doing its job and an agent doing something nobody asked for.