Responses to DA, DA2, background color requests get passed on to the client on Windows Terminal

Issue description

When starting a new session, response to DA, DA2, background color requests get passed on to the client. E.g.

61;4;6;7;14;21;22;23;24;28;32;42;52c0;10;1c11;rgb:0c0c/0c0c/0c0c

Steps to reproduce:

open Windows Terminal on Windows11
ssh <user>@<linux host>
tmux -Ltest kill-server
tmux -vv -Ltest -f/dev/null new and see the response printed after bash prompt

Required information

Please provide the following information. These are required. Note that bug reports without logs may be ignored or closed without comment.

tmux version (tmux -V): tmux 3.5a
Platform (uname -sp): Linux x86_64
Terminal in use (xterm, rxvt, etc): Windows Terminal 1.22.12111.0
$TERM inside tmux (echo $TERM): tmux-256color
$TERM outside tmux (echo $TERM): xterm-256color
Logs from tmux (tmux kill-server; tmux -vv new).
tmux-client-11101.log
tmux-client-11582.log
tmux-client-11657.log
tmux-client-11669.log
tmux-client-11681.log
tmux-out-11584.log
tmux-out-11659.log
tmux-out-11671.log
tmux-out-11683.log
tmux-server-11103.log
tmux-server-11584.log
tmux-server-11659.log
tmux-server-11671.log
tmux-server-11683.log

Additional info

Environment:

Linux host:

$ uname -sp && tmux -V && echo $TERM
Linux x86_64
tmux 3.5a
xterm-256color

Windows client:

Windows Terminal: 1.22.12111.0
ssh: OpenSSH_for_Windows_9.5p2, LibreSSL 3.8.2

Other examples of the issue:

Receiving forground color instead of background color.

<user>@<host>:~$ 61;4;6;7;14;21;22;23;24;28;32;42;52c0;10;1c10;rgb:cccc/cccc/cccc

DA, DA2 parts was received twice, with one before the bash prompt showing up. Also receiving foreground color

^[[?61;4;6;7;14;21;22;23;24;28;32;42;52c^[[>0;10;1c<user>@<host>:~$ 61;4;6;7;14;21;22;23;24;28;32;42;52c0;10;1c10;rgb:cccc/cccc/cccc

Similar sympton also happen when atteching a session.

Related issues:

A late response to a secondary DA request gets passed on to the client Similar symptom and also about Windows Terminal. But the hypothesis and fix is probably different from this one, because in this issue:

the response comes fast (no noticable delay)
there are duplicated response, which cannot be explained by delay
this line of code looks suspicious, where tty->term->flags should probably be tty->flags. The bit set here and here are basically ignored. This might open a possibility for repeated requests ?

Many people seem to met similar symptom. This comment collected some related issues.

Does this still happen if you build tmux from master?

You are right it is using the wrong flags, will fix that.

Yes, it still happens on master.

Also saw your fix already. That was so quick.

So tested on commit 3e28777ecbc8de3df803d5d7429a5ecd35f61553 which includes the fix as well. Unfortunately the symptom still happens.

Show server log from reproducing with master.

tmux-client-11159.log
tmux-out-11161.log
tmux-server-11161.log

This seems like a bug in the terminal you are using. Unless I am missing something, tmux sends the requests once:

1757688748.884062 /dev/pts/1: \033[c
1757688748.884072 /dev/pts/1: \033[>c
1757688748.884078 /dev/pts/1: \033[>q
1757688748.884084 /dev/pts/1: \033]10;?\033\\\033]11;?\033\\

It receives a response and processes it:

1757688748.901619 /dev/pts/1: read 95 bytes (already 0)
1757688748.901657 /dev/pts/1: keys are 95 (\033[?61;4;6;7;14;21;22;23;24;28;32;42;52c\033[>0;10;1c\033]10;rgb:cccc/cccc/cccc\033\\\033]11;rgb:0c0c/0c0c/0c)
1757688748.901800 /dev/pts/1: received primary DA \033[?61;4;6;7;14;21;22;23;24;28;32;42;52c
...
1757688748.902052 /dev/pts/1: complete key \033[?61;4;6;7;14;21;22;23;24;28;32;42;52c 0xfe000000000
1757688748.902061 /dev/pts/1: keys are 56 (\033[>0;10;1c\033]10;rgb:cccc/cccc/cccc\033\\\033]11;rgb:0c0c/0c0c/0c)
1757688748.902068 /dev/pts/1: received secondary DA \033[>0;10;1c
...
1757688748.902189 /dev/pts/1: complete key \033[>0;10;1c 0xfe000000000
1757688748.902196 /dev/pts/1: keys are 46 (\033]10;rgb:cccc/cccc/cccc\033\\\033]11;rgb:0c0c/0c0c/0c)
1757688748.902218 colour_parseX11: rgb:cccc/cccc/cccc = #cccccc

After that there are 21 bytes left with the unfinished background response:

1757688748.902239 /dev/pts/1: keys are 21 (\033]11;rgb:0c0c/0c0c/0c)
1757688748.902245 /dev/pts/1: partial key \033]11;rgb:0c0c/0c0c/0c
1757688748.902251 /dev/pts/1: increasing delay for active query

Then we get an additional 79 bytes. The start of this completes the background:

1757688748.908002 /dev/pts/1: read 79 bytes (already 21)
1757688748.908030 /dev/pts/1: keys are 100 (\033]11;rgb:0c0c/0c0c/0c0c\033\\\033[?61;4;6;7;14;21;22;23;24;28;32;42;52c\033[>0;10;1c\033]10;rgb:cccc/cccc/cccc\\
033\\\033)
1757688748.908044 colour_parseX11: rgb:0c0c/0c0c/0c0c = #0c0c0c
...
1757688748.908054 /dev/pts/1: complete key \033]11;rgb:0c0c/0c0c/0c0c\033\\ 0xfe000000000

But the remaining 75 bytes are another copy of the DA and RGB response. tmux has already received the ones it requested, so it passes these on to the pane:

1757688748.908061 /dev/pts/1: keys are 75 (\033[?61;4;6;7;14;21;22;23;24;28;32;42;52c\033[>0;10;1c\033]10;rgb:cccc/cccc/cccc\033\\\033)

Can you please reproduce like this and send me the strace.out* files:

rm strace.out*;strace -s 16384 -vv -ff -ttt -ostrace.out tmux -f/dev/null -Ltest new

strace should let us confirm whether tmux is receiving the wrong thing (two replies to one request) from the terminal or whether it is getting confused inside tmux or libevent somewhere.

Renamed files with a .log suffix so github allow them uploaded.

strace.out.11256.log
strace.out.11257.log
strace.out.11258.log
strace.out.11259.log
strace.out.11260.log
strace.out.11261.log
strace.out.11262.log
strace.out.11263.log
strace.out.11264.log
strace.out.11265.log
strace.out.11266.log
strace.out.11267.log

Curious, the partial key (of the incomplete background response) seems to be repeated at the beginning of the additional 79 bytes. Is it from the terminal or it is buffered and repeated by some layer in the middle ?

OK it looks like strace.out.11258.log is the tmux server.

And fd 5 is the pty:

1757691107.088006 recvmsg(7, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="..." , iov_len=65535}], msg_iovlen=1, msg_control=[{cmsg_len=20, cmsg_level=SOL_SO\
CKET, cmsg_type=SCM_RIGHTS, cmsg_data=[5]}], msg_controllen=24, msg_flags=0}, 0) = 5907

I only see one request:

1757691107.100568 writev(5, [{iov_base="\33[?1049h\33[22;0;0t\33[?1h\33=\33[H\33[2J\33[?12l\33[?25h\33[?1000l\33[?1002l\33[?1003l\33[?1006l\33[?1005l\33[?2004\
h\33[?2031h\33[?996n\33(B\33[m\33[?12l\33[?25h\33[?1006l\33[?1000l\33[?1002l\33[?1003l\33[1;1H\33[1;50r\33[c\33[>c\33[>q\33]10;?\33\\\33]11;?\33\\\33[1;1H", iov_len=202}], 1) = 202

And we get back two responses:

1757691107.114367 readv(5, [{iov_base="\33[?61;4;6;7;14;21;22;23;24;28;32;42;52c\33[>0;10;1c\33]10;rgb:cccc/cccc/cccc\33\\\33]11;r", iov_len=80}], 1) = 80
1757691107.117514 readv(5, [{iov_base="gb:0c0c/0c0c/0c0c\33\\\33[?61;4;6;7;14;21;22;23;24;28;32;42;52c\33[>0;10;1c\33]10;rgb:cc", iov_len=79}], 1) = 79
1757691107.152101 readv(5, [{iov_base="cc/cccc/cccc\33\\\33]11;rgb:0c0c/0c0c/0c0c\33\\", iov_len=39}], 1) = 39

Followed by what looks like you pressing C-b C-k C-d?

1757691109.793142 readv(5, [{iov_base="\1", iov_len=1}], 1) = 1
1757691110.167898 readv(5, [{iov_base="\v", iov_len=1}], 1) = 1
1757691111.437000 readv(5, [{iov_base="\4", iov_len=1}], 1) = 1

This seems like either the terminal, or something between the terminal and tmux (IIRC Windows has several layers?) is doing the wrong thing, or interpreting something else that tmux sends as an additional request.

If you do this outside tmux:

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

What do you see?

ISTR something like this coming up before and I don't know if there was ever any conclusion. The issue has been confused a bit because Windows terminal seems to sometimes take a while to send replies and tmux was not waiting for long enough, but that should be fixed in master and does not seem to be what is happening here.

Curious, the partial key (of the incomplete background response) seems to be repeated at the beginning of the additional 79 bytes. Is it from the terminal or it is buffered and repeated by some layer in the middle ?

tmux is printing its entire key buffer, it includes what it already had, so here:

1757688748.908002 /dev/pts/1: read 79 bytes (already 21)

tmux read 79 bytes to go with the 21 it already had in the buffer. And:

1757688748.908030 /dev/pts/1: keys are 100 (\033]11;rgb:0c0c/0c0c/0c0c\033\\\033[?61;4;6;7;14;21;22;23;24;28;32;42;52c\033[>0;10;1c\033]10;rgb:cccc/cccc/cccc\\
033\\\033)

This is the entire data tmux now has available to process, both the existing 21 bytes and the new 79 bytes, so 100 bytes total (that's the "are 100" bit). It is the bit after the now-complete background response that is incorrect.

Followed by what looks like you pressing C-b C-k C-d?

Yes, C-a to go beginning of line, C-k to clear the line after the cursor (which is the DA, etc), C-d to exit bash, thus tmux.

If you do this outside tmux:
printf '\033[c\033[>c\033[>q\033]10;?\033\\\033]11;?\033\\';read
What do you see?

^[[?61;4;6;7;14;21;22;23;24;28;32;42;52c^[[>0;10;1c^[]10;rgb:cccc/cccc/cccc^[\^[]11;rgb:0c0c/0c0c/0c0c^[\

OK, so it is working as expected outside tmux. So either 1) it is interpreting something else that tmux sends as an additional request or 2) the bug is only triggered when the terminal is in a mode that tmux sets.

Can you try this program test.c.txt? Rename it to test.c, build it with make test and then run it with ./test. You should be able to exit it by pressing Enter. Let me know what it shows.

ISTR something like this coming up before and I don't know if there was ever any conclusion.

Maybe this one #2984
Yes, I also feel it is different, as there is no delay in this issue.

Or this PowerShell/Win32-OpenSSH#2275 (comment)
suspecting Windows Terminal sends response in 2 separate TCP packets. But the separate packets seem to be handled well with tmux buffer as you just explained.

tmux read 79 bytes to go with the 21 it already had in the buffer

Good to know. Thanks.

Can you try this program test.c.txt?

$ ./test
16 \033[?61;4;6;7;14;2
80 1;22;23;24;28;32;42;52c\033[>0;10;1c\033]10;rgb:cccc/cccc/cccc\033\\033]11;rgb:0c0c/0c0c/0c0
3 c\033\

Please try this one instead which sends the same as tmux actually sends: test2.c.txt

Great!
Tried multiple times:

Most frequently it repeat twice:

159 \033[?61;4;6;7;14;21;22;23;24;28;32;42;52c\033[>0;10;1c\033]10;rgb:cccc/cccc/cccc\033\\033]11;rgb:0c0c/0c0c/0c0c\033\\033[?61;4;6;7;14;21;22;23;24;28;32;42;52c\033[>0;10;1c\033]10;rgb:cc
39 cc/cccc/cccc\033\\033]11;rgb:0c0c/0c0c/0c0c\033\

Occasionally 3 times:

174 \033[?61;4;6;7;14;21;22;23;24;28;32;42;52c\033[>0;10;1c\033]10;rgb:cccc/cccc/cccc\033\\033]11;rgb:0c0c/0c0c/0c0c\033\\033[?61;4;6;7;14;21;22;23;24;28;32;42;52c\033[>0;10;1c\033]10;rgb:cccc/cccc/cccc\033\\033
96 ]11;rgb:0c0c/0c0c/0c0c\033\\033[?61;4;6;7;14;21;22;23;24;28;32;42;52c\033[>0;10;1c\033]10;rgb:cccc/cccc/cccc
27 \033\\033]11;rgb:0c0c/0c0c/0c0c\033\

Occasionally once:

64 \033[?61;4;6;7;14;21;22;23;24;28;32;42;52c\033[>0;10;1c\033]10;rgb:cccc/c
16 ccc/cccc\033\\033]11;r
19 gb:0c0c/0c0c/0c0c\033\

OK. I can't see anything in what tmux is sending that could cause this, and when I try the same program in xterm it is fine.

You could try removing sequences from the #define S line and try to narrow down what is causing it.

If you find it, we may be able to stop tmux sending it, but think for a proper fix you will need to report this to the terminal developers and see if they can help.

Shortest sequence I found: \033[?1049h\033[c

with output:

   63 \033[?61;4;6;7;14;21;22;23;24;28;32;42;52c\033[?61;4;6;7;14;21;22;23;
15 24;28;32;42;52c

   64 \033[?61;4;6;7;14;21;22;23;24;28;32;42;52c\033[?61;4;6;7;14;21;22;23;2
53 4;28;32;42;52c\033[?61;4;6;7;14;21;22;23;24;28;32;42;52c

   39 \033[?61;4;6;7;14;21;22;23;24;28;32;42;52c

Modified code: test2-1.c.txt

With some lookup, \033[?1049h means Enables the "alternate screen buffer." But "buffer" sounds like something within the same terminal. Receiving repeated response still sounds strange.

You can prevent tmux switching to the alternate screen by doing:

set -as terminal-overrides '*:smcup@:rmcup@'

set -as terminal-overrides '*:smcup@:rmcup@'

Tried 20 times in a row with this config on a master build, and didn't observe the sequence.
3.5a does not have the luck though.

Thanks a lot for all the effort replying and debugging to narrow it down !

Opened an issue for Windows Terminal, and closing this one.

FYI I'm also tracking down this issue as the maintainer of Windows Terminal¹.

It turns out that there is an issue in the Windows SSH client that results in it reusing a send buffer when reporting a SIGWINCH to the remote end. The Windows console sends a window size change signal when the alternate buffer is enabled or disabled², and so a packet that combines enabling the ASB with e.g. a DA1 request trigger the race condition more often.

The main tracking issue is currently PowerShell/Win32-OpenSSH#2275.

We have seen a number of similarly hostile responses from the above user. I'm sorry about that. ↩
the active region of the terminal can change in certain conditions due to the addition or deletion of a scroll bar or other UI elements; I don't know why we always send it rather than only when there's a true change. ↩

We have seen a number of similarly hostile responses from the above user. I'm sorry about that. ↩

I no longer intend to assist Microsoft with any issues.

You should be thankful I reported that one at all.

In any case, it wasn’t even worth using tmux.

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

Navigation Menu

Repository navigation

Responses to DA, DA2, background color requests get passed on to the client on Windows Terminal #4634

Issue description

Required information

Additional info

Environment:

Other examples of the issue:

Related issues:

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Responses to DA, DA2, background color requests get passed on to the client on Windows Terminal #4634

Description

Issue description

Required information

Additional info

Environment:

Other examples of the issue:

Related issues:

Activity

nicm commented on Sep 12, 2025

diffuty commented on Sep 12, 2025

nicm commented on Sep 12, 2025

diffuty commented on Sep 12, 2025

nicm commented on Sep 12, 2025

nicm commented on Sep 12, 2025

diffuty commented on Sep 12, 2025

diffuty commented on Sep 12, 2025

nicm commented on Sep 12, 2025

nicm commented on Sep 12, 2025

nicm commented on Sep 12, 2025

diffuty commented on Sep 12, 2025

nicm commented on Sep 12, 2025

diffuty commented on Sep 12, 2025

nicm commented on Sep 12, 2025

diffuty commented on Sep 12, 2025

nicm commented on Sep 12, 2025

diffuty commented on Sep 12, 2025

nicm commented on Sep 12, 2025

diffuty commented on Sep 12, 2025

giuliohome commented on Oct 4, 2025

nicm commented on Oct 4, 2025

nicm commented on Oct 4, 2025

giuliohome commented on Oct 4, 2025

DHowett commented on Oct 6, 2025

Footnotes

giuliohome commented on Oct 6, 2025

github-actions commented on Nov 6, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions