Permission prompt auto-accepts when pressing Delete/Backspace while editing the "additional details" input

Description

When a permission/confirmation prompt offers multiple options (e.g., Yes / Yes, and tell Claude what to do differently / No) and I select the option that opens a free-text input for additional details, a single Delete or Backspace keypress during in-place editing causes the entire message to vanish and the prompt to confirm without my explicit Enter.

It is not clear from the UI which option the prompt ends up selecting (the previously-Tabbed option with my partially-typed-then-deleted message, the previously-Tabbed option with an empty message, "No", or something else). The action gated by the prompt proceeds anyway, leaving the user uncertain about what they just authorized.

Steps to reproduce

1. Trigger a permission prompt that offers a "Yes, and ..." style option (e.g., one that lets you add context before approving).
2. Press Tab to focus the option that opens the text input.
3. Type a few words into the text field.
4. Press Left Arrow one or more times to move the cursor backward inside your typed text.
5. Press Delete (forward delete) or Backspace to remove a character or word.

Expected: the character/word at the cursor is removed; the prompt remains open awaiting Enter; my message is preserved.

Actual: the entire typed message disappears and the prompt confirms/dismisses without an explicit Enter keystroke. The downstream action proceeds.

Why this is concerning

This couples a routine text-editing keystroke with a dialog-accept action. Because Claude Code permission prompts gate things like file writes, shell commands, and external API calls, this can cause the user to authorize an action they were still in the middle of refining — or to authorize an action whose final form (which option, what message) they cannot determine after the fact. It removes the explicit confirmation step that the prompt exists to provide.

The risk is heightened by the fact that the actual selected option is not disclosed after the auto-accept, so the user doesn't know whether to investigate possible damage.

Environment

• OS: macOS (Darwin 25.5.0)
• Shell: zsh
• Claude Code version: _2.1.141 (Claude Code)_
• Terminal app: iTerm2

Possible hypothesis (for triage)

The arrow-key navigation may move keyboard focus away from the text input back to the option chips, after which Delete/Backspace is interpreted by the chip selector as a confirm/dismiss command rather than as a text-editing action in the input. Alternatively, Delete on a near-empty buffer may be hitting a wrong code path that calls the prompt's accept handler.

Additional notes

• Reproducibility: appears consistent for me.
• Severity: in my view this should be considered high — it bypasses a safety affordance that the rest of the product relies on.