Strange character sequences (ANSI escape sequences?) leaking into shell prompt when starting/attaching Tmux

[primeos-work]

Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest version
• Search the existing issues.

Steps to reproduce

Connect to a Linux/Unix host via ssh and attach to a tmux session. Strangely the results seem to differ based on the target OS, e.g.:

• On an EoL CentOS 7 and a Fedora Linux 40 system I reliably get 61;6;7;21;22;23;24;28;32;42c (basically every time)
• On a Debian 12 host I get 0;10;1c but only on every third/fourth attempt or so

Expected behavior

I can attach to my Tmux session and it looks exactly as I left it.
This usually means that the last line of the active Tmux window/pane contains a empty shell prompt like this:

[michael@groot ~]$

Actual behavior

I get some additional random characters ("garbage") behind the prompt, e.g.:

[michael@groot ~]$ 61;6;7;21;22;23;24;28;32;42c

Error details

No response

Environment data

I am using the Windows Terminal and it doesn't matter if I uses the "Windows PowerShell", "Command Prompt", or "Git Bash". When I use "Git Bash" via "Windows Terminal" everything works as expected with /usr/bin/ssh (OpenSSH_9.7p1, OpenSSL 3.2.1 30 Jan 2024) but not with /c/Program\ Files/OpenSSH/ssh (OpenSSH_for_Windows_9.5p1, LibreSSL 3.8.2) which is why I came to the conclusion that this seems to be a OpenSSH for Windows bug. The second indication that this seems to be an OpenSSH for Windows bug is that I didn't get those unexpected character sequence with SSH_TERM_CONHOST_PARSER=0 (but that also makes the rendering much much slower and I get significant visual glitches like a green background color (probably due to the status line background color from tmux)).

Anyway, here is the desired output but I don't expect it to be relevant in this case:

Name                           Value
----                           -----
PSVersion                      5.1.19041.4894
PSEdition                      Desktop
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0...}
BuildVersion                   10.0.19041.4894
CLRVersion                     4.0.30319.42000
WSManStackVersion              3.0
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1

Version

OpenSSH_for_Windows_9.5p1, LibreSSL 3.8.2

Visuals

No response

[primeos-work]

Please also note that there are already a lot of related issues/reports but not in this repository.
I tried the following workarounds/solutions but none of them worked for me:

• set -sg escape-time 1 in ~/.tmux.conf
• I don't use any Tmux plugins (so I'm, e.g., not affected by tmux-sensible overriding escape-time)

Some links to the reports that I found:

• Strange characters appeared when entering Tmux microsoft/WSL#5931
• Terminal putting ANSI Escape Code in terminal line when attaching tmux session microsoft/terminal#16384
• Escape sequence leaking to terminal on starting/attaching tmux (over ssh) microsoft/terminal#17439
• https://serverfault.com/questions/1130064/why-is-the-windows-11-terminal-pushing-escape-sequences-to-tmux
  • Apparently those "strange characters" are "the terminal's response to an ESC [ c (\033[c) "Request terminal attributes" that was issued by the remote program [tmux]"
• https://askubuntu.com/questions/1468086/byobu-prints-out-non-standard-escape-sequences-at-startup
• tmux prints chars on session start tmux-plugins/tmux-sensible#61

Other relevant links:

• https://github.com/PowerShell/Win32-OpenSSH/wiki/TTY-PTY-support-in-Windows-OpenSSH#tty
  • Regarding SSH_TERM_CONHOST_PARSER=0 which I got from here: Using WSL via Win32-OpenSSH breaks console #670

So my conclusions are the following:

• This affects lots of people and the real source of the issue is still unknown
• Only users on Windows seem to be affected by it
• Weirdly the set -sg escape-time 1 workaround seems to resolve the Tmux issues for most users but not for me

[yoctozepto]

On OpenSSH_for_Windows_9.8 Win32-OpenSSH-GitHubp1, LibreSSL 3.8.2 as built from PowerShell/openssh-portable@414d853 it happens almost every time tmux is run and no workaround helps. But it happens only in Windows Terminal. The legacy command host is not affected so it's most likely an issue of the Windows Terminal. However, it also does not happen with WSL2-based ssh even though it's still in Windows Terminal.

[primeos-work]

Thanks for the additional data @yoctozepto! :)

I think it's the combination of the terminal and OpenSSH for Windows but that the actual bug is in OpenSSH for Windows and the terminal only matters as it will affect the response to tmux's ESC [ c (\033[c) "Request terminal attributes" (if https://serverfault.com/questions/1130064/why-is-the-windows-11-terminal-pushing-escape-sequences-to-tmux is correct).

I did run two additional tests yesterday:

• With https://github.com/alacritty/alacritty (https://github.com/alacritty/alacritty/releases/download/v0.13.2/Alacritty-v0.13.2-portable.exe) I wasn't able to trigger this bug
• With https://github.com/Eugeny/tabby (https://github.com/Eugeny/tabby/releases/download/v1.0.215/tabby-1.0.215-setup-x64.exe) I got 1;0c and only with a low probability (every 3-5 attempts or so) - vs. 61;6;7;14;21;22;23;24;28;32;42c which I get almost every time with Windows Terminal version 1.21.2361.0.

To be sure I did another test today via Ubuntu 24.04 LTS in WSL 2: I installed and started openssh-server in the Ubuntu VM/container, started a Tmux session and then did compare a "direct" terminal with an SSH connection:

• When I open a "direct" terminal to the Ubuntu system by selecting the "Ubuntu 24.04 LTS" profile on Windows Terminal I can attach to the Tmux session without triggering the bug (I didn't manage to get any "strange characters" even once)
• When I use the "Windows PowerShell" profile and OpenSSH for Windows (ssh $USER@localhost) I consistently get 61;6;7;14;21;22;23;24;28;32;42c0;10;1c every time.
  • With $env:SSH_TERM_CONHOST_PARSER = '0'; ssh localhost, the bug/problem goes away completely (although I get lot's of visual glitches / rendering issues instead...).

PS: I can also trigger the bug with echo instead of tmux like this (or echo -e '\e[c', etc.):

mweiss@groot ~ $ echo -e '\033[c'

mweiss@groot ~ $ 1;2c

[yoctozepto]

OK, so it truly is the Win32-OpenSSH - that is the common denominator here. It needs certain conditions to happen but it does not happen without it.