tmux ESC key ignored in 3.8.0

[xuefer]

1. tmux -f /dev/null # (using default setting)
2. vim -u /dev/null
3. i
4. press <ESC>, no response, does not escape from edit mode to normal mode, have to press ctrl+c

without tmux it's fine

$ tmux -V
tmux 3.4

# tmux -V
tmux 3.5a

 $ uname -a
Linux X 6.6.87.2-microsoft-standard-WSL2 #1 SMP PREEMPT_DYNAMIC Thu Jun  5 18:30:46 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux

os: Windows 10
guest:

$ cat /etc/os-release
PRETTY_NAME="Ubuntu 24.04.2 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
VERSION="24.04.2 LTS (Noble Numbat)"
VERSION_CODENAME=noble
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=noble
LOGO=ubuntu-logo

[mintty]

Not sure what you mean by "press no response". The normal behaviour of vi (and I assume vim) on pressing i is not to show anything. It works however, in tmux the same way as without, for me.

[xuefer]

Not sure what you mean by "press no response". The normal behaviour of vi (and I assume vim) on pressing i is not to show anything. It works however, in tmux the same way as without, for me.

i means press <ESC> (i should have used the code block syntax)

[mintty]

OK, as I said, "it works", which mean I can insert something after "i", then press ESC, and vi will place the cursor on the last character just entered (which is, by the way, the most crazy thing any editor might do, and enough reason not to use this crappy software...)
From there I can exit normally (:q!). If that's different for you, it may need to be analysed further but I doubt it has anything to do with mintty or wsltty. Except maybe, if the terminal was put into some special ESC mode before running vi. Please try this:
kill -9 the running vi session (from another terminal), then (in the shell, on the command line) press ^V, then ESC. What does it echo?

[xuefer]

vim is easier to see example, and yes ^V is even better
same problem in command line bash/zsh input under tmux. ^V followed by ESC without tmux gives ^[ while in tmux it shows nothing

strace the running zsh (under tmux) or tmux output nothing after i press ESC key.
tried renaming Roaming\wsltty to Roaming\wsltty.backup, tried turning off UTF-8 mode in region setting, same

any more tips to track this down?

[xuefer]

run wsl.exe under cmd.exe, ^V ESC works

as you suggested, instead of killing vim i kill tmux
restart mintty
kill -9 pid of tmux client, ^V ESC works ^C doesn't works, ^V ESC work, run reset, ^C works, ^V ESC works

restart mintty
kill -9 pid of tmux server, [server exited unexpectedly], ^C doesn't works, ^V ESC doesn't work, run reset, ^C works, ^V ESC still doesn't work

run mintty+tmux
run cmd.exe+wsl.exe, run tmux attach
kill -9 pid of tmux server, [server exited unexpectedly], ^C doesn't works in both mintty and cmd+wsl (expected), ^V ESC doesn't work in mintty but works in cmd+wsl, run reset, ^C works, ^V ESC still doesn't work

behavior of ^C is expected, can be restore by reset. but ^V ESC is strange

[xuefer]

reproduced without tmux

# printf "\\33[?7727h"

start the mode and ^V ESC fail

# printf "\\33[?7727l"

restore the mode and ^V ESC works

[mintty]

reproduced without tmux

Thanks, that confirms what I was trying to detect with my suggested test.
This issue has been discussed before in mintty/mintty#1308. Don't have the time to check right now, I think there was a workaround by updating tmux. It's not a mintty/wsltty bug though.

[xuefer]

reproduced without tmux

Thanks, that confirms what I was trying to detect with my suggested test. This issue has been discussed before in mintty/mintty#1308. Don't have the time to check right now, I think there was a workaround by updating tmux. It's not a mintty/wsltty bug though.

in my test it's not relative to tmux but wsltty

it works in mintty 3.7.8 (and cmd.exe+wsl.exe)

$ printf "\\33[?7727h"
$ ^[O[       (by press ^V ESC)

not working in wsltty 3.8.0

$ printf "\\33[?7727h"
$ ^     (by press ^V ESC)

[mintty]

Ah, I see. Thanks for the simplified test case.
For some reason I don't understand the updated README.md file did not make it into the repository. I've fixed that.
Please check the seccion Launching WSL and follow the linked instructions to replace your Windows conhost layer by its updated version OpenConsole from the Windows Terminal project. The new version shall eventually be deployed with Windows updates but unfortunately it isn't yet. I know this is still a bit bothering but it's the only way to get the wsl.exe gateway method work transparently (which also fixes this issue). And it was overdue to make this change as an increasing number of people was reporting problems with the previous wsltty launching method with the wslbridge gateway.
Sorry for the inconvenience.

[xuefer]

thank you. took some effort to set permission to overwrite the file. it would be nice if mintty can uses OpenConsole.exe by default if found in %PATH% before trying conhost.exe

[mintty]

So I assume the issue got fixed for you?
How did you actually overwrite the file. I could not, and the instructions say you should first move it away (rename it), then copy the replacement to the name conhost.exe.
Mintty does not involve conhost.exe, it is implicitly involved by the wsl.exe gateway, and I did not find a way to redirect its usage somehow. It's simply part of Windows and its invocation is hard-coded at various places (e.g. from cmd.exe), so it seems its substitution in place is the only way.

[xuefer]

So I assume the issue got fixed for you? How did you actually overwrite the file. I could not, and the instructions say you should first move it away (rename it), then copy the replacement to the name conhost.exe. Mintty does not involve conhost.exe, it is implicitly involved by the wsl.exe gateway, and I did not find a way to redirect its usage somehow. It's simply part of Windows and its invocation is hard-coded at various places (e.g. from cmd.exe), so it seems its substitution in place is the only way.

yes. set conhost.exe owner to myself (was TrustedInstaller). then enable inheritance which give enough permission to rename the file

[xuefer]

there're still problem with vim using openconsole conhost.exe, cursor is in wrong position after vim ctrl+o + exit

echo abc > abc.txt
vim -u /dev/null -N abc.txt
:q

this leaves following text on screen, everything seems ok and expected

xuefer@XuefersAero15 ~
$ vim abc.txt
xuefer@XuefersAero15 ~
$ _ (cursor _ is here after a space)

however:

echo abc > abc.txt
vim -u /dev/null -N abc.txt
o
<ESC>
ctrl+o
:qa! (only : is shown, no q a ! no cursor)
<ENTER>

[mintty]

I do not reproduce the latter behahiour, but let's not mix issues and discuss that in the other issue if desired.