Auto-mode permission classifier repeatedly denies user-authorized actions; cannot be unblocked in-session

Summary

In defaultMode: "auto", the permission classifier repeatedly denies the same low-risk action (e.g. Bash(sqlite3 ... UPDATE/DELETE/INSERT)) even after the user has explicitly authorized it, and there is no in-session way for the agent to clear the friction. This makes a routine multi-write workflow require the user to re-authorize many times, defeating auto mode.

Environment

• Claude Code CLI, permissions.defaultMode: "auto", skipAutoPermissionPrompt: true
• Model: Claude Opus 4.7

Steps to reproduce

1. Auto mode. Ask the agent to perform several related write commands (here: sqlite3 writes to a local app DB).
2. Agent runs a write. Classifier denies it, citing a prior unrelated user message as an inferred "boundary."
3. User explicitly authorizes ("I authorise you to do these").
4. Agent re-runs — sometimes allowed once, but subsequent similar writes are denied again.
5. User grants approval via the AskUserQuestion tool. Classifier still denies, because it does not appear to see AskUserQuestion answers as authorization.
6. Agent attempts the documented remedy — adding permissions.allow: ["Bash(sqlite3:*)"] to ~/.claude/settings.json. This is also denied as "self-modification of permission config."

Net effect: every denial message says "the user can add a Bash permission rule to their settings," but the agent is blocked from doing that on the user's behalf even when explicitly told to, so the only escape hatches are the user manually editing settings or running every command themselves via the ! prefix.

Expected behavior

• An explicit user authorization in conversation (or via AskUserQuestion) should satisfy the classifier for the authorized action(s), at least for the remainder of the session / for that command class.
• When the user explicitly instructs the agent to stop asking and proceed, there should be a sanctioned path to persist that (e.g. allow the agent to add a scoped permissions.allow rule, or honor a session-scoped grant).

Actual behavior

• AskUserQuestion approvals are not treated as authorization by the classifier.
• Explicit textual authorization is honored inconsistently (one command, not the class).
• The suggested remedy (add a permission rule) cannot be performed by the agent — including when the user explicitly requests it — creating a loop with no in-session resolution.

Impact

Routine authorized multi-step work in auto mode becomes high-friction: the user is forced to repeatedly re-grant or hand-run commands. The remediation advice in the denial text is not actionable by the agent it is shown to.

Suggested fixes

• Treat AskUserQuestion-confirmed actions as authorized.
• Support a session-scoped or class-scoped "user authorized this" grant after explicit confirmation.
• Allow the agent to write a scoped permissions.allow entry when the user explicitly instructs it, or surface a one-click "always allow this" affordance.