Permission classifier blocks read-only operations the user explicitly pre-approved, and does so non-deterministically

Status Open
Reported on v2.1.220
Maintainer reply None cached
Activity 0 comments · opened Aug 10, 2026

Type: bug

Environment

  • Claude Code version: 2.1.220
  • OS: macOS 26.5.2 (Darwin 25.5.0)
  • Platform: Claude subscription
  • Mode: auto-accept ("auto mode") for long-running unattended sessions

What happened

In auto mode, a classifier blocks operations independently of the configured permissions.allow list. That design is understandable for genuinely risky writes. The friction is that it also blocks read-only operations that the user has explicitly allowed, and it does so inconsistently.

Concretely, in a 26-day window, 16 of 86 audited sessions lost time to this. Representative cases:

  • A read-only remote grep over log files was blocked; the session worked around it with a roughly 30-step browser detour to read the same data.
  • Reading service environment metadata via an official CLI was blocked repeatedly, so it was delegated back to the human — around 20 times in 24 hours by the user's own count.
  • During a live incident, diagnostic reads were blocked, which is the worst possible moment for it.
  • The same command shape passed six times in a row and was then blocked, with no change in the command, the directory, or the settings.

The last point is the important one. If the block were deterministic it would just be a rule to work around. Because it is not, the model cannot distinguish "this is forbidden" from "try again" — which is exactly the retry loop the block is meant to prevent.

There is also no channel for the user to grant an exception. permissions.allow does not reach the classifier, so the only workarounds are (a) hard-coded wrapper scripts with an internal whitelist, which the classifier does not inspect — effectively obscuring the operation rather than authorizing it, or (b) dropping out of auto mode entirely, which defeats unattended runs.

Expected

  1. Determinism, or an explicit statement that it is probabilistic. Identical input in an identical session state should produce an identical decision. If the classifier is inherently probabilistic, the denial message should say so, so callers know whether a retry is meaningful.
  2. An explicit user-grant channel. Something like a settings-level, narrowly scoped classifier.allow (read-only command shapes, specific CLIs, specific hosts) that the user opts into knowingly. Today the only way through is a wrapper script whose contents the classifier never sees, which is strictly worse for safety than an explicit grant.
  3. A denial message that names the matched rule or category, so users can tell a scoped rule from a broad one and adjust.

Repro

Not deterministically reproducible — that is part of the report. Observed shape: in auto mode, with a broad allow rule in permissions.allow covering a remote-execution command, run the same read-only remote command repeatedly. Most invocations pass; some are blocked with a message referencing the auto-mode classifier.

Impact

The largest single lever on diagnostic speed in our usage. Because it is non-deterministic it also erodes the rule we teach the model ("a deterministic block will not change on retry"), which is the rule that prevents retry storms.

View original on GitHub ↗