Tmux shows control sequences during attach or resize

Issue description

Sometimes, when I attach to a session, tmux injects some control sequences as-if I had typed them.
Here's an example from this morning:

rcampbell@dev3-181 ~/mine/version
$ 11;rgb:d1d1/f4f4/d6d6

I'm running Fedora 42, and I'm connecting via SSH.

rcampbell@dev3-181 ~/mine/version
$ uname -sp && tmux -V && echo $TERM
Linux unknown
tmux 3.5a
tmux-256color

I tried building the HEAD of master, but I can't run it at all. I just get:

$ ./tmux
open terminal failed: not a terminal

This is similar to #4535, except that bug was closed because the reporter was not cooperating. I don't mind trying to debug this. I tried adding a bunch of options to my .tmux.conf based on some googling, including:

# Trying to debug terminal escape codes showing up in tmux sessions
set-option -g default-terminal "tmux-256color"
set-option -g set-clipboard off
set-window-option -g xterm-keys off
set-option -g terminal-overrides ',xterm-256color:RGB@:Tc@' # Using your confirmed non-hyphenated TERM
set-option -g allow-passthrough off
set-option -g set-titles on # Explicitly set to 'on'

And while it might be less common with those settings, it still happens.

What terminal are you using?

How did you build tmux from master? You need to try with master because there is a good chance this is fixed.

I have tried Microsoft Terminal, and Mintty (I'm running Windows 11, running a terminal, and then sshing into Fedora 42).

I built from master using the instructions in the repo:

git clone https://github.com/tmux/tmux.git
cd tmux
./configure && make
$ ./tmux
open terminal failed: not a terminal

Show config.log please.

Are you killing your existing tmux? You can't mix old server and new client. If you don't want to do that, use tmux -Ltest.

Sorry, I thought I had killed my old tmux v3.5, but I had some old stuck processes.

Anyway, now that I really killed all the old processes, I can start the one built from "master".

I will try to reproduce it using the "master" version.

I just reproduced it with the "master" build:

11;rgb:d1d1/f4f4/d6d611;rgb:d1d1/f4f4/d6d611;rgb:d1d1/f4f4/d6d611;rgb:d1d1/f4f4/d6d611;rgb:d1d1/f4f4/d6d611;rgb:d1d1/f4f4/d6d611;rgb:d1d1/f4f4/d6d611;rgb:d1d1/f4f4/d6d611;rgb:d1d1/f4f4/d6d611;rgb:d1d1/f4f4/d6d6

Show server log please from reproducing with master.

tmux-server-3744068.log

Here is the server log from my reproduction.

Can you do two things:

If you do this outside tmux, what do you see:

printf '\033[c\033[>c\033[>q\033]10;?\033\\\033]11;?\033\\'; read -n200

If you try it a few times does the output change, or does it always stay the same?

You'll need to press C-c each time to get back to the prompt.

Run tmux with strace, reproduce and show me the strace.out file:

strace -vvttt -fostrace.out ./tmux -Ltest -f/dev/null new

I think this is an issue that came up before on Windows and is because there are a number of layers on Windows that handle escape sequences and they do not seem to play nicely together.

$ printf '\033[c\033[>c\033[>q\033]10;?\033\\\033]11;?\033\\'; read -n200
^[[?64;1;2;4;6;9;11;15;21;22;28;29c^[[>77;30708;0c^[P>|mintty 3.7.8^[\^[]10;rgb:1010/3030/3030^[\^[]11;rgb:d1d1/f4f4/d6d6^[\^C
rcampbell@dev3-181:~
rcampbell@dev3-181 ~
$ printf '\033[c\033[>c\033[>q\033]10;?\033\\\033]11;?\033\\'; read -n200
^[[?64;1;2;4;6;9;11;15;21;22;28;29c^[[>77;30708;0c^[P>|mintty 3.7.8^[\^[]10;rgb:1010/3030/3030^[\^[]11;rgb:d1d1/f4f4/d6d6^[\
>
rcampbell@dev3-181:~
rcampbell@dev3-181 ~
$ printf '\033[c\033[>c\033[>q\033]10;?\033\\\033]11;?\033\\'; read -n200
^[[?64;1;2;4;6;9;11;15;21;22;28;29c^[[>77;30708;0c^[P>|mintty 3.7.8^[\^[]10;rgb:1010/3030/3030^[\^[]11;rgb:d1d1/f4f4/d6d6^[\
>
rcampbell@dev3-181:~
rcampbell@dev3-181 ~
$ printf '\033[c\033[>c\033[>q\033]10;?\033\\\033]11;?\033\\'; read -n200
^[[?64;1;2;4;6;9;11;15;21;22;28;29c^[[>77;30708;0c^[P>|mintty 3.7.8^[\^[]10;rgb:1010/3030/3030^[\^[]11;rgb:d1d1/f4f4/d6d6^[\
>
rcampbell@dev3-181:~
rcampbell@dev3-181 ~

Actually, never mind, this log is confusing because you have two clients, so it is not what I thought.

I have a single ssh connection, with a single client. But that ssh connection drops occasionally (I'm on a laptop and I'm constantly switching from docking-station to wifi to VPN). When it drops, it tries to automatically reconnect and run tmux attach. The new client probably attaches before the old client times out; but my goal is to only have 1 client at a time.

OK, problem is that your terminals are being slow to respond, although for some reason not all the time. It could be network, but this was happening before and it was something to do with Window. For example, in your log tmux gets this:

1750784565.300206 /dev/pts/6: keys are 70 (\033[?64;1;2;4;6;9;11;15;21;22;28;29c\033[>77;30708;0c\033P>|mintty 3.7.8\033\\\033]10)
1750784565.324975 /dev/pts/6: keys are 46 (;rgb:1010/3030/3030\033\\\033]11;rgb:d1d1/f4f4/d6d6\033\\)

So it gets part of the responses (to DA, DA2, XDA and the start of the colours), then it is not until another 24 milliseconds later that it gets the rest. By this time tmux has decided (because the default escape-time is 10 milliseconds) that the first bit of the colours (\033]10) was in fact you pressing M-] then 10, and so on for the rest of the response.

We already worked around this by automatically extending escape-time if we are waiting for DA, DA2, XDA, so we can just extend that to include the colours as well. Try this please: x.diff.txt

I want to mention that I was reproducing this issue when I upgraded from tmux 2.6 to 3.5a. Checking out 7e43953 master as of today has solved the issues for me.

I spoke too soon. I am now reproducing this again.

Found a workaround from Windows Terminal issues:

Garbage characters printed when attaching remote tmux session microsoft/terminal#18600 (comment)
Garbage characters printed when attaching remote tmux session microsoft/terminal#18600 (comment)

TL;DR:
In your tmux.conf

set -sg escape-time 500 # or set to some value larger than 10
set -g focus-events off

20250713 edit:

Note that there would be some noticeable delay with your typing escape keys.

Nobody tested this fix but it looks right to me so I have applied it.

This issue has been automatically locked since there has not been any recent activity after it was closed.

Navigation Menu

Repository navigation

Tmux shows control sequences during attach or resize #4541

Issue description

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Tmux shows control sequences during attach or resize #4541

Description

Issue description

Activity

nicm commented on Jun 24, 2025

solace-rcampbell commented on Jun 24, 2025

nicm commented on Jun 24, 2025

nicm commented on Jun 24, 2025

solace-rcampbell commented on Jun 24, 2025

solace-rcampbell commented on Jun 24, 2025

nicm commented on Jun 24, 2025

solace-rcampbell commented on Jun 24, 2025

nicm commented on Jun 24, 2025

solace-rcampbell commented on Jun 24, 2025

nicm commented on Jun 24, 2025

solace-rcampbell commented on Jun 24, 2025

nicm commented on Jun 24, 2025

czipperz commented on Jul 8, 2025

czipperz commented on Jul 8, 2025

zzeitt commented on Jul 10, 2025

nicm commented on Jul 13, 2025

github-actions commented on Aug 13, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions