branderson/dotfiles
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Merge pull request 'Fix multi-line paste corruption in nested tmux on 3.5/3.5a' (#6) from tmux-extended-keys-paste into master

Browse Source 
Reviewed-on: #6
Reviewed-by: branderson <brad@branderson.io>
This commit was merged in pull request #6.
This commit is contained in:
branderson
2026-08-17 14:27:55 -07:00
parent 86d19db1e9 123c68dbae
commit 7849b91f06
1 changed files with 18 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files
config/tmux.conf
+18 -5
View File
@@ -87,13 +87,26 @@ if-shell "tmux -V | awk '{print $2}' | awk -F. '{if ($1*1000+$2 >= 3003) exit 0;
# itself using default-terminal above (screen-256color) -- 'xterm*' would
# never match that, breaking the nested case this is meant to support.
#
# Investigated as a suspect for multi-line paste getting corrupted with
# literal CSI 27;<mod>;<key>~ garbage in place of newlines (see Claude Code
# issues #43169 and #30239) -- turning this off did not fix that paste
# corruption, so it's an upstream Claude Code paste-tokenizer bug, not
# something caused by this setting. Restored.
# Not the cause of multi-line paste arriving with literal CSI 27;5;106~ in
# place of each newline (that being C-j, the pasted newline, in
# modifyOtherKeys form). That is a tmux 3.5/3.5a bug: 3.5 rewrote extended-key
# handling and encodes keys inside a bracketed paste, which the layer further
# in then passes through verbatim rather than decoding. Reproduced against
# 3.2a/3.3a/3.4/3.5a/3.6b/3.7c -- only 3.5 and 3.5a corrupt, and only on a hop
# whose downstream has asked for modifyOtherKeys mode 2, which a nested tmux
# always does and a bare application under screen-256color generally doesn't.
# Hence it shows up with tmux at both ends of the ssh and not with one.
# Fixed upstream in 3.6, so upgrade the offending layer where that's possible.
if-shell "tmux -V | awk '{print $2}' | awk -F. '{if ($1*1000+$2 >= 3002) exit 0; else exit 1}'" 'set -s extended-keys on; set -as terminal-features "*:extkeys"'
# Where it isn't -- a host pinned to a distro tmux -- give the paste back on
# just those two versions. Nothing narrower helps: csi-u format only changes
# which escape lands in the text, and withholding the extkeys feature above
# stops this tmux asking its own parent for extended keys without stopping it
# encoding them for the pane. Turning them off is the whole of the workaround,
# and confining it to 3.5/3.5a keeps them everywhere else.
if-shell "tmux -V | awk '{hit = ($2 ~ /^3[.]5/)} END {exit hit ? 0 : 1}'" 'set -s extended-keys off'
# Accept pane-originated OSC 52 clipboard-set attempts into a real tmux
# buffer. Only on-vs-off matters here -- off would refuse to even look at
# these escapes; "on" (rather than "external") is needed so the pane-set-