[BUG] Esc does not close /usage in iTerm2 (xterm-256color, no kitty protocol) on 2.1.270; q bound to confirm:no works

Status Fixed / completed
Reported on v2.1.270
Maintainer reply None cached
Activity 1 comment · opened Sep 13, 2026 · closed Sep 13, 2026
Correction (same day): the terminal is iTerm2 3.6.11, not Ghostty. First version of this report named the wrong terminal; the symptom, version and workaround are unchanged. Title and body updated.

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report
  • [x] I am using the latest version of Claude Code

What's Wrong?

In iTerm2 3.6.11 on macOS 27.0, pressing Esc in the /usage view no longer closes it and returns to the prompt. The view stays open. This used to work; it stopped after a recent update (currently on 2.1.270).

The default keybinding is present: /usage uses the Settings context, where escape is bound to confirm:no. So the mapping isn't missing — the bare 0x1b keypress apparently isn't being recognized as Escape in this context anymore.

iTerm2 does not speak the kitty keyboard protocol, and CSI u / modifyOtherKeys (Use libtickit protocol) is off in this profile, so Esc arrives as a plain 0x1b byte. That makes this the classic "is a lone ESC a key or the start of a sequence?" disambiguation path.

Suspected change: 2.1.269 shipped "Fixed F1/F2/F4 not working in kitty-protocol terminals and Delete in st, Alt+arrows acting as Escape in rxvt-unicode …", which reworked key decoding. #93788 reports that the same release killed CSI arrow/Home/End keys in the composer on a plain xterm-256color terminal, with 2.1.268 fine. This report is likely the same regression seen from the other side: there, ESC-prefixed sequences stop being recognized; here, a bare ESC does. I have not bisected against 2.1.268 (not on disk).

Workaround (confirmed)

Adding an extra close key to the Settings context works:

{
  "bindings": [
    { "context": "Settings", "bindings": { "q": "confirm:no" } }
  ]
}

With this, q closes /usage. Since confirm:no fires fine from another key, the action itself is intact; only the Esc keypress isn't reaching it.

Steps to Reproduce

  1. Open Claude Code 2.1.270 in iTerm2 (default profile, no keybindings.json, "tui": "fullscreen").
  2. Run /usage.
  3. Press Esc.

Expected: the usage view closes and focus returns to the prompt.
Actual: nothing happens; the usage view stays open.

Environment

| | |
|---|---|
| Claude Code | 2.1.270 (native install, ~/.local/share/claude/versions/) |
| OS | macOS 27.0 release candidate (26A428), arm64 |
| Terminal | iTerm2 3.6.11, TERM=xterm-256color, TERM_PROGRAM=iTerm.app |
| iTerm2 profile | defaults: Option Key Sends = Normal (both), no Keyboard Map overrides, no global Esc mappings, libtickit/CSI u off |
| settings.json | "tui": "fullscreen", no vim mode |
| keybindings.json | none at time of repro (only added afterwards for the workaround above) |

Related, but distinct

  • #93788 — 2.1.269 kills CSI arrow/Home/End keys in the composer on xterm-256color over SSH. Different keys, but same terminal class and same release; plausibly the same key-decoding change.
  • #93384 — Esc in dialog text fields discarding text; not about Esc being ignored.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗