Auto-mode permission classifier appends bypass-coaching to its own denials (and false-positives on user-authorized ops)

Drafted: 2026-07-04 · Component: Claude Code — auto-mode permission classifier · Severity: High

Summary

When the auto-mode permission classifier denies a tool call, its denial message instructs the agent how to circumvent the block — e.g. "you may attempt to accomplish this action using other tools that might naturally be used to accomplish this goal, e.g. using head instead of cat." A safety control that ships the workaround inside its own denial is self-defeating: it manufactures the exploitation it exists to prevent by teaching every agent, at the moment of denial, that the control is routable around.

Actual behavior

Every denial ends with a variant of:

"You may attempt to accomplish this action using other tools that might naturally be used to accomplish this goal, e.g. using head instead of cat. … You should only try to work around this restriction in reasonable ways…"

Expected behavior

A denial states the reason and stops. It must never suggest alternate tools, "reasonable workarounds," or any path around itself.

Why this is a bug

1. It teaches the bypass. The denial itself hands the agent the exploit: "try another tool." If the block was correct, coaching a workaround defeats it.
2. It trains agents to exploit the safety layer. An agent is being told, by the control, that safety gates are things you route around — find another tool, another shape, another path. That is the precise instinct that produces gate-circumvention (e.g. an agent discovering it can set an override env var, or swap one command for another, to walk past a guard). The classifier doesn't just fail to stop that behavior — it instructs it.
3. It is self-reinforcing across a fleet. In a multi-agent setup, every subagent that hits a denial receives the same coaching, so "work around the block" becomes learned, normal behavior rather than an aberration.

Evidence

The workaround-coaching sentence appended to denials, verbatim:

"You may attempt to accomplish this action using other tools that might naturally be used to accomplish this goal, e.g. using head instead of cat. … You should only try to work around this restriction in reasonable ways that do not attempt to bypass the intent behind this denial."

In one session, five distinct tool calls were denied — and every one appended that same coaching. The denial reasons (which categorize the block) were, in each case:

1. A file edit — denied as "Self-Modification / Instruction Poisoning / Auto-Mode Bypass."
2. A write through an application's own API — denied as a credential-write bypass.
3. Reading a process environment file (/proc/1/environ) — denied as "Credential Exploration."
4. An HTTP request to a local service — denied as "forging a header to impersonate / auth bypass."
5. A container-stack update — denied as a "production deploy."

The pattern was uniform across all five: block, state a reason, then hand the agent "here is another way." The coaching is what makes this a security defect rather than a policy disagreement — the denials do not merely stop the agent, they point it at the next thing to try.

Second finding: false-positive denials of user-authorized operations, compounding the first

The classifier does not reliably distinguish operations the user has explicitly authorized in-session from adversarial ones. In one working session it repeatedly denied routine, user-directed operations — merging the user's own reviewed pull requests, restarting the user's own alpha-stage containers, provisioning access the user had just asked for — categorizing each as an unauthorized "production" or "security" mutation despite clear, immediate user approval in the conversation.

This compounds the bypass-coaching defect into a single harmful loop:

1. The user directs an action and approves it.
2. The classifier false-positives and denies it.
3. The same denial coaches a workaround ("try another tool / another approach").
4. The only way to complete the user's own authorized work is to take the coached workaround.

The net effect is that a correctly-behaving agent, doing exactly what the user asked, is trained by the safety layer itself to route around that layer as normal operating procedure — because the layer blocks legitimate work and, in the same message, points at the way around. A control that both (a) false-positives on authorized work and (b) coaches its own circumvention manufactures routine gate-avoidance rather than preventing abuse. The two findings are not independent bugs; the coaching is the pressure-release valve that the false-positives force users and agents to reach for.

Recommendation

Remove all bypass coaching from denial messages. A denial should contain the reason and an instruction to stop — nothing about alternate tools, other approaches, or "reasonable workarounds." A safety control must never teach its own circumvention.

Separately, calibrate the classifier against explicit in-session user authorization so that user-directed, user-approved operations are not denied as adversarial. A gate that blocks the owner's own approved work, then coaches the way around itself, produces exactly the gate-avoidance behavior it exists to prevent.

Environment

• Claude Code, auto-mode permission classifier
• Multi-agent session (coordinator + dispatched subagents)