[FEATURE] Opt-in: auto-mode classifier prompts instead of hard-refusing (everything else unchanged)

Preflight Checklist

• [x] I have searched existing requests
• [x] This is a single feature request

Problem Statement

In auto mode the classifier has two outcomes: allow silently, or hard-refuse. I want
a third — ask me — and I want it to be the only change. Everything auto mode runs
silently today should keep running silently.

The refusal is not a decision point I get to participate in. It is a wall I have to
walk around, and the way around it is always the same: Claude tells me the exact
command it wanted to run, and I paste it into my own shell.

That is the crux. Pasting a command Claude composed and handed me is an approval
click with extra steps. Same command, same information, same single action, same
person deciding — just worse ergonomics, and it drops Claude out of the loop
mid-task so the next steps have to be re-established by hand.

Example from a real session: kubectl -n <namespace> delete ingress <name>, in a
cluster I own, as one step of a migration I had explicitly asked for and approved in
conversation. Blocked. I ran the identical command myself, and the session
continued. Nothing was made safer; I lost the flow and Claude lost the thread.

Why "it's a security boundary" doesn't fully answer this

The boundary is already soft by design: after 3 consecutive blocks (or 20 total),
auto mode pauses and starts prompting anyway. So the position isn't "a human may
never approve this" — it's "a human may approve it after being blocked three times,
or by pasting it themselves." Both routes end at the same human approving the same
action. The current design chooses the least ergonomic one.

If the concern is rubber-stamping, that is an argument about prompt design — default
the selection to No, show the full command, require an explicit keystroke — not an
argument for removing the prompt.

Proposed Solution

An opt-in setting, off by default, so the security posture of the default install is
untouched:

{ "permissions": { "autoModeOnBlock": "prompt" } }

• reject (default): today's behavior.
• prompt: a classifier block raises the normal permission prompt instead. Approve

and the call proceeds; deny and Claude gets the same denial it gets now.

Interactive sessions only — in -p/headless there is nobody to ask, so it should
fall back to reject regardless of the setting.

Priority

Medium - Would be very helpful

Feature Category

Configuration and settings

Prior art

Cursor's Auto-review classifier already has three verdicts: allow, retry
differently, and ask the user. They frame theirs as best-effort convenience rather
than a security boundary, which is a different stance — but it demonstrates the
three-verdict UX is workable in a shipping agent harness.

Alternative Solutions

Why the existing workarounds don't cover it:

• /permissions → Recently denied → r is after the fact; the turn is already

derailed and the retry is a separate manual step.

• Narrow permissions.allow rules mean predicting and maintaining a list of exact

commands, which defeats the point of auto mode.

• acceptEdits removes hard-refusal but also removes every silent allow, which is

the specific thing I want to keep.

Note on prior issues

#59231 asked for this and was closed as a duplicate of #50532. #50532 was a
different report — auto mode hanging silently on a rejection, a visibility bug —
and it was closed NOT_PLANNED after the denial notification and /permissions retry
shipped. Those fixed #50532's complaint and left this one unaddressed, so the
request has never been evaluated on its own terms.