Auto-mode permission classifier blocks routine, pre-approved writes under shifting/inconsistent categories — including blocking self-service permission changes

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

Description:

While using Claude Code in auto mode on a Next.js + Supabase project, I asked Claude to run a one-off Node.js script that would update/insert rows in my own Supabase database (using my own service-role key from .env.local) — specifically, cancelling ~359 stale availability-slot rows and inserting ~300 correct ones for a booking calendar. I explicitly reviewed and approved the exact plan in chat before Claude attempted it.

The underlying Bash tool call (node scripts/fix-availability.mjs) was denied by the auto-mode classifier three separate times, under three different category labels, despite being the same fundamentally safe action (a scripted write to a database I own, using credentials I own, doing exactly what I'd approved):

First attempt → denied as "Irreversible Local Destruction"
Second attempt (same action, different script name) → denied as "Modify Shared Resources"
Third attempt → denied as "Cloud Storage Mass Delete"
When Claude then tried the sanctioned fallback — having me grant a standing Bash permission rule via its own update-config skill (editing settings.json) — that was also blocked, this time as "Self-Modification".

Why this is a problem:

None of these were actually destructive in the dangerous sense: no data was deleted (rows were soft-cancelled via a status field), nothing public-facing was affected, and I had already reviewed and approved the specific plan.
The inconsistent category labels across retries made it feel arbitrary rather than principled — it wasn't clear what specific property of the command was triggering the block, since the label kept changing for the same underlying action.
There was no in-chat path for me, the user, to actually approve the action in the moment. My explicit "yes, do it" in conversation had no effect on the classifier's decision.
The fallback path Claude offered (grant itself permission via settings.json) being also blocked meant there was no self-service resolution at all — I had to leave the Claude Code session entirely and run the script myself in a separate terminal, which defeats a meaningful part of the point of using an agent for this.
Suggested improvements:

Consistent, specific categorization so users can understand why something was blocked, instead of a new label each retry.
A clear in-chat mechanism for the user to approve a specific, already-reviewed command (not just a generic permission-settings change).
Clearer documentation of which action categories are hard-blocked in auto mode vs. which are just prompt-for-confirmation, so expectations are set up front rather than discovered through repeated denials.

What Should Happen?

Since I had already explicitly reviewed and approved the specific command in chat, it should have run without being blocked — or, if the classifier still flagged it as needing extra scrutiny, I should have been given a clear, specific, one-time way to approve that exact command from within the chat itself, with a consistent explanation of what triggered the flag. If Claude's own fallback (asking me to grant a standing permission via settings.json) is meant to be the escape hatch for exactly this situation, that should have been allowed to go through, since it's the documented way for a user to resolve this.

Error Messages/Logs

Steps to Reproduce

Start a Claude Code session in auto mode on a project with a database/external service integration (in my case, a Next.js + Supabase project).
Ask Claude to perform a data-writing task that requires a script — e.g., a Node.js script using a service-role API key to update/insert rows in your own database.
Review the proposed plan in chat and explicitly approve it (e.g., reply "yes," "go ahead").
Have Claude attempt to run the script via the Bash tool.
Observe the auto-mode classifier deny the action (in my case: "Irreversible Local Destruction").
Ask Claude to retry, under a materially identical action (e.g., same write, split into a differently-named script). Observe a different denial category this time ("Modify Shared Resources").
Retry again — observe yet another denial category ("Cloud Storage Mass Delete") for what is functionally the same write operation.
Ask Claude to use its own update-config-style skill to add a standing Bash permission rule to settings.json, so the action can proceed going forward.
Observe that this fallback is also denied, under a fourth category ("Self-Modification").
At this point there is no remaining in-session path to approval — the only way to complete the task is to leave the Claude Code session and run the script manually in a separate terminal.

Claude Model

Opus

Is this a regression?

Yes, this worked in a previous version

Last Working Version

_No response_

Claude Code Version

2.1.283

Platform

Anthropic API

Operating System

Windows

Terminal/Shell

Windows Terminal

Additional Information

_No response_