microsoft
Random letters are inserted on startup
When opening edit over ssh session, the first line shows this encoding pattern: c/0000cccc/cccc/ccccd6d6/d6d6
Repro steps: Enable SSH on Windows machine. Connect to ssh session. Download and install edit Run edit
Observed results: When opened the line number column is shifted 1 char to the right and some kind of encoding string is presented: c/0000cccc/cccc/ccccd6d6/d6d6.
Expected results: edit should run without issues under a standard ssh session.
Some other misalignment issues are also observable under ssh session:"
Can you clarify how you are using ssh?
Does the behaviour occur in all configurations?
Does using conhost make a difference in comparison to Windows Terminal?
- Windows SSH client to Windows SSHD server
- Windows SSH client to Linux SSHD server
- Linux SSH client to Windows SSHD server
- Linux SSH client to Linux SSH server
The encoding string is the initial OSC 4 and OSC 10 request (request the color palette / theme from the terminal). This indicates that parts of the response are dropped before they arrive in Edit. However, the output also looks like there are bits being dropped, which is worrying.
I loosely remember working on an issue like this for Windows Terminal a year ago or something. Can you check what version of Windows Terminal you're using? Click on the drop-down menu for the profile and then open the About dialog.
Also please include ssh versions. I have not seen this issue running from conhost. (since windows terminal isn't supported on ltsc2019 I can't test that)
This appears to be a similar/the same issue I'm seeing with docker in #377. I didn't see this issue until after I created that; I can close if we'd rather track it here.
This is happening with Windows Terminal 1.22.11141.0; it does not happen with conhost.
[...] it does not happen with conhost.
FYI: The reason this doesn't happen with conhost is most likely because it doesn't support those OSC sequences to begin with.
What I suspect all of these cases have in common is that they're using older versions of ConPTY. ConPTY was not particularly robust until somewhat recently.
Edit: Thinking about this more, inefficiencies in ConPTY and SSH (similar to https://github.com/PowerShell/openssh-portable/pull/771) could be stacking up to lead to an increased latency. We should try bumping up the ESC timeout from 50ms to 100ms and see if that fixes it.
The issue running through Docker still persists in 1.2
Sometimes the "1" will show up in the proper place in addition to the upper right (but it still has the c0c inserted).
Can you clarify how you are using ssh?
Does the behaviour occur in all configurations?
Does using conhost make a difference in comparison to Windows Terminal?
- Windows SSH client to Windows SSHD server
- Windows SSH client to Linux SSHD server
- Linux SSH client to Windows SSHD server
- Linux SSH client to Linux SSH server
Using native SSH server and clients from Windows.
Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0
Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0
Happens when using native OpenSSH client from Windows to Windows. Version (9.5.4.1) No difference from connhost vs Windows Terminal when using native ssh.exe.
Do not happen when connecting from Linux SSH client or Windows Putty client to Windows SSH Server.
I have the same problem. I am connecting with ssh from Windows 11 to Windows 10. The host on the remote system is powershell. I got the escape codes inserted to the file, when I open edit. this happens, if I just open "edit", then the characters are inserted into a new empty file. But this also happens, if I open it inderectly with git -c core.editor=edit config --global -e. Then the git configuration is opened, but the escape codes are inserted at the beginning of the file.
If I close the file, and open it again inside edit, no characters are inserted into the file.
My SSH client version (on Windows 11) is: OpenSSH_for_Windows_9.5p1, LibreSSL 3.8.2 My SSH server version (on Windows 10) is: OpenSSH_for_Windows_9.5p1, LibreSSL 3.8.2
My Windows 11 version is: 10.0.26100.3476 (24H2) My Windows 10 version is: 10.0.19045.5796 (22H2)
My Windows Terminal Version is: 1.22.11141.0
And for reference, the problem does not happen, if I use conhost. ConEmu also seems to not produce this error.
I experience a similar behavior when using it via SSH from an Ubuntu 25.10 with ptyxis (the new default terminal emulator). It the enters ;rgb:5757/e3e3/8989 and shows the "Go to line" modal dialog on top. Both do not happen if ran through a virtual tty aka Ctrl-Alt-F3. edit is running on Windows Server 2022 LTSC.
