Bug: AskUserQuestion treats Escape as "decline tool use" — destroys answers for vi/vim users

Summary

The AskUserQuestion picker interprets the Escape key as "user declined the tool use," which immediately discards any text the user has typed into the free-text "Other" field. For users with a vi/vim editing workflow, Escape is a near-constant reflex (it returns to normal mode before any navigation), which silently destroys long, detailed answers with no recovery path and no warning.

Environment

• Tool affected: AskUserQuestion (the picker UI shown when the assistant uses this tool)
• Editor habit: vi/vim (or anything that uses Escape for mode switching or readline vi mode in the shell — set -o vi, bindkey -v in zsh, editing-mode vi in .inputrc, etc.)
• Platform: macOS (Darwin), but the keybinding behavior is not platform-specific
• Claude Code surface: terminal CLI

Reproduction

1. Configure the shell or readline for vi-mode (or simply be a vim/vi user whose muscle memory hits Escape constantly).
2. The assistant uses AskUserQuestion with options that include a free-text "Other" field.
3. Select "Other" and begin typing a long answer.
4. At any point during composition, press Escape — to leave insert mode, to navigate, to cancel a completion, etc.
5. Expected: Escape behaves like vi (mode switch, focus stays on the field, text preserved), or at minimum requires a confirmation ("Cancel and lose your answer? y/N") before discarding text.
6. Actual: The picker immediately treats the keypress as a rejection of the tool use. Every character typed into the "Other" field is discarded with no recovery, no draft, no undo. The assistant receives "user rejected the tool" and proceeds as if no answer was given.

Impact

• Lost work. Users routinely lose multi-paragraph answers representing 30+ seconds to several minutes of careful composition.
• Trust degradation. Users learn to avoid AskUserQuestion-driven workflows entirely (brainstorming skills, design questions, multi-step configuration prompts) because they cannot safely answer them.
• Disproportionate impact on power users. vi/vim users — heavily represented in the developer audience Claude Code targets — are exactly the cohort hit by this. The user filing this report had to ask the assistant to permanently never use AskUserQuestion and instead ask questions in plain text in the response body.
• No workaround in the user's hands. The user cannot disable the picker, cannot remap Escape, and cannot recover the text after it's destroyed.

Suggested fixes (any one of these would resolve it)

1. Don't treat Escape as decline when the free-text field is non-empty. Require a deliberate cancel action (Ctrl-C, a "Cancel" button, or typing :q in vi-mode picker) when there's unsaved text.
2. Confirm before discarding. If Escape would discard a non-empty buffer, prompt "Cancel and lose your answer? y/N" first.
3. Preserve the draft on cancel. Even if Escape cancels the tool use, write the typed text to a recoverable buffer/log so the assistant or user can recover it on the next turn.
4. Detect vi/readline-vi mode (e.g., $EDITOR=vi*, set -o vi, readline mode in INPUTRC) and switch the picker to a vi-aware keymap where Escape is a no-op (or a mode switch within the field).
5. Make Escape behavior configurable in ~/.claude/settings.json so vi users can opt out of "Escape = cancel."

Of these, (1) and (2) are the safest broad fixes; (4) is the most ergonomic for the affected cohort.

User note

This was filed at the user's explicit request after losing a detailed answer mid-brainstorm. Quote: "How much time has been wasted due to AskUserQuestion not being able to handle vi editor."

The assistant has now permanently disabled use of AskUserQuestion for this user via a memory entry and will only ask questions in plain text in the response body.