### Preflight Checklist - [x] I have searched [existing requests](https://github.com/anthropics/claude-code/issues?q=is%3Aissue%20label%3Aenhancement) and this feature hasn't been requested yet - [x] This is a single feature request (not multiple features) ### Problem Statement `Ctrl+[` is a standard ANSI terminal keybinding that sends the exact same escape sequence as the `Esc` key. However, Claude Code does not recognize `Ctrl+[` as `Esc` in either normal mode or vim mode. This force

Support Ctrl+[ as Esc equivalent in both normal and vim input modes

Status Fixed / completed

Maintainer reply None cached

Activity 5 comments · opened Mar 11, 2026 · closed Mar 29, 2026

Preflight Checklist

[x] I have searched existing requests and this feature hasn't been requested yet
[x] This is a single feature request (not multiple features)

Problem Statement

Ctrl+[ is a standard ANSI terminal keybinding that sends the exact same escape sequence as the Esc key. However, Claude Code does not recognize
Ctrl+[ as Esc in either normal mode or vim mode.

This forces users to physically move their hand to press Esc, breaking the home-row muscle memory that terminal users rely on. The issue affects both vim mode (where Ctrl+[ should exit insert mode) and normal mode (where Esc dismisses/cancels input).

Proposed Solution

Map Ctrl+[ to Esc in all input modes:

Normal mode: same effect as pressing Esc
Vim mode: exit insert mode, identical to Esc

This is consistent with standard terminal, readline, and vim behavior where Ctrl+[ has always been a first-class equivalent to Esc.

Alternative Solutions

Using physical Esc: works, but requires moving hand away from the home row

Priority

Medium - Would be very helpful

Feature Category

Interactive mode (TUI)

Use Case Example

I'm in Claude Code's input box typing a message
I want to cancel or switch to vim normal mode
I instinctively press Ctrl+[ (standard terminal habit)
Currently nothing happens — I have to reach for the Esc key
With this feature, Ctrl+[ would work identically to Esc

Additional Context

OS: macOS, Shell: zsh, Chip: Apple Silicon (arm64)
Ctrl+[ producing the escape sequence is defined ANSI terminal behavior, not a vim-specific concept
This is a common request from terminal power users who avoid moving hands off the home row

View original on GitHub ↗

5 Comments

benhamill · 5 months ago

I use zsh on Ubuntu inside WSL on Windows and use it in vim mode. I'm on Claude code version 2.1.83. I feel like this was working until recently. At least, I wasn't tripping over my CTRL-[ muscle memory until today. Claude seems to think that Claude code is intercepting the CTRL-[ signal before it gets to the terminal to switch input modes.

So I would reclassify this as a bug because I think something may have changed recently regarding this.

ink-ableton · 5 months ago

FWIW this is from my claude session finding a fix:

  My best hypothesis: Claude Code likely enables the modifyOtherKeys or Kitty keyboard protocol when it starts up (a common practice for TUI apps to disambiguate key
  sequences). Under these protocols, ctrl+[ gets sent as something like ESC[91;5u instead of bare 0x1b — but the physical ESC key still sends plain 0x1b.

I was able to fix that for me using a mapping in iterm2 as suggested by claude:

So you can intercept ctrl+[ and force it to send 0x1b
  regardless of what protocol Claude Code has enabled.
  iTerm2 → Settings → Profiles → Keys → Key Mappings → +

  1. Click the shortcut field and press ctrl+[
  2. Action: Send hex code
  3. Value: 1b

So as suggested by your application, here I am :)
Worth filing the bug at anthropics/claude-code — the vim mode should recognize ESC[91;5u as ESC.

Sherlockedb · 5 months ago

FWIW this is from my claude session finding a fix: `` My best hypothesis: Claude Code likely enables the modifyOtherKeys or Kitty keyboard protocol when it starts up (a common practice for TUI apps to disambiguate key sequences). Under these protocols, ctrl+[ gets sent as something like ESC[91;5u instead of bare 0x1b — but the physical ESC key still sends plain 0x1b. ` I was able to fix that for me using a mapping in iterm2 as suggested by claude: ` So you can intercept ctrl+[ and force it to send 0x1b regardless of what protocol Claude Code has enabled. iTerm2 → Settings → Profiles → Keys → Key Mappings → + 1. Click the shortcut field and press ctrl+[ 2. Action: Send hex code 3. Value: 1b ` So as suggested by your application, here I am :) Worth filing the bug at anthropics/claude-code — the vim mode should recognize ESC[91;5u as ESC.`

That's great! This solved my problem! Thank you so much!

Sherlockedb · 5 months ago

I use zsh on Ubuntu inside WSL on Windows and use it in vim mode. I'm on Claude code version 2.1.83. I feel like this was working until recently. At least, I wasn't tripping over my CTRL-[ muscle memory until today. Claude seems to think that Claude code is intercepting the CTRL-[ signal before it gets to the terminal to switch input modes. So I would reclassify this as a bug because I think something may have changed recently regarding this.

Oh, after taking your advice, I went and tested macOS's built-in terminal, as well as the terminals in VSCode and Cursor — all of them support using Ctrl+[ as a substitute for Esc. So it really is only an issue in iTerm2, which confirms it's a bug. Someone above @ink-ableton has also replied with instructions on how to configure an iTerm2 shortcut to work around the issue.

github-actions[bot] · 4 months ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.