Vim mode: pressing Escape in INSERT mode on agent screen clears the entire prompt

Status Open

Reported on v2.1.179

Maintainer reply ✓ Yes — bcherny

Activity 4 comments · opened Jun 17, 2026

💡 Likely answer: A maintainer (bcherny, collaborator) responded on this thread — see the highlighted reply below.

Description

When vim mode is enabled and you're on the agent screen (accessed via claude agents, left arrow, or Ctrl-Z), typing a prompt and pressing Escape to switch from INSERT to NORMAL mode clears the entire prompt text instead of just switching vim modes.

Steps to reproduce

Enable vim mode in Claude Code settings
Open the agent screen (e.g. press left arrow or Ctrl-Z from the main prompt)
Type any text (e.g. hello world)
Press Escape to switch from INSERT to NORMAL vim mode
The entire prompt is wiped

Expected behavior

Pressing Escape should transition from INSERT to NORMAL vim mode, leaving the typed text intact — the same behavior as on the main prompt screen.

Actual behavior

The entire prompt text is cleared and the view navigates away from the agent screen (back to the main prompt).

Root cause (from binary analysis)

The uc function (inner key handler) contains this logic:

function uc(G$) {
  let F8 = Gp() && G$.name === "escape";
  if ((hH === 0 || F8) && (G$.name === "escape" || G$.name === "backspace" || G$.name === "delete" || G$.ctrl && G$.key === "u"))
    L("prompt"), YH(!1);
  // ...
}

Gp() returns true when on the agent screen. So F8 is true whenever the user presses Escape on the agent screen — regardless of whether vim mode is active or what vim mode state (INSERT vs NORMAL) the user is in. This causes L("prompt"), YH(!1) (navigate to prompt / clear) to fire unconditionally on any Escape keypress on the agent screen, racing against and overriding the vim mode's INSERT→NORMAL transition.

The fix should gate F8 on vim mode state: only allow the escape-to-cancel behavior when vim is disabled or already in NORMAL mode (i.e. a second Escape in NORMAL mode should cancel, but the first Escape from INSERT should not).

Environment

Claude Code 2.1.179
Vim mode: enabled
OS: Linux (Fedora)

View original on GitHub ↗

3 Comments

erdembircan · 2 months ago

Reproduces on macOS as well (Claude Code 2.1.179, macOS, vim mode enabled), so this is platform-independent — not Linux-only. Same behavior: on the agent screen, typing a prompt and pressing <kbd>Esc</kbd> to go from INSERT to NORMAL mode wipes the entire prompt and navigates back instead of just switching vim modes. Easy to accidentally lose a whole prompt this way. The root-cause analysis above matches — the escape-to-cancel handler isnt gated on vim mode state.

thiblahute · 1 month ago

This is often very annoying, I lost many well thought prompts because of that one.

bcherny collaborator · 15 days ago

Reproduced on v2.1.233 (macOS).

Steps:

Enable vim mode ("editorMode": "vim" in settings; the main prompt shows -- INSERT --).
Run claude agents to open the agent screen (same screen as ← / Ctrl-Z from the main prompt).
Type hello world in the prompt at the bottom.
Press Esc once.

Observed: the whole prompt is wiped immediately and the input goes back to the empty placeholder. Typing afterwards still inserts text (typing ihello shows ihello), so the input never actually switches INSERT → NORMAL — Esc only ever clears. The footer on this screen says esc to clear and shows no vim mode indicator.

Expected: the first Esc switches from INSERT to NORMAL and keeps the typed text, like the main prompt; only a further Esc in NORMAL should clear.

Assessment: this looks like a genuine bug. Vim mode is meant to apply to the agent-screen inputs (Esc in INSERT → NORMAL, Esc in NORMAL → clear), and that is how the input itself is written, but the agent screen's own Esc handler ("esc to clear") runs first and clears the text before the vim layer sees the keypress. It's not a regression — Esc has always cleared here — but the vim wiring added for this screen is being preempted, so the fix is to let Esc reach the vim layer while the input is in INSERT mode. Still present on the latest release.

🤖 Generated with Claude Code

Showing cached comments. Read the full discussion on GitHub ↗