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

Description

Multi-line paste collapses to a single line when tmux's extended-keys-format is set to csi-u. Newlines/carriage returns are silently dropped from pasted content.

Environment

• Claude Code: 2.1.47 (but likely affects all recent versions)
• Terminal: Ghostty (macOS)
• Multiplexer: tmux 3.5a
• macOS: Darwin 24.5.0

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
3. Copy multi-line text to clipboard and paste (Cmd+V)
4. Observe: all newlines are stripped; text appears as a single line

Expected Behavior

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

Actual Behavior

All newlines/carriage returns are dropped. A 3-line paste becomes 1 line.

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 line breaks 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 paste content.

Workaround

Disable extended-keys-format csi-u in tmux and restart the tmux server (tmux kill-server). Note: detach/reattach is insufficient — the tmux server caches terminal capability state and persists it until the server process is killed.

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

🤖 Generated with Claude Code