Auto-mode classifier blocks user-authorized deploys and compounds denials within a session
Status Open
Maintainer reply None cached
Workaround ✓ Mentioned in description ↑
Activity 2 comments · opened Sep 4, 2026
Environment: Claude Code CLI on a Raspberry Pi (Linux aarch64), auto (permission) mode, 2026-09-03.
What happened, in order, in one session:
- While investigating a bug, the agent attempted a read-only query against a production SQLite database over SSH. Denied by the auto-mode classifier. Defensible.
- Later, after the fix was built, reviewed, tested (975 tests passing) and an encrypted backup was taken, the agent ran the project's own deploy script. Denied. The identical script had run in auto mode two days earlier, and ran again in auto mode from a fresh session minutes later with no objection.
- I explicitly told the agent to add a Bash permission allow rule for the deploy script, exactly as the denial message suggests. Denied.
- The agent then tried only to read
~/.claude/settings.jsonto show me the current permissions block. Denied.
Problems:
- The denial text says "the user can add a Bash permission rule to their settings", but the classifier then blocks the agent from adding that rule even when the user asks for it in plain words.
- Denials appear to compound on conversation history: one early refusal makes an unrelated, fully authorized deploy fail later in the same session. The workaround is to open a new session and run the same command, which defeats the purpose of the check.
- Explicit owner authorization in chat has no effect on the classifier.
Requests:
- Let an explicit user instruction in the same turn clear a classifier block.
- Never block reading or editing the user's own settings file.
- Stop weighting earlier denials so heavily that a clean, backed-up deploy of the user's own app is refused.
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗