[BUG] A fast double-Esc destroys the entire prompt with no recovery, and cannot be disabled

Problem

A fast Esc Esc silently empties the entire prompt buffer. The text is not
recoverable — not by Ctrl+Y, not from prompt history — and the behavior
cannot be disabled.

The first Esc displays an Esc again to clear hint, so this is nominally
guarded. The guard does not work for the population most likely to trigger it:
Esc Esc is a single over-learned gesture for vim users, the reflexive
double-tap to guarantee NORMAL mode. It is not two decisions the hint can sit
between; both keypresses are already in flight. Claude Code ships a vim mode, so
it actively recruits exactly these users.

Measured on 2.1.234

Driven through a pty with a pyte screen model, so these are real rendered
frames, not inferred:

Fast double-Esc — destroys everything, unrecoverable

typed 3 lines            ❯ AAALINEONE
                           BBBLINETWO
                           CCCLINETHREE
after fast Esc Esc       ❯ Try "how do I log an error?"     <- placeholder: buffer empty
after Ctrl+Y             ❯ Try "how do I log an error?"     <- nothing comes back

Ctrl+U on the same buffer — correct, and fully recoverable

typed 3 lines            ❯ AAALINEONE
                           BBBLINETWO
                           CCCLINETHREE
after Ctrl+U             ❯ AAALINEONE                        <- kills the current line only
                           BBBLINETWO
after Ctrl+Y             ❯ AAALINEONE                        <- yanked straight back
                           BBBLINETWO
                           CCCLINETHREE

Ctrl+U is the model to copy. It is scoped, it pushes to the kill ring, and
Ctrl+Y restores it. The double-Esc path destroys strictly more text and offers
strictly less recovery.

There is no user-side workaround

~/.claude/keybindings.json cannot reach this. Verified on 2.1.234:

{ "bindings": [ { "context": "Chat", "bindings": { "escape": null } } ] }

The buffer still empties on a fast double-Esc. Unbinding escape does not
disable the clear, so a user who diagnoses this correctly still has no remedy —
and would lose turn-interrupt in exchange for nothing.

Severity scales with the value of the input

This costs the most on long, carefully composed prompts, which are exactly the
ones worth writing. Losing one mid-sentence is not a papercut; it is the whole
draft, with no undo.

Requested fix, in order of preference

1. Make the clear recoverable — push the cleared buffer to the same kill ring

Ctrl+U already uses, so Ctrl+Y restores it. This is the smallest change and
reuses existing plumbing.

1. Make it disableable — have {"escape": null} (or a dedicated action such as

chat:clearInput on the double-Esc path) actually suppress it.

1. Make the guard real — require a deliberate gap between the two presses, or

require confirmation when the buffer is over some size, so a reflexive
double-tap cannot destroy a long draft.

Environment

• Claude Code 2.1.234, Linux (Ubuntu 26, kernel 7.0)
• Terminal: Ptyxis (VTE 0.84), TERM=xterm-256color, Wayland
• Reproduced from a clean session; not vim-mode-specific (vim mode was off)

Reproduction

1. Type a multi-line prompt into the chat input.
2. Press Esc twice in quick succession, as a vim user does by reflex.
3. The entire buffer is gone. Ctrl+Y restores nothing; Up-arrow does not find it.
4. Add {"context": "Chat", "bindings": {"escape": null}} to

~/.claude/keybindings.json and repeat — no change.

Related

• #69181 — Vim mode: pressing Escape in INSERT mode on agent screen clears the

entire prompt. Same destruction, reached by a vim-mode-specific path; this
report covers the non-vim-mode default binding and adds the recovery and
non-disableable findings.

• #83528 — No action clears the prompt buffer without a side effect. Argues from

the opposite direction (no safe way to clear on purpose); together these
describe one gap — clearing is available only in its destructive form.

• #82970 — Mirror input-editor kills to the system clipboard. Related safety-net

request for the kill ring that this path never reaches.