[FEATURE] Auto-mode classifier: prompt for approval on high-risk classifications instead of hard-refusing

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

When the auto-mode permission classifier identifies a tool call as high-risk (writes to shared infrastructure, production-adjacent operations, etc.), it currently hard-refuses the call and asks the agent to escalate to the user via plain text. The denial reads:

Permission for this action was denied by the Claude Code auto mode classifier. Reason: \<…\>. If you believe this capability is essential to complete the user's request, STOP and explain to the user what you were trying to do and why you need this permission. Let the user decide how to proceed.

The agent then has to:

1. Stop mid-task.
2. Explain what it was trying to do and why.
3. Tell the user how to grant the permission (edit ~/.claude/settings.json, or re-run with the ! prefix).
4. Wait for the user to either edit settings, re-prompt with more context, or run the command themselves.

Because the classifier is stateless and can't see the conversation, this happens even when the user has already explicitly authorized the action in chat — sometimes multiple times in a row. The agent reads as "refusing to do work the user clearly authorized," which is a poor experience and degrades trust in the agent's competence even though the agent has no way to bypass the block.

Proposed Solution

When the classifier flags an action as high-risk, instead of hard-refusing, surface a non-auto-mode-style approval prompt inline:

The agent wants to run: aws ssm send-command --instance-ids i-XXX …
Reason classifier flagged it: write to shared infrastructure (AWS dev EC2 via SSM)
[a] Approve once   [s] Approve and remember for this session   [d] Deny

The user keys a / s / d and the agent continues immediately. No context-switch, no settings edit, no !-prefix workaround.

This preserves the safety intent (human in the loop for risky operations) while removing the multi-turn friction. The prompt UX already exists in non-auto mode — this is a consistent extension, not a new pattern.

Alternative Solutions

1. Pass conversational-authorization signals to the classifier. Let the agent supply "the user explicitly authorized this in turn N" as a hint, and have the classifier weigh it. Risk: trivially spoofed by an agent that's been jail-broken or that misreads conversation; not robust on its own.
2. Stateful classifier with cross-turn memory. Persist prior approvals so the classifier sees "the user already said yes to this action class." Adds complexity (what is "the same action class"?) and is harder to audit.
3. Better settings.json discoverability. Surface a copy-pasteable permission-rule snippet in the denial message so the user can add the rule in 5 seconds. Reduces friction but still requires the user to context-switch to a settings file mid-task — and many users won't want a permanent rule for a one-time action.
4. Status quo: hard-refuse + agent explains. What we have today. Works but produces the user-frustration failure mode described above.

The inline-prompt option dominates the alternatives on UX while preserving the same safety property as (4).

Priority

Medium - Would be very helpful

Feature Category

CLI commands and flags

Use Case Example

A user, working with an agent on a feature branch, asked it to run a dev-environment simulation script against a real EC2 instance via SSM. The script forges a webhook to test an email-dispatch code path. Authorization was explicit ("Call the command in dev environment of AWS").

The classifier blocked:

• aws ssm describe-instance-information (read-only, just to confirm SSM connectivity)
• aws ssm send-command (the actual call)

The agent had to write a multi-paragraph explanation, suggest editing ~/.claude/settings.json to add Bash(aws ssm send-command:*) and Bash(aws ssm get-command-invocation:*), and offer the !-prefix workaround. The user — who had already authorized the action twice — responded with a frustrated escalation. After the user manually exited auto mode, the same command ran with no issue.

An inline approval prompt would have collapsed that 5-turn exchange into a single keystroke.

Additional Context

• Hard-refuse can and should remain available for truly bright-line cases (production deletes, destructive ops where even an approval prompt is undesirable). The proposal is to make "prompt-and-confirm" the default for ambiguous-but-likely-fine classifications, with "hard-refuse" reserved for clearly dangerous ones.
• "Approve and remember for this session" should persist within the current Claude Code session only — not across sessions — mirroring how other tools handle per-action consent without leaking elevated trust to future invocations.
• The prompt should display the classifier's stated reason so the user can make an informed decision (the current denial does this well — keep that part).
• If implemented, the existing auto-mode-refusal denial message can be retired entirely, simplifying the agent's prompt as well.