branderson
123c68dbae
Pasting multi-line text into a tmux session reached over ssh from inside another tmux replaced every newline with a literal CSI 27;5;106~, i.e. C-j -- the pasted newline -- rendered in modifyOtherKeys form rather than sent as a newline. tmux 3.5 rewrote extended-key handling and encodes keys inside a bracketed paste; the layer further in passes those bytes through verbatim instead of decoding them, so the application receives the escape as text. A hop only corrupts when whatever sits downstream of it has asked for modifyOtherKeys mode 2. A nested tmux always asks, because of the "*:extkeys" terminal-feature above it; an application running directly under screen-256color generally does not. That is why one tmux in the chain was fine and two were not. Confirmed by building 3.2a, 3.3a, 3.4, 3.5a, 3.6b and 3.7c and driving a real bracketed paste through a pty into every outer/inner combination: only 3.5 and 3.5a corrupt, and only on the requesting hop. Fixed upstream in 3.6, so upgrading is the real answer where it is available. For hosts pinned to a distro tmux, disable extended keys on exactly those two versions. Nothing narrower works: extended-keys-format csi-u only changes which escape lands in the text, and withholding the extkeys terminal-feature stops a tmux asking its own parent for extended keys without stopping it encoding them for its pane. With the guard in place all sixteen version combinations paste correctly, and extended keys stay on everywhere except 3.5/3.5a. The guard tests the version with an awk END block rather than a bare exit, so that empty input -- a tmux -V that failed for any reason -- leaves extended keys on instead of silently disabling them. Also corrects the comment that attributed this to a Claude Code paste tokenizer bug. It reproduces just as readily pasting into neovim.