You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Ghost characters appear when running tmux in a Win10->Linux ssh session #819
I'll now create a table listing the circumstances under which this bug occurs. Then we can run them all in the debugger and figure out where the problem lies.
Side note regarding this thread: On the night of October 5-6, 2025, following microsoft/terminal#19401, giuliohome deleted all of their messages here in one go; I had to recover them from my email and re-present them as quotations.
giuliohome left a comment (#819):
It seems to be an issue of OpenSSH_for_Window. When using weztern ssh it does not appear (also wsl ssh works but I'm afraid that is because conhost ignores the chars, I'm not sure if it's the same for wezterm ssh). It is strange that is especially affecting Windows 10 but it is possibly because of some optiizations of Windows 11. Maybe from your debugging you can find some additional details.
I disagree. When running tmux inside an OpenSSH session within vtm, everything works as expected.
Let's skip the WezTerm part, it will be likely similar to WT, let's focus only on that one.
But any idea about the difference between Windows 10 and 11 ?
I think the only difference is in the file C:\Windows\System32\conhost.exe (maybe also in some conpty.dll)
By interrupting OpenConsole.exe at a breakpoint, you delay the response tmux is waiting for. After the timeout, tmux no longer waits for DA responses and dumps everything to the input stream.
Yes, but why is the ESC lost? That is the main point, if it just pass the DA response to the client, it should not be visible as such.
Yes, I’m not certain what exactly caused the issue on the Windows 10 machine. It’s possible that the simulated scenario doesn’t fully match the behavior that occurred on the actual physical machine.
For debugging here, it's better to use printf "\e[c"; showkey -a instead of tmux itself.
It was also very strange that in .tmux.conf for that Win10 machine the set -sg escape-time 500 did not work but only the set -as terminal-overrides '*:smcup@:rmcup@'
This is something I could not reproduce (even with the BP trick)
We know that tmux sends to the terminal when it starts (#819 (comment)):
Please use printf+showkey to make it clear what's going on.
It seems to me (I haven't tested) that set -as terminal-overrides '*:smcup@:rmcup@' just removes \e[?1049h and \e[?1049l from the sequence mentioned above.
I need a few hours before I can regain access to that physical Windows 10 machine.
Meanwhile from WindowsTerminalPreview_1.24.2682.0_x64 and Win32-OpenSSH v9.=
8.3.0p2-Preview
from a beefy Windows11 machine:
PS C:\Users\giuli> C:\development\cpp\OpenSSH-Win64\OpenSSH-Win64\ssh.exe -=
l giulio -i \Users\giuli\.ssh\fedora_ed25519 192.168.1.202
Enter passphrase for key '\Users\giuli\.ssh\fedora_ed25519':
Last login: Sun Oct 5 11:01:40 2025 from 192.168.1.37
giulio@myhome:~$ showkey -a; sleep 500;printf"\e[?1049h\e[22;0;0t\e[?1h\e==3D\e[H\e[2J\e[?12l\e[?25h\e[?1000l\e[?1002l\e[?1003l\e[?1006l\e[?1005l\e[?=2004h\e(B\e[m\e[?12l\e[?25h\e[?1006l\e[?1000l\e[?1002l\e[?1003l\e[1;1H\e[1;=35r\e[c\e[>c\e[>q\e]10;?\a\e]11;?\a"
Press any keys - Ctrl-D will terminate this program
^D 4 0004 0x04
^C
giulio@myhome:~$
From a Windows 10 VirtualBox VM (not the physical Windows 10 machine). Un=
fortunately, the tmux issue did not reproduce =E2=80=94 surprisingly, I rem=
ember being able to reproduce it there before:=20
PS C:\Users\giuli> C:\test\OpenSSH-Win64\OpenSSH-Win64\ssh.exe -i C:\Users\=
giuli\fedora_ed25519 -l giulio 192.168.1.202
Enter passphrase for key 'C:\Users\giuli\fedora_ed25519':
Last login: Sun Oct 5 10:54:34 2025 from 192.168.1.37
giulio@myhome:~$ showkey -a; sleep 500; printf "\e[?1049h\e[22;0;0t\e[?1h\=
e=3D\e[H\e[2J\e[?12l\e[?25h\e[?1000l\e[?1002l\e[?1003l\e[?1006l\e[?1005l\e[=
?2004h\e(B\e[m\e[?12l\e[?25h\e[?1006l\e[?1000l\e[?1002l\e[?1003l\e[1;1H\e[1=
;35r\e[c\e[>c\e[>q\e]10;?\a\e]11;?\a"
Press any keys - Ctrl-D will terminate this program
^D 4 0004 0x04
^C
giulio@myhome:~$
From the original physical Windows 10 machine, where the issue always occurred.
TO-DO
sleep 500;
It is almost ten minutes.
The correct order (showkey should be at the end, it will accept the input stream):
printf "\e[?1049h\e[22;0;0t\e[?1h\e=\e[H\e[2J\e[?12l\e[?25h\e[?1000l\e[?1002l\e[?1003l\e[?1006l\e[?1005l\e[?2004h\e(B\e[m\e[?12l\e[?25h\e[?1006l\e[?1000l\e[?1002l\e[?1003l\e[1;1H\e[1;35r\e[c\e[>c\e[>q\e]10;?\a\e]11;?\a"; showkey -a
The correct order (showkey should be at the end, it will accept the input stream):
printf "\e[?1049h\e[22;0;0t\e[?1h\e=\e[H\e[2J\e[?12l\e[?25h\e[?1000l\e[?1002l\e[?1003l\e[?1006l\e[?1005l\e[?2004h\e(B\e[m\e[?12l\e[?25h\e[?1006l\e[?1000l\e[?1002l\e[?1003l\e[1;1H\e[1;35r\e[c\e[>c\e[>q\e]10;?\a\e]11;?\a"; showkey -a
Let me repeat it all. I have the Win10 machine now.
Physical machine, same SW versions as above
Microsoft Windows [Versione 10.0.19045.6332]
(c) Microsoft Corporation. Tutti i diritti sono riservati.
C:\Users\Andrea>C:\Giulio\dev\mywt\OpenSSH-Win64\OpenSSH-Win64\ssh.exe -l giulio -i .\.ssh\fedora_ed25519 192.168.1.202
Enter passphrase for key '.\.ssh\fedora_ed25519':
Last login: Sun Oct 5 11:28:02 2025 from 192.168.1.53
giulio@myhome:~$ printf "\e[?1049h\e[22;0;0t\e[?1h\e=\e[H\e[2J\e[?12l\e[?25h\e[?1000l\e[?1002l\e[?1003l\e[?1006l\e[?1005l\e[?2004h\e(B\e[m\e[?12l\e[?25h\e[?1006l\e[?1000l\e[?1002l\e[?1003l\e[1;1H\e[1;35r\e[c\e[>c\e[>q\e]10;?\a\e]11;?\a"; showkey -a
Ah, right, that's because the terminal doesn't have a scrollback buffer in alternate mode. Output needs to be redirected to a file, etc. Because of this, I initially tested without enabling altbuf and found nothing.
I will help you if you have any difficulties with building, only openssh-portable\contrib\win32\openssh\ssh.vcxproj needs to be built.
So, I have to start building it in VS2022 in Win11....
Ah, right, that's because the terminal doesn't have a scrollback buffer in alternate mode. Output needs to be redirected to a file, etc. Because of this, I initially tested without enabling altbuf and found nothing.
also if I have to repeat also from Win11 to compare it....
Let me rewind a moment
The ssh.exe project can be built anywhere, and then the build folder can be easily copied to another machine. I built it on Windows 10 and copied it to Windows 11.
Microsoft Windows [Versione 10.0.19045.6332]
(c) Microsoft Corporation. Tutti i diritti sono riservati.
C:\Users\Andrea>C:\Users\Andrea\Downloads\Release-o-sdn-o\Release\ssh.exe -l giulio -i .\.ssh\fedora_ed25519 192.168.1.202
Enter passphrase for key '.\.ssh\fedora_ed25519':
Last login: Sun Oct 5 11:56:04 2025 from 192.168.1.53
giulio@myhome:~$ tmux
I hit enter and it does not show the ghost chars
Am I correct in understanding that everything is working as expected?
Recap:
I can always reproduce the issue on my Windows 10 machine (it seems more like a hardware than a software problem).
Both fixes work: yours addresses the root cause, while mine prevents DA responses from going into ConPTY. I think the latter also makes sense. It is configurable per user and per SSH profile, which may be useful since DA responses there are only relevant for debugging, and by default it remains off.
When tmux handles a DA (Device Attributes) request, it acts as a terminal multiplexer rather than a regular shell. This means that the DA request can be forwarded directly over the network (via SSH) to the remote terminal — in this case, Windows Terminal (WT) — without necessarily being processed by the local shell inside tmux.
Once WT receives the DA response, it decides whether to pass it through ConPTY to the terminal output. ConPTY’s role is to facilitate communication between the terminal and the pseudo-terminal, but it has no functional need to process DA responses under normal operation; these responses are only relevant for debugging or diagnostic purposes.
Therefore, it makes sense to block the DA responses from reaching ConPTY:
The responses have already successfully traveled the network and reached WT.
ConPTY does not need them for normal terminal operation.
By blocking them, we prevent unnecessary “errors” or unwanted output in the terminal while preserving the ability to debug if needed.
I’ll keep my local copy for my needs and leave it to Microsoft to decide what works best for the others.
If there’s nothing else required from my side, many thanks to @o-sdn-o and all of you for the collaboration!
I hit enter and it does not show the ghost chars
Am I correct in understanding that everything is working as expected?
Yes, thank you very much!!! 🎉
Thank you too!!!
Nothing. Your fix works like a charm, I have only tested it, kudos to you!
This means that the DA request can be forwarded directly over the network (via SSH) to the remote terminal.
As far as I understand, terminal multiplexers shouldn't (never) forward DA requests from applications. Applications request the capabilities of the multiplexer they're running on. The multiplexer makes its own requests to the terminal it's running on. All requests shouldn't cross multiplexer boundaries.
By blocking them, we prevent unnecessary “errors” or unwanted output in the terminal while preserving the ability to debug if needed.
Blocking the response may cause the clipboard to stop working, as the response advertises support for clipboard operations. If there is no acknowledged response, this feature will not be activated.
As far as I understand and as far as I have tested the clipboard works because tmux receives the DA responses.
Will verify again later on
If you have a non regression that is not a debugging printf I am happy to double check.
Activity
o-sdn-o commentedon Sep 28, 2025
I'll now create a table listing the circumstances under which this bug occurs. Then we can run them all in the debugger and figure out where the problem lies.
o-sdn-o commentedon Sep 28, 2025
Side note regarding this thread: On the night of October 5-6, 2025, following microsoft/terminal#19401, giuliohome deleted all of their messages here in one go; I had to recover them from my email and re-present them as quotations.
I disagree. When running tmux inside an OpenSSH session within vtm, everything works as expected.
vtm.exe -r term->ssh user@linux->tmuxo-sdn-o commentedon Sep 28, 2025
Yes.
o-sdn-o commentedon Sep 28, 2025
I'm currently trying to configure WezTerm with the latest version of OpenConsole.exe. There's some issue with conpty.dll.
I want to align all the terminals so they all use the same component versions.
o-sdn-o commentedon Sep 28, 2025
Note that vtm.exe doesn't use either conhost.exe or OpenConsole.exe. They have their own implementation of the Windows Console Subsystem.
o-sdn-o commentedon Sep 28, 2025
I'm currently dumping input logs generated by each terminal in response to tmux being launched. These will help me figure out what to look for next.
o-sdn-o commentedon Sep 28, 2025
vtm:
o-sdn-o commentedon Sep 28, 2025
Windows Terminal (built from source) running in Win10:
o-sdn-o commentedon Sep 28, 2025
I haven't analyzed the logs yet. I need to get the logs from WezTerm. Do you know how to do that? If not, I'll find them myself.
o-sdn-o commentedon Sep 28, 2025
I think the only difference is in the file
C:\Windows\System32\conhost.exe(maybe also in some conpty.dll)o-sdn-o commentedon Sep 28, 2025
I'll check all the related files in Windows 10 and Windows 11 in just a minute.
o-sdn-o commentedon Sep 28, 2025
win10:
win11:
o-sdn-o commentedon Sep 28, 2025
I least of all think that condrv.sys is involved. It's more likely that OpenConsole.exe is causing various glitches when running in different modes.
o-sdn-o commentedon Sep 28, 2025
vtm works with condrv and there are no problems in this area.
o-sdn-o commentedon Sep 28, 2025
I need to see what tmux asks the terminal and what it responds with. This should be clear from the logs. I'm looking at them now.
130 remaining items
o-sdn-o commentedon Oct 5, 2025
For debugging here, it's better to use
printf "\e[c"; showkey -ainstead of tmux itself.o-sdn-o commentedon Oct 5, 2025
We know that tmux sends to the terminal when it starts (#819 (comment)):
Please use printf+showkey to make it clear what's going on.
It seems to me (I haven't tested) that
set -as terminal-overrides '*:smcup@:rmcup@'just removes\e[?1049hand\e[?1049lfrom the sequence mentioned above.o-sdn-o commentedon Oct 5, 2025
It is almost ten minutes.
The correct order (showkey should be at the end, it will accept the input stream):
o-sdn-o commentedon Oct 5, 2025
Can you test the patched version of OpenSSH: PowerShell/openssh-portable#806?
I will help you if you have any difficulties with building, only openssh-portable\contrib\win32\openssh\ssh.vcxproj needs to be built.
o-sdn-o commentedon Oct 5, 2025
Ah, right, that's because the terminal doesn't have a scrollback buffer in alternate mode. Output needs to be redirected to a file, etc. Because of this, I initially tested without enabling altbuf and found nothing.
o-sdn-o commentedon Oct 5, 2025
The ssh.exe project can be built anywhere, and then the build folder can be easily copied to another machine. I built it on Windows 10 and copied it to Windows 11.
o-sdn-o commentedon Oct 5, 2025
Clone Vcpkg Repository (*required as of September 2025 - see here for more info)
Sorry for misleading you, it's better to follow the instructions completely.
o-sdn-o commentedon Oct 5, 2025
Release.zip
o-sdn-o commentedon Oct 5, 2025
Am I correct in understanding that everything is working as expected?
o-sdn-o commentedon Oct 5, 2025
Thank you too!!!
o-sdn-o commentedon Oct 5, 2025
As far as I understand, terminal multiplexers shouldn't (never) forward DA requests from applications. Applications request the capabilities of the multiplexer they're running on. The multiplexer makes its own requests to the terminal it's running on. All requests shouldn't cross multiplexer boundaries.
o-sdn-o commentedon Oct 5, 2025
Blocking the response may cause the clipboard to stop working, as the response advertises support for clipboard operations. If there is no acknowledged response, this feature will not be activated.
o-sdn-o commentedon Oct 6, 2025
I think all the i's are dotted and crossed. Thank you all for your input and insights.