[Feature Request] Require double ESC in Vim mode to clear message in Plan Mode Q&A

Found 2 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/553
2. https://github.com/anthropics/claude-code/issues/736

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Those potential duplicates were closed prior to the question and answer functionality being released. It's the same sort of problem, just popping up in a new place.

I have the same problem. It's quite frustrating, when you make long answers and think about it for a few minutes. then you want a new line (esc, o) and bam, 5 minutes work is lost.

I just write a message here each time I accidentally hit ESC in Q&A mode..
Happend again, still annoyed.
I guess few people are using vim mode...

FUCK! AGAIN! (sorry for the swear words and capitalization)

I just ran into this twice in a row while answering a question with a detailed response. It would be awesome if it were possible to go to normal mode while answering the question to do more involved editing

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

I just checked again on Claude Code v2.0.76 and this bug is still occurring.

I've also done this maybe 5 times today. Kudos to it, Claude responded to my "Sorry, please ask me those again" by stopping using the Q&A mode and just asking its questions in a regular message. But yeah, for vim-mode users, when answering questions ESC should enter normal mode rather than nuke all my responses

Really annoying. The funniest thing is that as I was typing the /feedback to report this issue it also happened twice!

I got the same issue twice in a row while answering an elaborate answer in plan mode. This is really frustrating. Please support vim bindings during questions mode.

I've started selecting "Chat about this" and then answering if I'm planning on answering with any more than a few words, then you can edit in the standard prompt / use C-g / etc. and not worry about loosing what you're typing.

just offering this as a suggestion for people frustrated with this and looking for a workaround; still would be great if escape didn't cancel in vim mode, very frustrating the first few times it happens before you know to work around this problem

I just got hit by this. I don't think this is a feature request, this is a bug due to incomplete vim-mode. I complained to Claude. It said:

❯ Damn it! Exiting vim insert mode when replying to a plan question cancels the whole thing and looses the edits! Can you send a report about this somehow?

● That's a painful bug. Report it at: https://github.com/anthropics/claude-code/issues

The issue is: pressing Escape (to exit vim insert mode) while answering an AskUserQuestion/plan approval dialog cancels the dialog and discards edits.

Yeah, this is also really frustrating for a permission prompt when you spend a significant amount of time editing a response to a Yes[, and ] , and then it not only cancels the command you intended to run, but also you lose your carefully crafted response.

This is still an extremely frustrating issue for vim mode users as of 2.1.92. I run into it almost daily.

why is escape mapped to interrupt? is that not what ctrl-c is for?

Adding a slightly different angle — I'm in vim mode but the bug I hit wasn't the usual Esc-out-of-insert reflex. I was answering a multi-option AskUserQuestion with annotations on several of the options, and hit Esc trying to navigate from a notes field back up to the option list — Esc as "back up a level" within the question, which felt natural. Lost everything I'd typed.

Worth flagging because most of the thread frames this as a vim mode-switching issue. The same destructive outcome lands via a "navigation within a multi-level UI" mental model too, which would affect non-vim users as well. And what's typically lost is the reasoning being captured per option, not just a short answer.

A confirmation before discard, an auto-saved draft, or Esc just unfocusing the current field rather than killing the whole question — any of those would unblock the workflow. Thanks for the great tool.

_(Comment authored by Claude with Groot's approval.)_

Also experiencing it quite often during AskUserQuestion usage yes. Immediate, Auto close / auto No in tools where user can type (and expects to be able to use VIM shortcuts) is quite frustrating.

I had to add a memory and rule to my claude.md to NOT use AskUserQuestion and poll me 1 question at a time so I wouldn't lose significant effort when answers are lost. Extremely irritating to put a lot of effort into a prompt answer only to see it erased due to muscle-memory of hitting esc to navigate. I'm a vi power-user of over 30 years and I'm not spending human tokens re-wiring my brain to intercept esc ONLY in claude.

This is a data loss bug. The answers I've typed are lost. How is a data loss bug not treated with higher priority? I can understand if the view is something like, "We haven't designed the right experience yet" but at least save what I've typed in and make it retrievable. This shouldn't even be a question in 2026.

My Claude Code is giving this workaround:

You can neutralize Esc there by unbinding it in
~/.claude/keybindings.json:

  {
    "$schema": "https://www.schemastore.org/claude-code-keybindings.json",
    "$docs": "https://code.claude.com/docs/en/keybindings",
    "bindings": [
      {
        "context": "Confirmation",
        "bindings": {
          "escape": null,
          "ctrl+x ctrl+q": "confirm:no",
        },
        "context": "Select",
        "bindings": {
          "escape": null,
          "ctrl+x ctrl+q": "select:cancel"
        }
      }
    ]
  }

Has anyone tried this approach? Perhaps there is another key that we can assign instead of setting it null?

Update: I asked Claude to apply this change and after restart, asked it to simulate questions and verified that it worked. Esc no longer canceled the prompt and preserved what I typed. I also tried ^X+^Q` and it did cancel.