[BUG] Multi-line paste loses newlines when tmux extended-keys-format is csi-u

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?

Multi-line paste collapses to a single line when using Claude Code from within Ghostty and tmux's extended-keys-format is set to csi-u. All newlines and carriage returns are silently dropped from pasted content within Claude Code's input.

For example, pasting 3 numbered lines:

1. First line
2. Second line
3. Third line

Results in: 1. First line 2. Second line 3. Third line

What Should Happen?

Pasted multi-line text should preserve line breaks, as it does when extended-keys-format is not set to csi-u.

Error Messages/Logs

No error messages — newlines are silently dropped. No crash or freeze, just data loss in the paste.

Steps to Reproduce

1. Add to ~/.tmux.conf:

``
set-option -g extended-keys on
set-option -g extended-keys-format csi-u
``

1. Kill tmux server and restart: tmux kill-server && tmux
2. Launch claude inside the tmux session
3. Copy any multi-line text to the clipboard
4. Paste with Cmd+V (or terminal paste)
5. Observe: all newlines are stripped; text appears as a single line

Control test: Comment out the two extended-keys lines, tmux kill-server && tmux, launch claude, paste the same text — newlines are preserved.

Note: Detach/reattach is insufficient to clear the state. The tmux server caches terminal capability negotiation and persists it until the server process is killed.

Claude Model

Opus

Is this a regression?

No, this never worked

Claude Code Version

2.1.91 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

Terminal: Ghostty (not in the dropdown)
Multiplexer: tmux 3.5a
macOS: Darwin 24.5.0 (Sequoia)

Root cause hypothesis: When tmux's extended-keys-format is csi-u, tmux encodes CR (0x0D) within bracketed paste content as CSI-u sequences (e.g., ESC[13;1u) instead of sending raw bytes. Claude Code's bracketed paste tokenizer does not decode CSI-u sequences within paste brackets, so the encoded carriage returns are silently lost.

Per the kitty keyboard protocol spec, the keyboard protocol should not affect content inside bracketed paste brackets (ESC[200~ ... ESC[201~). However, tmux's extended-keys-format csi-u implementation appears to re-encode characters within the paste bracket.

The fix is likely in the paste tokenizer — it should decode CSI-u sequences for CR/LF (and potentially other control characters) when encountered inside bracketed paste content.

Related issues:

• #3134 — Terminal Paste Corruption from Bracketed Paste Mode
• #41598 — Paste causes permanent session freeze (tokenizer consuming PASTE_END)
• #39219 — Enter key intermittently stops working in Ghostty