[FEATURE] Permission prompts: never use a number for "No"; treat stray digits as "Yes" fallback

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

Today the claude-code prompt interaction is creating friction for the user. @bcherny Boris, could you please have a brief look, so this does not get auto-closed?

Permission prompts encode "No" as a numbered option. In 3-option prompts, 2 means "Yes, always". In 2-option prompts, 2 means "No". Users build muscle memory for 2 = Yes, always and then silently reject
actions when the prompt happens to be binary. The cost of a wrong keystroke is asymmetric — a missed approval is interruptible; an accidental rejection often destroys in-flight work.

Prior issues (#40500, #46781, #47094, #47201) framed this as a consistency problem and proposed making numbered options stable across prompt shapes. All four were closed by the stale bot with no maintainer
reply. IMPORTANT: this issue is different — "no" should be using "n" or "0" as the key — never numbers >1.

Proposed Solution

1. "No" is never a number > 1. Always the literal letter n (or 0 if a digit is preferred), in every prompt shape.
2. y is always a synonym for 1 (Yes), in every prompt shape — symmetric with n.
3. Binary prompts have options 1/y (Yes) and n/0 (No). There is no 2.
4. Stray-digit fallback: in a binary prompt, if the user types 2, 3, … (a digit not corresponding to any listed option), treat it as 1/y (Yes). Rationale: such a digit is overwhelmingly

carried-over muscle memory for "Yes, always". Mapping it to No is the failure mode this issue is filed about; mapping it to Yes fails safe — the action proceeds and is interruptible, instead of being silently
discarded.

1. The literal n always means No, in every prompt shape. Esc / Ctrl-C still cancel.

Alternative Solutions

• Just being more careful with keystrokes — doesn't scale across hundreds of prompts per long session.
• --dangerously-skip-permissions to bypass prompts entirely — too broad; removes the safety net the prompts exist for.
• Arrow-key selection of options (proposed in #35091, closed not_planned) — would also fix the problem but is a larger UI change. The n/y letter-binding proposed here is strictly additive and

backward-compatible with the current numeric input.

Priority

High - Significant impact on productivity

Feature Category

Interactive mode (TUI)

Use Case Example

Concrete scenario:

1. Claude is mid-task, about to edit a config file. A binary permission prompt appears: "1) Yes 2) No".
2. I type 2 reflexively — muscle memory from the more common 3-option prompt where 2 = "Yes, always".
3. The action is silently denied. Claude logs "tool denied" and continues to the next step without applying the change.
4. Several minutes later I notice the file wasn't edited. I either re-prompt Claude (losing context) or have to manually undo whatever it did downstream.

With the proposed change: typing 2 in a binary prompt would map to 1 (Yes), the action proceeds, and the work isn't silently lost. To actually decline, I'd type n — which has no muscle-memory collision
with the 3-option prompt's Yes, always.

Additional Context

Why this matters

Asymmetric failure cost: silent rejection of an intended action is much harder to recover from than a re-confirmation of an unintended action. Long agent runs cascade — a rejection mid-task often loses several
minutes of work plus context. Multiple bug reports already exist (#40500, #46781, #47094, #47201) showing this is a consistent footgun, not an edge case.

Prior context

• #40500 (consistency request, stale-bot-closed Apr 29)
• #47094, #46781, #47201 (duplicates of #40500, all bot-closed)

cc — past reporters of related issues

@RichGibson @jertsdev @bradfeld @dgunderson — you each filed one of the related issues (#40500, #46781, #47094, #47201) which got auto-closed without engagement. Please have a look and 👍 if this framing
resonates, so it doesn't share the same fate.