[BUG] Multi-line paste fails in Ghostty 1.3.x with TERM=xterm-ghostty (works after switching to TERM=xterm-256color)

Preflight Checklist

• [x] I have searched existing issues
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

In Ghostty 1.3.1 with the default TERM=xterm-ghostty, pasting multi-line text into Claude Code's input prompt:

1. Triggers the multi-line paste warning dialog (suggesting bracketed paste isn't engaged), and
2. After confirming, every \n in the paste is interpreted as Enter — splitting the paste into multiple submitted messages instead of being inserted as a single multi-line block.

Pasting the same text into the surrounding zsh shell (same Ghostty window, no Claude Code) works correctly — bracketed paste is wrapped and content stays intact. So Ghostty itself is fine; the issue is specifically Claude Code's input handling.

Workaround (and the smoking gun)

Launching Claude Code with TERM=xterm-256color claude makes paste work normally — no warning, newlines preserved.

That implicates Claude Code's TERM-driven code path:

• xterm-ghostty terminfo declares both bracketed paste (BE=\E[?2004h, PS=\E[200~, PE=\E[201~) and kitty-keyboard-protocol-style extensions.
• xterm-256color terminfo declares neither.

So Claude Code seems to take a kitty-protocol-aware paste tokenization path on xterm-ghostty, and that path mangles the paste.

What Should Happen?

Multi-line paste in Ghostty (no tmux) with the default TERM=xterm-ghostty should preserve newlines and not show the bare-paste warning, the same way TERM=xterm-256color already works.

Likely Regression Window

Changelog mentions paste-tokenizer changes around v2.1.119:

• "Fixed multi-line paste losing newlines in terminals using kitty keyboard protocol sequences inside bracketed paste"
• "Fixed pasting CRLF content (Windows clipboards, Xcode console) inserting an extra blank line between every line"

Plausibly the kitty-protocol-aware paste path landed/changed in 2.1.119 and didn't cover Ghostty 1.3.x's specific encoding. Related but distinct: #43169 (tmux + extended-keys-format=csi-u, closed as duplicate), #3134 (long-running bracketed paste corruption issue).

Steps to Reproduce

1. Ghostty 1.3.1 (default config), echo $TERM shows xterm-ghostty.
2. Launch claude (no tmux, no multiplexer).
3. Copy multi-line text:

``
line one
line two
line three
``

1. Cmd+V into the Claude Code prompt.
2. Observe the paste warning, then observe each line being submitted separately after dismissing it.
3. Exit, relaunch with TERM=xterm-256color claude, repeat — paste works correctly.

Claude Code Version

2.1.123

Platform

Anthropic API

Operating System

macOS 26.3 (arm64)

Terminal/Shell

Other — Ghostty 1.3.1, zsh 5.9. No tmux/zellij/screen.

Additional Information

infocmp -x xterm-ghostty | grep -E 'BE|BD|PS|PE' →

BD=\E[?2004l, BE=\E[?2004h, ...
PE=\E[201~, PS=\E[200~, ...

So bracketed paste is fully declared in the Ghostty terminfo; the issue isn't a missing capability.