[FEATURE] Permission dialog: make the digit for "No" stable across the 2-option and 3-option variants (implementation TBD)

Preflight Checklist

• [x] I have searched existing requests
• [x] This is a single feature request (not multiple features)

Prior art, stated up front (please don't auto-dedupe): the underlying complaint has been filed before and every one of those threads is now closed and locked — #7944 (not_planned, stale autoclose), #10126 (not_planned, 60-day inactivity autoclose), #29107 (bot-closed as duplicate of #10126). Two related requests are still open but each covers a different axis: #76551 (standardise on 1=yes/0=no) and #79809 (expose the middle option as a bindable action so digits can be remapped). This issue is filed to hold the one question none of them resolves: should the default digit for the destructive/negative choice be stable across dialog variants, and if so, how? I have deliberately not picked an implementation — see below.

Problem Statement

The permission dialog ships in (at least) two shapes, and the meaning of the 2 key silently changes between them:

Two-option variant

  1. Yes
  2. No, and tell Claude what to do differently (esc)

Three-option variant

  1. Yes
  2. Yes, and don't ask again for <X> in <Y>
  3. No, and tell Claude what to do differently (esc)

So 2 is "cancel" in one dialog and "grant a persistent permission" in the other. The dialogs are visually near-identical, appear in the same screen position, and are answered reflexively dozens of times an hour, so in practice the digit gets pressed from muscle memory before the label is read.

Two distinct failure modes, in opposite directions:

1. Unintended persistent grant. You expect the two-option dialog, press 2 meaning "no", and instead write a standing permission rule. Recoverable via /permissions, but you have to notice it happened first — there is no confirmation and no undo prompt.
2. Unintended denial. The mirror case for users whose habit is 2 = "yes, and don't ask again" — they hit the three-option shape's 2 on a two-option dialog and cancel the action.

Both cohorts genuinely exist: #76551's author reports being trained on 2 = accept-and-don't-ask, which is the exact inverse of my own habit. That matters for the design — see the trade-off notes.

What makes this different from ordinary misclicks is that the number of options is not something the user chooses or predicts. It is decided by the tool, per invocation, based on whether the action is rule-able. From the keyboard's point of view the meaning of 2 is effectively nondeterministic.

Proposed Solution

The ask is the invariant, not a specific patch: the key for the negative/cancel choice should not change meaning based on how many options the dialog happens to render — and, ideally, the highest-consequence choice (a persistent grant) should not sit on the digit adjacent to the reflex key.

I want to be explicit that I am not asking for a particular implementation. Several designs satisfy the invariant with very different costs, and the choice depends on telemetry and installed-base considerations that only maintainers can see. Options I can think of, with what I believe the trade-offs are:

(a) Gap numbering — the two-option variant uses 1 and 3, skipping 2.

  1. Yes
  3. No, and tell Claude what to do differently (esc)

"No" becomes 3 everywhere; "don't ask again" stays on 2 where it exists; a stray 2 in the two-option dialog is a no-op rather than the wrong action. Strictly safer than today and, as far as I can tell, the only option that breaks neither cohort's existing muscle memory. Cost is purely cosmetic — a visibly skipped digit, which some will read as a rendering bug.

(b) Reorder the three-option variant to yes / no / don't-ask-again.

  1. Yes
  2. No, and tell Claude what to do differently (esc)
  3. Yes, and don't ask again for <X> in <Y>

Cleanest mental model, and it moves the least-reversible choice furthest from 1. But it inverts the meaning of 2 for everyone currently trained on 2 = always, i.e. it trades one cohort's errors for the other's during the relearning window. Probably the most disruptive of the three.

(c) Letter mnemonics — y / a / n.
Self-describing, matches git add -p and apt conventions, and immune to option-count changes. Known complications: collision with typing into the prompt box, and with the a/b/c-style multiple-choice dialogs. Could be opt-in via settings rather than default — cf. #80897, which asks for lettered labels generally.

(d) Keybinding-level fix only. Expose the options as bindable actions and let users move them. This is #79809's request. As of v2.1.220 the binary exposes confirm:yes and confirm:no but no action for the middle "don't ask again" option, so it cannot currently be remapped or unbound. This is the smallest shippable change and it lets individuals build (c) themselves — but it leaves the default, which is what most users experience, untouched.

Personally I lean toward (a) as the default, precisely because it is the only one that costs no user any relearning, with (d) shipped alongside it for people who want (c). But I would rather this be settled with maintainers than have the issue read as a demand for one patch — treat the specific mechanism as TBD. If the answer is "we have data showing the current ordering is fine", that is a useful outcome too; the three previously closed threads were all closed by inactivity bots rather than by a decision, so the question has never actually been answered.

Alternative Solutions

• Current workaround: nothing reliable. keybindings.json can rebind confirm:yes/confirm:no, but the digit quick-selects appear to be handled inside the dialog component rather than routed through the keybinding system, and the middle option has no bindable action at all — so the specific collision cannot be defused today.
• Damage control after the fact: /permissions to remove an accidentally-written rule from .claude/settings.local.json. Works, but only if you notice.
• Not viable: "just read the dialog." The whole point of a digit quick-select is that it is answered pre-attentively; a design that is only safe under full attention isn't safe at a few hundred prompts a day.

Priority

Medium - Would be very helpful

Feature Category

Interactive mode (TUI)

Use Case Example

1. Long refactor across a monorepo; Claude is running a mix of read-only git/grep calls and occasional writes, so permission dialogs of both shapes alternate.
2. A dialog appears. I glance at it, recognise the command as safe, and press 2 — my habit for "no, not that one" from the two-option shape.
3. This one happened to be the three-option shape, so instead of cancelling I have just granted a standing rule for that command class in that directory.
4. Nothing marks this as unusual in the transcript. I find out later, from /permissions, that a rule I never intended is in settings.local.json.

The inverse scenario, for the 2-means-accept-all cohort, is the same sequence with the shapes swapped and an unintended cancellation as the outcome.

Additional Context

• Related open issues, different axes: #76551 (proposes 1=yes / 0=no), #79809 (bindable confirm:acceptAlways + remappable digits), #80897 (letters instead of numbers).
• Same family, cross-platform rather than cross-variant: #73325 and #74475 report that 1 means Approve in the terminal CLI but Deny in the Windows desktop app. Whatever invariant gets chosen here should probably hold across surfaces too.
• Previously closed without a decision: #7944, #10126, #29107 (all locked).
• Verified against v2.1.220 (macOS, Homebrew cask): confirm:yes and confirm:no exist as keybinding actions; there is no confirm:acceptAlways or equivalent.