microsoft
Randomly added / inserted numbers on startup
Version: 1.0.0 Terminal: Wezterm
This does seem to be somehow related to usage within Wezterm, but I don't know where the issue lies. I do not have such behaviour in other shell applications.
https://github.com/user-attachments/assets/b5dd9085-2db2-4436-8802-1839f97866f0
I recorded a video of it. It only happens after opening it twice it seems.
This is most likely a leftover of the VT responses from WezTerm. The best way to investigate may be to modify this spot to log the received text into a file on disk:
https://github.com/microsoft/edit/blob/d8320588536211765332a1851abde47404ccd63f/src/sys/windows.rs#L361-L362
I suspect that this may be a race condition of some sort (not inside edit, but between edit and the terminal).
I see this added to the start of the opened text file when running edit in git-bash on Windows:
;0;rgb:0000/0000/0000;1;rgb:d4d4/2c2c/3a3a;2;rgb:1c1c/a8a8/0000;3;rgb:c0c0/a0a0/0000;4;rgb:0000/5d5d/ffff;5;rgb:b1b1/4848/c6c6;8;rgb:6060/6060/6060;9;rgb:ffff/7676/7676;10;rgb:0000/f2f2/0000;11;rgb:f2f2/f2f2/0000;12;rgb:7d7d/9797/ffff;13;rgb:ffff/7070/ffff;14;rgb:0000/f0f0/f0f0;15;rgb:ffff/ffff/ffff
Edit: I pulled the latest and now get this text
;0;rgb:0000/0000/0000
And edit shows a "go to line/column" popup populated with ffff/ffff/ffff
I do believe everyone here that this is a real issue, because I've seen this exact behavior in other projects a few times already. The only problem is that I cannot reproduce it with Windows Terminal.
If you give me debug code, i can try giving you logs or so. I don't know Rust :D
Well, to be fair... if it reproduces on Windows Terminal a log from the debug tap might be helpful! Just to see if there's an issue in input generation.
This is trivially reproducible in WezTerm, so it may be specific to the older ConPTY it ships with. I guess? In WSL you can test it with:
sh -c 'printf "\e]4;0;?;1;?;2;?;3;?;4;?;5;?;6;?;7;?\x07\e]4;8;?;9;?;10;?;11;?;12;?;13;?;14;?;15;?\x07\e]10;?\x07\e]11;?\x07\e[c"; read >/dev/null'
The expected response should be quite long. In WezTerm I get:
^[[?61;6;7;22;23;24;28;32;42c555^[\
It also doesn't react the first time I press Enter. I faintly remember an OSC ordering issue with Windows Terminal / ConPTY but I can't find it.
I've experienced this issue when using windows terminal (1.22.11751.0) and running msedit (1.2.0) within a docker container built from "mcr.microsoft.com/windows/servercore:ltsc2022".
I'm seeing the numbers "626" prepended to the file contents.
@lhecker Hope this help you to replicate the issue.
I am experiencing the same in wezterm (20240203-110809-5046fc22) and edit (1.2.0) on Windows 10. No matter the shell (cmd, powershell, wsl), edit adds the 626 at the beginning of the file. See cast below
However, the same wezterm works fine on Fedora 42 Workstation
As mentioned above, wezterm uses an older version of something called ConPTY (which we maintain). It used to be somewhat buggy and has received numerous bug fixes over the last year. I don't believe they use the latest version yet. You can steal OpenConsole.exe from a recent Windows Terminal Canary build and replace the same file in your wezterm folder.
@ekmpspete I don't have docker installed right now, but I suspect they also use ConPTY, but an even older version installed as part of the OS.
I suspect that this will be a recurring issue and likely the only way to hotfix it is by adding a literal sleep() in the startup path of edit lol. 🥲
I suspect that this will be a recurring issue and likely the only way to hotfix it is by adding a literal
sleep()in the startup path ofeditlol. 🥲
@lhecker Another solution might be to allow edit to accept OSC query responses out of sequence. You don't necessarily need to process them - if the DA1 response is received before the palette responses, you can just drop them when they eventually do arrive. Worst case is you lose out on the palette detection. The important thing is to not treat the OSC introducer as an Alt+] keystroke, and keep consuming the response until the string terminator. That's assuming the responses don't get intertwined in some way - I can't remember if that's the case.
Unless I made a mistake, I actually parse OSC sequences at all times, so this should already work as expected.
But you reminded me that I investigated this with wezterm initially, because it made it easy to reproduce and it showed that the broken output arrives straight from ConPTY itself - it's not a mangling of the application. See here, where you can see a random "555" string after the end of the DA1 response: https://github.com/microsoft/edit/issues/109#issuecomment-2916724946
OK, then it's not just the responses being out of order. It's possible the sequence is being corrupted by conpty's input statemachine, like the issue you fixed in PR #16352. If that's the case, I don't see how a delay would help. I think the only solution may be to avoid sending OSC queries to old versions of conhost, but I'm not sure how feasible that is either.
Results on Windows 10, executing edit.exe newfile in different consoles/terminal/shells:
Terminal: Windows Console Host Shell: cmd.exe: no issues Shell: git-bash.exe (Git for Windows): no issues Shell: wsl.exe / Debian bash: no issues
Modern Windows Terminal
Shell: cmd.exe: no issues
Shell: git-bash.exe: no issues
Shell: wsl.exe / Debian bash: various new file contents inserted e.g.: 525/2525a4a/46464b4/3333a8a/ebebe6e/b7b75c5/b7b7777/7777b3b/3b3be5e/5656c7c7/4646c5c5/41419c9c/fefe8181/cacad8d8/c9c9dede/dedeb9/b9b918/1818
Terminal: Mintty (Git for Windows)
Shell: cmd.exe: starts at "Go to Line:Column..." dialog with dede/dede/dede, new file contents inserted: ;0;rgb:2525/2525/2525
Shell: git-bash.exe: same
Shell: wsl.exe / Debian bash: almost same, file contents is added an extra 1;rgb:eded/
@Tabiskabis That's interesting. This hadn't occurred to me, but running edit.exe (i.e. the Windows version) from within a WSL shell will force it to go through the system conpty, so that's an easy way to reproduce the issue on Windows Terminal (at least on Windows 10 - the conpty in Windows 11 may not have the same limitations).
And looking at the Windows Terminal debug tap, we can see the OSC 4, OSC 10, and OSC 11 queries being passed through, but not the following DSR-CPR and DA queries (which will have been handled by conhost). And once edit has got the DA response, it immediately starts drawing the edit window, so that output reaches terminal before it starts replying to the OSC queries.
Assuming edit is still happy to consume those responses despite their late arrival, that shouldn't have been a problem, but somewhere along the line the response buffer is being split, so the escape sequences get corrupted. Counting the bytes in my particular palette response it looks like it's exactly on the 256-byte boundary.
In my case, the 256-byte boundary ends here:
|
v
␛]4;9;rgb:e7e7/4848/5656␛\
And that results in the trailing 56 being interpreted as keypresses. The sequences before that (including the truncated one), are safely consumed by conhost, or possibly passed through to edit. And the same goes for the ones that follow the buffer split. It's just the second half of the split sequence that's an issue.
Although I should be clear that this is just a theory. I don't know for a fact that the buffer is being split, but it seems like a reasonable deduction given the alignment with the 256-byte boundary.
ETA: I wonder if it would help to split the startup sequences in the setup_terminal function into multiple write_stdout calls (along with a flush?), so the terminal doesn't try and respond to them all at the same time.
This may be due to the fact that wsl shreds the outgoing stdin stream from the terminal to the application in 16-byte chunks. That is, the application sees the stdin buffer like this: Chunk 16 bytes, Empty, Chunk 16 bytes, Empty, Remaining chunk. If the application has requested something from the terminal, it have to wait until the last byte regardless of whether the buffer is empty, otherwise it will fly to the keyboard input.
xlinks:
- https://github.com/microsoft/WSL/issues/1638
- https://github.com/microsoft/terminal/issues/19282
Details can be obtained by looking at the log of wsl interaction via Win32API with the system.
Initial conditions: For the purpose of generating a wide stream in stdin, mouse reporting is enabled in the terminal using the vt-input-mode protocol, generating APC with mouse events (~100 bytes long per event).
Interpretation: From the log of wsl interaction with the system via Win32 API, it is clear that wsl operates two buffers to receive the stdin stream: a buffer of 1 INPUT_RECORD size + a buffer of 15 INPUT_RECORD's size. As a result, wsl sends 16-byte chunks to the application, creating gaps with an empty buffer state between these sendings.
@o-sdn-o I'm not sure those 16-byte chunks are a problem here (at least for the case where we run edit.exe from WSL) because otherwise the break would have occurred halfway through the first OSC response, and not 240 bytes later.
I also did some testing with a simple exe that outputs all the same startup queries as edit, and then tries to read back the responses. It failed in exactly the same place.
However, I could get it to work by splitting up the OSC 4 queries so they don't request more than 4 colors at a time, and inserting a DSR-CPR query after each OSC query. The DSR-CPR response needs to be read before proceeding with the next OSC query, and it also seemed to require at least a 1ms sleep between each query.
That seems a bit flaky though. It may depend on the speed of the computer, or just a matter of luck.
The ability to reproduce this issue directly depends on the program's quick reaction to the appearance of data in the stdin buffer. If the program is not fast enough, these chunks, without being read, are quickly glued together and form a complete original block.
@o-sdn-o But the app has no direct control over how fast the responses are being read, because it's conhost that is reading them and consuming them (I'm talking about the OSC responses). The trick is to get conhost to eat them completely and not return half chewed bits of them.
I see the stack layout of a running Linux console application on Windows (in WSL) as follows:
Terminal -> conhost -> kernel -> wsl -> app
| | | | |
| | | | +-- app waits (::poll()) on the stdin file descriptor
| | | +-- wsl reads INPUT_RECORDs by blocks of 16 records, converting them to text and sending them as standalone strings to the app's stdin buffer, creating breaks between them
| | +-- kernel forwards all INPUT_RECORDs at once
| +-- conhost somehow converts the vt-sequence string into an INPUT_RECORD sequence (there may also be fragmentation issues here as the same behavior has been observed without wsl in the past)
+-- terminal generates a vt-sequence as a reply to the request
The app waits (::poll()) on the stdin file descriptor and reads the whole block at once or in chunks in a loop (using non-blocking read mode). In general, when the app detects an empty stdin buffer (less data has been read than the buffer provided), it concludes that there is no more data. Wsl on its side, forwarding the original block, creates a continuous sequence of stdin buffer states filled_buffer+empty_buffer, which of course collapses (concatenated) if the data is not read immediately by the app. But if the data is read quickly enough, then a break occurs and the app is simply forced to wait (to spin) on empty stdin if they understand what is happening.
Just to be absolutely clear, the case I'm talking about was a win32 executable run from within a WSL shell. In that case there are two different conpty sessions: Windows Terminal launches wsl.exe using the OpenConsole bundled with the terminal, and wsl launches edit.exe via the system conhost.
So the stack (as I understand it) looks something like this:
Terminal <--> OpenConsole <--> WSL <--> conhost <--> edit.exe
When edit.exe sends a DA query, it only gets as far as conhost, since conhost understands DA and is able to provide a response. That query never reaches WSL or the Terminal. However, when edit.exe sends an OSC query, the sytem conhost doesn't understand it, so it passes it through to WSL, which passes it through to OpenConsole, which passes the query through to the terminal.
If the terminal then responds to that OSC query, that gets passed back in a similar way, up until the point it reaches the system conhost, which tries to parse the sequence. If you're lucky, it will simply discard it as an unknown keypress. But if a sequence doesn't arrive in a single packet, the old conhost parser can get confused, and may interpret the second part of the sequence as individual character keypresses.
The case is simpler for something like WezTerm when it's running edit.exe directly, but the effect is likely to be the same. The key point is that you have an old version of conhost somewhere between the terminal and the app. So the stack looks something like this:
WezTerm <--> conhost <--> edit.exe
It may be using a bundled version of OpenConsole that is newer than the system conhost, but if it's a version that has the same response parsing bug, I would expect it to fail in the same way. WezTerm reponds to the OSC queries, and conhost chokes on the response when one of the sequences doesn't arrive in a single packet.
The following C++ snippet for linux reproduces what I mean instantly for the case:
terminal <--> ... <--> wsl <--> linuxapp_or_conhost
Press 'x' to exit:
#include <array>
#include <iostream>
#include <unistd.h>
#include <fcntl.h>
#include <termios.h>
using namespace std::literals;
static constexpr auto c0_view = std::to_array({ "·"sv, "☺"sv, "☻"sv, "♥"sv, "♦"sv, "♣"sv, "♠"sv, "•"sv, "◘"sv, "○"sv, "◙"sv, "♂"sv, "♀"sv, "♪"sv, "♫"sv, "☼"sv, "►"sv, "◄"sv, "↕"sv, "‼"sv, "¶"sv, "§"sv, "▬"sv, "↨"sv, "↑"sv, "↓"sv, "→"sv, "←"sv, "∟"sv, "↔"sv, "▲"sv, "▼"sv, "⌂"sv });
auto buff = std::string(4096, 0);
auto debase437(auto utf8)
{
buff.clear();
for (uint8_t c : utf8)
{
if (c < 0x20) buff += c0_view[c];
else if (c == 0x7F) buff += c0_view[0x20];
else buff += c;
}
return buff;
}
int main()
{
auto flags = ::fcntl(0, F_GETFL, 0) | O_NONBLOCK;;
::fcntl(0, F_SETFL, flags);
auto backup = ::termios{};
::tcgetattr(0, &backup);
auto raw_mode = backup;
::cfmakeraw(&raw_mode);
::tcsetattr(0, TCSANOW, &raw_mode);
// msedit's inits:
std::cout << //"\x1b[?1049h"
"\x1b[?1002;1006;2004h\x1b[?1036h"
"\x1b]4;0;?;1;?;2;?;3;?;4;?;5;?;6;?;7;?\x07"
"\x1b]4;8;?;9;?;10;?;11;?;12;?;13;?;14;?;15;?\x07"
"\x1b]10;?\x07\x1b]11;?\x07"
"\r…\x1b[6n"
"\x1b[c"
<< std::flush;
auto buf = std::string(4096, 0);
auto t = 0;
while (true)
{
auto len = ::read(0, buf.data(), buf.size());
if (len > 0)
{
auto crop = std::string_view{ buf.data(), (size_t)len };
if (crop == "x") break;
std::cout << "crop=\033[7m" << debase437(crop) << "\033[m\r\n";
t = 1;
}
else if (t)
{
std::cout << "empty buffer\r\n";
t = 0;
}
}
::tcsetattr(0, TCSANOW, &backup);
std::cout << "\x1b[?1002;1006;2004l\x1b[?1036l" << std::flush;
}
Output in wsl in WT:
root@meg:/mnt/d/sources/!_tests/test_read/.vs/build/PROD-WSL-x64# ./test_read
…crop=←]4;0;rgb:0c0c/0
empty buffer
crop=c0c/0c0c
empty buffer
crop=←\
empty buffer
crop=←]4;1;rgb:c5c5/0
empty buffer
crop=f0f/1f1f
empty buffer
crop=←\
empty buffer
crop=←]4;2;rgb:1313/a
empty buffer
crop=1a1/0e0e
crop=←\
empty buffer
crop=←]4;3;rgb:c1c1/9
crop=c9c/0000
empty buffer
crop=←\
empty buffer
crop=←]4;4;rgb:0000/3
empty buffer
crop=737/dada
empty buffer
crop=←\
empty buffer
crop=←]4;5;rgb:8888/1
empty buffer
crop=717/9898
empty buffer
crop=←\
empty buffer
crop=←]4;6;rgb:3a3a/9696/dddd
empty buffer
crop=←\
empty buffer
crop=←]4;7;rgb:cccc/c
empty buffer
crop=ccc/cccc
empty buffer
crop=←\
crop=←]4;8;rgb:7676/7676/7676
empty buffer
crop=←\
empty buffer
crop=←]4;9;rgb:e7e7/4
empty buffer
crop=848/5656
empty buffer
crop=←\
empty buffer
crop=←]4;10;rgb:1616/
empty buffer
crop=c6c6/0c0c
empty buffer
crop=←\
empty buffer
crop=←]4;11;rgb:f9f9/
empty buffer
crop=f1f1/a5a5
empty buffer
crop=←\
empty buffer
crop=←]4;12;rgb:3b3b/
empty buffer
crop=7878/ffff
empty buffer
crop=←\
empty buffer
crop=←]4;13;rgb:b4b4/
empty buffer
crop=0000/9e9e
empty buffer
crop=←\
empty buffer
crop=←]4;14;rgb:6161/
empty buffer
crop=d6d6/d6d6←\
crop=←]4;15;rgb:f2f2/
empty buffer
crop=f2f2/f2f2
empty buffer
crop=←\
empty buffer
crop=←]10;rgb:cccc/cc
empty buffer
crop=cc/cccc
empty buffer
crop=←\
empty buffer
crop=←]11;rgb:0c0c/0c0c/0c0c←\←[32;2R←[?61;4;6;7;14;2
empty buffer
crop=1;22;23;24;28;32;42;52c
empty buffer
root@meg:/mnt/d/sources/!_tests/test_read/.vs/build/PROD-WSL-x64#
Output in GNOME Terminal on Ubuntu 24.04 Desktop:
sdn@ubuntu24:~$ ./test_read
…crop=←]4;0;rgb:1717/1414/2121•←]4;1;rgb:c0c0/1c1c/2828•←]4;2;rgb:2626/a2a2/6969
•←]4;3;rgb:a2a2/7373/4c4c•←]4;4;rgb:1212/4848/8b8b•←]4;5;rgb:a3a3/4747/baba•←]4;
6;rgb:2a2a/a1a1/b3b3•←]4;7;rgb:d0d0/cfcf/cccc•←]4;8;rgb:5e5e/5c5c/6464•←]4;9;rgb
:f6f6/6161/5151•←]4;10;rgb:3333/dada/7a7a•←]4;11;rgb:e9e9/adad/0c0c•←]4;12;rgb:2
a2a/7b7b/dede•←]4;13;rgb:c0c0/6161/cbcb•←]4;14;rgb:3333/c7c7/dede•←]4;15;rgb:fff
f/ffff/ffff•←]10;rgb:ffff/ffff/ffff•←]11;rgb:3030/0a0a/2424•←[3;2R←[?61;1;21;22c
empty buffer
sdn@ubuntu24:~$
But as far as I can see there's no data loss in your case. You're getting all the responses back, just split up across packets. If the app isn't handling that, that's an app problem, but edit doesn't have an issue with that as far I can see. It works fine as a Linux app when run from within WSL (assuming a terminal with the latest OpenConsole).
My test case, which involves a Windows executable run from within a WSL shell, produces three buffers that look like this:
←[?1;0c←[5;4R
5
6←\
The ←[?1;0c is a response from the system conhost to the DA request, and the ←[5;4R is a response from the system conhost to the DSR-CPR request. The 5 and 6←\ are the remnants of an OSC 4 response from Windows Terminal that made its way back from the terminal, through OpenConsole, through WSL, and then got half eaten by conhost.
The characters 5, 6, ←, and \ are bytes 257, 258, 259, and 260 in the combined response from the terminal. There are 256 bytes before that which are safely consumed by conhost, and there are more bytes following that which are also safely consumed. Those are just the bytes that got chopped off the end of a ←]4;9;rgb:e7e7/4848/5656←\ response, and thus weren't recognised as a valid escape sequence.
But as far as I can see there's no data loss in your case. You're getting all the responses back, just split up across packets. If the app isn't handling that, that's an app problem, but edit doesn't have an issue with that as far I can see. It works fine as a Linux app when run from within WSL
To test this, I split the stdin stream into 2-byte packets and added an unreasonable 150ms delay between packets for the "empty buffer" state, ~~and as a result, mouse events are dumped into keyboard input~~ all works as expected.
vtm_terminal <--> wsl <--> edit_for_linux
|
+-- responds with packets of two bytes with an interval of 150ms
UPDATE: I need to make sure that the stdin stream does not mix up keys and mouse events on the vtm_terminal side. I'm not sure about that. The example below may be due to incorrect splitting of the stdin stream on the vtm_terminal side.
UPDATE2: Despite the fact that the stdin stream is split into two-byte packets and the packets are delayed by 150ms, edit for linux works properly as expected.
I just realised there's another issue evident in the responses I'm seeing. The DSR-CPR response and DA response are actually out of order. This likely wouldn't be the case for someone on Windows 11, or with WezTerm using a more recent version of OpenConsole, but the Windows 10 conhost is ancient, so it still has bugs that were fixed in 2020 (likely even earlier). I think this particular one may be https://github.com/microsoft/terminal/pull/7583. I don't think it's a factor in the corrupted OSC responses, but I thought it's worth mentioning in case anyone is confused by the order of those sequences.
Also, digging into the code from that era, I think you can see where the 256 byte buffer is coming from: https://github.com/microsoft/terminal/blob/986f20e031d8a50321b1a640fe55c81b7e0b61cf/src/host/VtInputThread.cpp#L109-L113
That buffer size was increased in https://github.com/microsoft/terminal/pull/16470 at the end of 2023, and I thought WezTerm was using something more recent than that, but possibly only in the nightly build.
I just saw that wsl source code is open 🙃
https://github.com/microsoft/WSL/blob/feb9ad97a4532a4887bd24bf4a579bf38d11f2b7/src/windows/common/svccomm.cpp#L31-L37
tldr: Fresh OpenConsole.exe fixes the issue.
Some more tests.
Responses in stdin for the case:
wt <--> ... <--> wsl.exe <--> win10_conhost.exe <--> wsl.exe <--> ./test_read
root@meg:/mnt/d/sources/!_tests/test_read/.vs/build/PROD-WSL-x64# ./test_read
…crop=←[?1;0c
empty buffer
crop=←[6;2R
empty buffer
crop=←\f0f/1f
empty buffer
crop=1f
empty buffer
crop=←\1a1/0e
empty buffer
crop=0e
empty buffer
crop=←\c9c/00
empty buffer
crop=00
crop=←\737/dada←\
empty buffer
crop=676/7676←\
empty buffer
crop=←\
empty buffer
crop=d6d6/d6d6←\
empty buffer
crop=←\
empty buffer
root@meg:/mnt/d/sources/!_tests/test_read/.vs/build/PROD-WSL-x64#
Responses in stdin for the case (I replaced C:\WINDOWS\System32\conhost.exe with the latest OpenConsole.exe):
wt <--> ... <--> wsl.exe <--> OpenConsole.exe <--> wsl.exe <--> ./test_read
root@meg:/mnt/d/sources/!_tests/test_read/.vs/build/PROD-WSL-x64# ./test_read
…crop=←]4;0;rgb:0c0c/0
empty buffer
crop=c0c/0c0c
empty buffer
crop=←\←]4;1;rgb:c5c5/0
empty buffer
crop=f0f/1f1f
empty buffer
crop=←\
empty buffer
crop=←]4;2;rgb:1313/a
empty buffer
crop=1a1/0e0e
empty buffer
crop=←\
empty buffer
crop=←]4;3;rgb:c1c1/9
empty buffer
crop=c9c/0000
empty buffer
crop=←\
empty buffer
crop=←]4;4;rgb:0000/3
empty buffer
crop=737/dada
empty buffer
crop=←\
empty buffer
crop=←]4;5;rgb:8888/1
empty buffer
crop=717/9898
empty buffer
crop=←\
empty buffer
crop=←]4;6;rgb:3a3a/9
empty buffer
crop=696/dddd
empty buffer
crop=←\
empty buffer
crop=←]4;7;rgb:cccc/cccc/cccc
empty buffer
crop=←\
empty buffer
crop=←]4;8;rgb:7676/7
empty buffer
crop=676/7676
empty buffer
crop=←\
empty buffer
crop=←]4;9;rgb:e7e7/4
empty buffer
crop=848/5656
empty buffer
crop=←\
empty buffer
crop=←]4;10;rgb:1616/
empty buffer
crop=c6c6/0c0c
empty buffer
crop=←\
empty buffer
crop=←]4;11;rgb:f9f9/
empty buffer
crop=f1f1/a5a5
crop=←\
empty buffer
crop=←]4;12;rgb:3b3b/7878/ffff←\
empty buffer
crop=←]4;13;rgb:b4b4/
crop=0000/9e9e
empty buffer
crop=←\←]4;14;rgb:6161/
empty buffer
crop=d6d6/d6d6←\←]4;15;rgb:f2f2/f2f2/f2f2
empty buffer
crop=←\
empty buffer
crop=←]10;rgb:cccc/cc
empty buffer
crop=cc/cccc
empty buffer
crop=←\←]11;rgb:0c0c/0c0c/0c0c
empty buffer
crop=←\←[40;2R
empty buffer
crop=←[?61;4;6;7;14;21;22;23;24;28;32
empty buffer
crop=;42;52c
empty buffer
root@meg:/mnt/d/sources/!_tests/test_read/.vs/build/PROD-WSL-x64#
@o-sdn-o Thank you for this detailed analysis and testing! I was really missing this information.
By the way, I just noticed that WezTerm-windows-20250909-070512-bf9a2aee\wezterm.exe ssh (on the same Windows 10 machine) is not affected (kudos to their developers!) by the tmux issue in wt ssh.
