AskUserQuestion: Escape destroys typed answers (breaks vi/vim users)

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).

1. The assistant uses AskUserQuestion with options that include a

free-text "Other" field.

1. Select "Other" and begin typing a long answer.
2. At any point during composition, press Escape — to leave insert mode,

to navigate, to cancel a completion, etc.

1. 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.

1. 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.

1. Confirm before discarding. If Escape would discard a non-empty

buffer, prompt "Cancel and lose your answer? y/N" first.

1. 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.

1. 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).

1. 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.