Repository navigation
wslc treats IME commit of 【】 as the Ctrl-P Ctrl-Q detach sequence #41958
Description
Windows Version
Microsoft Windows [Version 10.0.26200.9445]
WSL Version
3.0.3.0 (wslc --version prints wslc 3.0.3.0)
Are you using WSL 1, WSL 2, or WSLC?
- WSL 2
- WSL 1
- WSLC
Kernel Version
Not applicable. The stall is in wslc.exe on the Windows side, before the guest reads the input.
Distro Version
WSLc container. The guest is an Arch Linux userspace started with wslc exec -it.
Other Software
noctty 1.3.131. The same input path is wslc exec -it, so the terminal is only how the keys reach the console.
Repro Steps
wslc exec -itinto a container and runcat.- With a Japanese IME, commit the conversion
【】(U+3010, U+3011). Pasting those two characters back to back does the same thing.
Expected Behavior
cat prints 【】 and keeps accepting input.
Actual Behavior
Input stops. Further keystrokes never reach the guest. The committed text does not show up as an ongoing session. Output from the guest still arrives. This is the same state as the hard-coded detach sequence, Ctrl-P then Ctrl-Q.
wslc 3.0.3 matches the detach sequence against the low byte of each UTF-16 key:
ConsoleService.cppline 108 setsstd::vector<char> detachSequence{0x10, 0x11};with a TODO to make it configurable.HandleIO.cppline 1126 appendsKeyEvent.uChar.AsciiChar.
ReadConsoleInputExW fills uChar with a UTF-16 code unit, and AsciiChar is only the low 8 bits. U+3010 is 0x3010 and U+3011 is 0x3011, so the low bytes are 0x10 and 0x11. Two characters in a row match Ctrl-P Ctrl-Q. wslc forwards those two characters, then stops reading the keyboard.
A non-ASCII character should break a partial match, and the comparison should use the whole code unit (or the UTF-8 that is forwarded), not AsciiChar.
This was isolated while reporting the freeze against noctty. noctty delivers U+3010 and U+3011 intact. A child that replays this input loop stops reading immediately after 【】, and keeps reading after 「」 or 日本. Details and the maintainer's notes: amanthanvi/noctty#395
Diagnostic Logs
wslc --version → wslc 3.0.3.0
Activity
github-actions commentedon Oct 16, 2026
Logs are required for review from WSL team
If this a feature request, please reply with '/feature'. If this is a question, reply with '/question'.
Otherwise, please attach logs by following the instructions below, your issue will not be reviewed unless they are added. These logs will help us understand what is going on in your machine.
How to collect WSL logs
Download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:
The script will output the path of the log file once done.
If this is a networking issue, please use
.\collect-wsl-logs.ps1 -LogProfile networkinginstead, following the instructions in Collect WSL logs for networking issuesOnce completed please upload the output files to this GitHub issue.
See Collect WSL logs (recommended method).
If you choose to email these logs instead of attaching them to the bug, please send them to wsl-gh-logs@microsoft.com with the GitHub issue number in the subject, and include a link to your GitHub issue comment in the message body, and reply with '/emailed-logs'.
wtcttn commentedon Oct 16, 2026
Diagnostic logs from
collect-wsl-logs.ps1(master, without-Dump):https://gist.github.com/wtcttn/2a548f6d8591554d1d88bccf5c6c18b2
The archive is base64-encoded there. Decode
WslLogs-2026-10-16_22-46-30.tar.gz.b64as described inREADME.txtin that gist. Original size is 580624 bytes.wslc --versioniswslc 3.0.3.0.【】is displayed, and keyboard input stops after that.The collector ran in an elevated PowerShell session. That session could not see the
wslc-devcontainer (WSLC_E_CONTAINER_NOT_FOUND), and attaching to its console was denied, sologs.etlmay not contain the detach. The registry export, Windows version,.wslconfig, and service logs are in the archive.ggarzia-MSFT commentedon Oct 16, 2026
Thanks for reporting this bug, I was able to repro. See #41960 for the fix