Confirmation prompts: use 0 for No to prevent accidental cancellation from muscle memory

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 Claude Code asks for confirmation, the option layout varies between prompts:

• Sometimes: 1) Yes 2) Yes, and don't ask again for similar 3) No
• Sometimes: 1) Yes 2) No

Users develop muscle memory for pressing 2 — the "yes to all similar" shortcut, very common in repetitive workflows (file edits, DB operations, batch confirmations). When a 2-option prompt appears instead, pressing 2 out of habit means pressing No — the opposite of the intended action.

The risk is concrete: the keystroke users learn to press fast is the same one that, in a different prompt shape, cancels the operation. I haven't noticed a pattern in which prompts show 2 vs 3 options, which is exactly why a universal rule is the right fix rather than per-prompt tuning.

Proposed Solution

Use 0 for No across all confirmation prompts, regardless of how many other options are present.

• 0 is physically far from 1 and 2 on the number row, so muscle-memory pressing of 2 cannot land on No even with a finger slip. This mirrors the GUI principle of separating destructive actions from primary ones.
• The rule is universal — it applies to every prompt without needing to classify which ones are "risky". One change, problem solved everywhere.
• 1 (Yes) and 2 (Yes to all) remain adjacent and fast, preserving the existing speed for the common path.

Ideal interaction with three options:

Do you want to proceed with this operation?
1) Yes
2) Yes, and don't ask again for similar operations
0) No

Ideal interaction with two options:

Do you want to proceed?
1) Yes
0) No

An alternative would be reserving 3 always for No (leaving position 2 empty in 2-option prompts), but 0 is preferable because it adds physical separation on the keyboard, not just logical consistency in the layout.

Alternative Solutions

• Reserve 3 always for No, leaving position 2 empty when there's no "yes to all" option. This gives positional consistency but keeps No adjacent to the muscle-memory key, so the protection is weaker than 0.
• Require an explicit non-numeric keystroke for No (e.g. n or Esc). Effective but breaks the all-numeric flow users are used to.
• Visual differentiator (color, prefix character) when the layout changes between 2 and 3 options. Helps but relies on the user actually looking before pressing — exactly what muscle memory bypasses.

Currently I work around this by consciously slowing down on every confirmation prompt, which defeats the purpose of having a "yes to all" shortcut in the first place.

Priority

Critical - Blocking my work

Feature Category

CLI commands and flags

Use Case Example

Example scenario:

1. I'm running a session where Claude Code is making many similar edits across a codebase (e.g. refactoring imports across dozens of files).
2. For the first edit, I press 2 to approve and skip future similar confirmations — fast, fluid.
3. Later in the same session, Claude Code asks a different kind of confirmation that only has two options: 1) Yes 2) No.
4. My finger, primed by the previous rhythm, hits 2 — and I've just cancelled an operation I actually wanted to approve.
5. Depending on the operation, this can mean re-running expensive steps, losing context, or leaving the workspace in an inconsistent state if the cancelled action was part of a sequence.

With 0 reserved for No, step 4 cannot happen — pressing 2 on a 2-option prompt would simply do nothing or re-prompt, never cancel.

Additional Context

This is a classic positional consistency issue in interactive CLIs: the same keystroke should always carry the same semantics, especially for destructive actions. The current behavior violates this because position 2 means "fast-path approve" in one prompt shape and "cancel" in another.

The fix is small in implementation cost but high in safety value, because it eliminates an entire class of slip-errors without requiring users to change their behavior.

(Attached: two screenshots showing a real 2-option and 3-option prompt from Claude Code, illustrating the inconsistency.)