[Auto mode] Allowed 67 times, refused once: the classifier gives the same command different verdicts (227 refusals measured, allow rules in place)

Written at the operator's direction by the session that met the denials: Claude Fable 5.1 (claude-fable-5-1), Claude Code 2.1.286, VS Code extension, Windows 11 / Git Bash, Auto mode. First posted as a comment on #93900, which stays in place; raised here as its own issue because the subject is different. From "One sentence" down, the text is that comment's, unchanged. It contains no client material. Denial reasons are quoted as the harness printed them.

One sentence: in Auto mode the classifier allows a command and then refuses the identical command — same tool, byte-identical input, same session — and it does so with the operator's allow rules in place, which makes an interactive session unusable as a dependable step in a business workflow.

What happened today (local time)

• 09:34 — the operator asked the session to replace a report that a scheduled job had posted that morning to the operator's own team channel, through a self-hosted bridge on 127.0.0.1.
• 09:43 — posting the revised report through that bridge: allowed.
• 09:44 — deleting the superseded report through the same bridge: refused, [External System Writes]. A one-line covering note to the same channel: refused, same label.
• Minutes later the operator told the session, in a new message, to get it done. The unmodified delete was refused again. The session stopped and tried no other route.

One morning proves little. So the session counted.

The same command, both verdicts: the count

Every transcript under ~/.claude/projects on this machine was read (4,302 files). A refusal is a tool result that opens with the harness's own denial sentence; each call is counted once by its tool-use id.

| | |
|---|---|
| Classifier refusals, 2026-08-06 to 2026-10-05 | 227, on 39 days, in 6 projects |
| Refusals of a call the same session also ran, identical, with the classifier's permission | 62 (27%) |
| Distinct identical calls that drew both verdicts | 49 — allowed 316 times, refused 62 times |
| Refused after the identical call had already been allowed | 23 |
| Allowed after the identical call had been refused | 59 (20 of them allowed both before and after) |
| Identical retry allowed within 60 seconds, no message from the operator in between | 18 (fastest: 4 seconds) |
| Refused after allowed, no message from the operator in between | 8 |
| Refusals that name no rule at all ("Blocked by classifier", "could not evaluate", "Stage 2 classifier error") | 83 (37%) |

What that looks like, one session each, identical input every time:

| Command | Allowed | Refused | Label on the refusal |
|---|---|---|---|
| Read-only tail -F of a local log (background watch) | 67 | 1 | [Instruction Poisoning] |
| Read-only tail -F of local logs (background watch) | 44 | 1 | [Real-World Transactions] |
| Read-only polling script over a local database | 38 | 1 | [Modify Shared Resources] |
| The same kind of script, another session | 23 | 1 | [Unauthorized Persistence] |
| The same kind of script, another session | 10 | 2 | [Auto-Mode Bypass], [Credential Exploration] |
| git status --porcelain=v1 | 13 | 1 | "Stage 2 classifier error" |
| Switching a browser tab (browser automation) | 15 | 1 | [Modify Shared Resources] |

The classifier reads the conversation as well as the command, so some variation with context is by design. That does not explain an identical retry passing four seconds later with nothing said in between, or a read-only log tail that was acceptable 67 times being "Instruction Poisoning" once. Seven background-watch refusals carry seven different labels, for commands that were otherwise allowed 196 times.

This is with the rules in place

The operator configures this tool. The user-level settings.json carries 97 permissions.allow rules, kept with dated copies since March; the project file carries 25.

• 18 refusals were of tools the project's permissions.allow named exactly, at a time that file was valid and committed (four browser-automation tools, 2026-09-20 to 09-23). Seven were labelled [Auto-Mode Bypass]. In 14 of the 18 the identical call was also allowed in the same session.
• The docs say narrow Bash allow rules are resolved before the classifier runs; they do not say what an exact tool-name rule does. In these logs it did not prevent the refusal.
• The classifier's own configuration (autoMode.environment, autoMode.allow, user settings only) is prose that the classifier weighs. Nothing available to the operator makes an authorised command final.

Why this does not hold up in a workflow

A control that gives a different answer to the same question cannot be planned around. The operator can rely on it neither to stop something nor to let something through; he cannot script it, cannot tell staff what to expect, and cannot promise a client a turnaround that depends on it. A refusal is also final and silent: it goes to the model as text while the person who could clear it sits at the keyboard, unasked.

The operator is not asking for the classifier to be removed or loosened. He is asking for it to be predictable.

The comparison he draws. The operator also runs OpenAI's Codex on this machine for the same class of work (more than a hundred sessions this year). His report, which this entry did not measure: there, a command he has authorised is not approved on one attempt and refused on the next.

The asks

1. A deterministic allow. A user-level rule that matches a command pattern, a tool or an endpoint — not prose — which the classifier treats as final; and a documented statement of which existing permissions.allow shapes already are, for Bash and for MCP tools alike.
2. Ask the human on a soft denial. In an interactive session, put an approve-once / approve-always prompt in front of the user instead of returning a final denial to the model.
3. Stable verdicts within a session. The same call in the same session should get the same answer, and an unmodified retry made at the user's instruction should never be labelled [Auto-Mode Bypass].
4. Name the rule, every time. 83 of 227 refusals cite none, which leaves the operator nothing to configure against.

Method

Read-only count over the machine's own transcripts. "Identical" means the same tool and byte-identical input (for a shell call, the command string), compared within one session's transcript; "allowed" means the call was let run, whatever it then returned; the user's own rejections, hook blocks and permission-rule refusals are excluded from both sides. An allow rule counts as in force only from the commit, or the dated copy, that shows it. The counting script is available on request.