[BUG] `claude attach` never asks the terminal about the kitty keyboard protocol (`CSI ? u`), so Shift+Enter submits in capable terminals not on the TERM_PROGRAM list

Status Open
Reported on v2.1.272
Maintainer reply None cached
Activity 0 comments · opened Sep 26, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

What's wrong

Plain claude now asks the terminal whether it supports the kitty keyboard protocol (CSI ? u), which fixed #71700 in 2.1.272. claude attach <id> (and so opening a background session) doesn't. At startup it sends only XTVERSION (CSI > 0 q) and DA1 (CSI c), and it turns on the kitty protocol and modifyOtherKeys only when TERM_PROGRAM is on the allowlist (iTerm.app, kitty, WezTerm, ghostty, tmux, windows-terminal, WarpTerminal).

In a terminal that fully supports the kitty protocol but has another name, Shift+Enter arrives as a bare CR in an attached session and submits the prompt instead of adding a line. The same terminal works with plain claude.

An XTVERSION reply naming an allowlisted terminal doesn't help in attach either; only TERM_PROGRAM counts.

Environment

  • Claude Code 2.1.283 (npm, Linux x86_64 container; first seen on macOS)
  • Terminal: an app embedding SwiftTerm 1.20.0, which answers CSI ? u, DA1 and XTVERSION. TERM=xterm-256color, TERM_PROGRAM set to the app's own name.

What I saw (byte captures)

| Command | TERM_PROGRAM | Terminal answers | Sent CSI ? u? | Kitty push (CSI > 5 u, CSI > 4;2 m)? |
|---|---|---|---|---|
| claude | SomeTerminal | CSI ? 0 u + DA1 | yes | yes |
| claude attach | SomeTerminal | CSI ? 0 u + DA1 | no | no |
| claude attach | SomeTerminal | XTVERSION ghostty 1.2.0 | no | no |
| claude attach | ghostty | nothing | no | yes |

With the kitty protocol off, Shift+Enter in the attached session submitted first. With TERM_PROGRAM=ghostty, the same terminal sent CSI 13;2 u and got a new line.

Workaround

The terminal can send ESC CR (Meta+Enter) for Shift+Enter, which Claude Code treats as a new line.

Related: #71700 (same root cause, fixed for plain claude only), #96526 (the same allowlist gating for modifyOtherKeys).

What Should Happen?

Expected

claude attach should use the same startup check as plain claude: send CSI ? u and turn on the kitty protocol when the terminal answers. Then attached sessions would behave the same as foreground ones in any capable terminal.

Error Messages/Logs

Steps to Reproduce

Steps to reproduce

  1. claude "say hi" --bg and note the id.
  2. Run claude attach <id> in a pseudo-terminal with TERM_PROGRAM=SomeTerminal, answering CSI ? u with CSI ? 0 u and CSI c with CSI ? 62;22 c.
  3. Record what Claude Code writes, then type first, press Shift+Enter (the terminal sends CR in legacy mode), and type second.

Claude Model

None

Is this a regression?

No, this never worked

Last Working Version

_No response_

Claude Code Version

2.1.283

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

_No response_

View original on GitHub ↗