TL;DR:
DO NOT use escape-time 0
, but rather set it to a low value.
In ~/.tmux.conf
:
set -s escape-time 50 # ~5-100. https://superuser.com/a/1809494/224906
Finish by either reloading your tmux config or restarting your tmux server. (In your CLI, run either tmux source-file ~/.tmux.conf
or tmux kill-server; tmux
.)
Detailed Explanation:
After spending several days over the last couple of months tracking down a very annoying (non-deterministic and seemingly random) issue while remotely connected to a tmux server (via iTerm2 3.4.20 -> zsh 5.8.1 -> ssh 8.9p1 -> zsh 5.8.1 -> tmux 3.3a), I would highly recommend NOT setting escape-time to 0 (as suggested by others here, and even by tmux-sensible, which links to this very question at the time of my post), but rather setting escape-time to a lower value of something like 10 or 50 (from the default of 500).
Why? I finally discovered the solution in the GitHub issue "tmux 3.3 leaks text into shell":
escape-time 0
prevents tmux from recognizing escape sequences that are fragmented across read/packet boundaries. You should raise that to a more reasonable value such as 100ms which should be enough time for most cases while still being quick enough that it shouldn't cause human-scale interaction issues.
He is using a completely different terminal than me (wezterm vs iTerm2), yet is experiencing a very similar issue of a combined CSI (Control Sequence Introducer) and DCS (Device Control String) escape sequence—specifically \033[>0;95;0c\033P>|iTerm2 3.4.20\033\\
—leaking into the shell in response to the CSI escape sequences CSI > c
(aka \033 [ > c
) and CSI > q
(aka \033 [ > q
). (Which, at least for me, seem to always occur in sequence immediately after one another.)
After some time, this would cause a random paste to occur in my vim buffer, followed by Term2 3.4.20
[sic] being prepended to the pasted text.
Further detail to help others searching for this solution:
The combined CSI and DCS sequence \033[>0;95;0c\033P>|iTerm2 3.4.20\033\\
causes the following in vim: \033[>0;95;0c\033
doesn't do much, P
pastes whatever is in vim's unnamed/default register, >|
tabs the line to the right, i
enters insert mode, Term2 3.4.20
is inserted into the buffer, \033
escapes back out of insert mode, and the final \\
basically does nothing.
I've observed that this happens more often when I'm on the road, and especially when using an unreliable and slow mobile connection. This now makes perfect sense, since packet latency is greater under these conditions, and since I was using a escape-time 0
.
TL;DR: Don't use escape-time 0
; it exists for a good reason. Give it a low reasonable value (like 5, 50, or 100) that will still work well when connected remotely. Adjust as needed to find the right balance. If the value is too high, it'll interfere with human-scale interactions. If the value is too low, you may experience escape sequence artifacts and bugs.
Edit: This problem and solution is also cited in this Microsoft WSL issue on GitHub, which similarly links back to this question.
Edit #2: I've also learned that the issues I described above can (and perhaps more likely) be due to TTY_QUERY_TIMEOUT
in tmux/tty.c
not being set high enough, but this is beyond the scope of this question. It remains true that you shouldn't use escape-time 0
for the reasons mentioned above.