You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
mouse support stops working upgrading to 3.3.7, 3.3.8 #573
Thanks for flagging this. I went looking for it properly rather than guessing, and I could not make set -g mouse on fail on 3.3.7. Here is exactly what I checked, so you can tell me which part looks different on your machine.
What I tested on 3.3.7
Every route you could turn the mouse on, checking both that the option reads back and that the wheel actually does something:
route
result
fresh session default
on
set-option -g mouse on at runtime
on
set -g mouse on (alias)
on
set -g mouse off then back on
toggles correctly
set -g mouse on in the config file at startup
on
set-option -g mouse on in config
on
set -g mouse 1 in config
on
setw -g mouse on in config
on
set -gq mouse on in config
on
And the behaviour behind the option:
wheel with mouse on: pane enters copy mode, so the wheel is being acted on
wheel with mouse off: nothing happens, so the gate works in both directions
click to focus a pane: focus moved to the clicked pane correctly
wheel over a full screen TUI application: delivered
wheel over an application that enables mouse the Win32 console way, with no DECSET at all: delivered
So the option plumbing itself is healthy on 3.3.7.
What I think may actually have bitten you
3.3.7 did change mouse behaviour in two places. One of them is a genuine bug that I found and fixed today while working #570: psmux was reporting every wheel notch at the centre of the pane instead of at your pointer. Fixed in 7435244.
If your editor or terminal application has more than one window inside a single psmux pane, a file tree beside an editor for example, that bug meant the wheel scrolled whichever inner window happened to sit at the pane centre rather than the one you were pointing at. That very easily reads as "the mouse stopped working". Details are in #570.
3.3.7 also tightened when clicks and bare pointer motion get forwarded into a pane, so that container shells stop receiving stray escape sequences (#349). That gating keys off the application announcing a mouse mode. If your case is a click that no longer reaches something, this is the most likely suspect and I want to see it.
What would help me
Could you tell me:
Which terminal you run psmux in (Windows Terminal, Alacritty, WezTerm, conhost, over SSH)
What "mouse" means in your workflow: wheel scrolling, clicking to switch pane, dragging to select text, or the mouse inside a specific application
Which application is in the pane when it fails, and whether it fails at a shell prompt too
Whether 3.3.6 genuinely worked for the same action on the same machine
Output of psmux show-options -g -v mouse while it is misbehaving
A one line "wheel does nothing in nvim in Windows Terminal, worked in 3.3.6" is plenty. With a single line to go on I risk fixing the wrong thing, and I would rather fix yours.
@psmux thanks to choco i was able to downgrade without killing psmux . THe downgraded version 3.3.6 works flawlessly with my mouse across all terminal emulators. Able to itneract with pane, scroll all gud..
Windows Server 2022 was the missing piece. That single detail explains it, and I owe you an apology for my earlier reply: I tested every route to turn the option on, which is why I found nothing, when the option was never the problem. Thank you for going back and confirming 3.3.6 works on the same machine, that is what made this findable.
What is wrong
Windows Server 2022 is OS build 20348. In 3.3.7 I added a gate (c92aec0, for #457) that refuses to enable mouse reporting on any Windows build below 22523. Your build is under that line.
The gate exists for a real reason. On Windows 10 build 19045, enabling mouse meant the first click sent a mouse report into the console host, which fast failed with 0xc0000409 and killed the pane process along with it. Someone lost a long running session to a single click. So I chose a dead mouse over a dead session.
What I got wrong is the width of the net. The crash was only ever measured on Windows 10 era console hosts. I drew the line at 22523 and swept in every build beneath it, including Server 2022, which by your account had been running mouse perfectly happily for the whole 3.3.6 era.
The mechanism, since it explains why the option still reads on: psmux writes the mouse enable sequence through a raw WriteFile on the console handle, specifically to bypass ConPTY on builds where ConPTY eats it rather than passing it to your terminal. That bypass is the only thing that puts your terminal into mouse reporting on a build like yours. 3.3.7 gates it off, your terminal is never told to report mouse, so it never sends any, so psmux never sees a click or a wheel notch. The mouse option is set correctly and completely irrelevant, which is exactly the screenshot you sent.
I proved this at byte level rather than by reading code, hosting a real attach inside a pseudo console and dumping every outward byte:
One more thing that widened this: in 3.3.7 I also started routing WezTerm through the same input path as SSH (#468, so WezTerm's mouse bytes stop leaking into panes as text). That means local WezTerm on a sub 22523 build now inherits this gate too, where in 3.3.6 it used a different path and was unaffected.
I have deliberately not lowered the threshold. I do not have crash data for 20348's console host, and if I guess wrong the failure mode is your session dying on a click, which is worse than what you have now. Guessing with someone else's sessions is not a trade I get to make.
What I did instead is give you the lever that did not exist. Setting
$env:PSMUX_FORCE_MOUSE="1"
before attaching overrides the gate and restores mouse on your build. Put it in your PowerShell profile to make it permanent. It works in the other direction too ("0"), for anyone on a modern build whose console host misbehaves. The default is completely unchanged, so nobody on 19045 loses the crash protection.
What would help me
Two things, and the first one decides whether the above is even your bug:
Are you SSHing into the Server 2022 box, or sitting at it? This matters enormously. If you are SSHing in, everything above explains you exactly, and it also explains why two unrelated terminals broke identically, because the cause is on the server side and has nothing to do with the terminal. If instead you run Alacritty locally on the machine itself, I measured that path as byte identical between 3.3.6 and 3.3.7, and something else is going on that I have not found yet.
Does PSMUX_FORCE_MOUSE=1 bring your mouse back? You would need a build from master, or the next release. If it does, that confirms the root cause on your actual hardware, which is the one link I could not close from here, since this machine is on a modern build and I can only tell psmux to pretend otherwise. If it does not, this analysis is wrong and I want to know.
And a warning that comes with it: if a click ever kills your session while that variable is set, unset it immediately and tell me. That would mean Server 2022's console host has the same fault as Windows 10's, and the threshold is right where it is.
If you confirm 20348 is safe, I will lower the threshold properly so nobody on Server 2019 or 2022 has to set anything at all. Your evidence is what unlocks that, so I would rather wait for it than ship a guess.
psmux 3.3.8 is released and contains the fix for this (the ConPTY mouse build gate escape hatch, commit 237d93f). Update via winget, scoop, choco, cargo install psmux, or the release page. Please retest on 3.3.8 and let me know; if mouse support works again for you this can be closed.
A quick verified-install update for 3.3.8. Scoop is confirmed working end to end on a real machine (hash check passes, session creation, keys and capture all good), and it is already in scoop's main bucket so no extra bucket is needed:
scoop install psmux
WinGet is still serving 3.3.7 while Microsoft validates the 3.3.8 submission (microsoft/winget-pkgs PR 420116); until that merges, use scoop, Chocolatey, the installer from the release page, or cargo install psmux. I will keep an eye on the winget merge.
Thanks for the correction, and your instinct about the stale session is exactly right, with one detail that matters: a session created under 3.3.6 keeps its 3.3.6 server process alive even after you upgrade the binary, so any test against that session is testing the old code. psmux kill-server (or a reboot) and a fresh session is the only clean test.
That said, seeing the problem on a genuinely fresh 3.3.8 session would not surprise me, and here is the honest state of it: 3.3.8 was tagged on 2026-08-18, and the substantial mouse path fixes landed on master after that tag. That includes the wheel attribution rework (7199f07), the gate that stops psmux writing mouse reports into applications that never asked for them (1357bc1, issue #598), and the registration keepalive that stops the terminal falling back to arrow key scrolling (9c7e44c, issue #597). The codex symptom you originally reported is precisely the #597 and #598 pair. So 3.3.8, even fresh, does not contain the full fix set for your scenario.
then start a fresh session and try codex again. If you cannot build, the next release will include all of it and I will post here when it ships. Either way, if a fresh session on master still misbehaves for you, that is new information and I want to know.
Hi, @laciferin2024
This might be unsolicited advice, but a new version of psmux—version 3.4.0 (official release) —has been released. It includes fixes for many issues, including the one you’ve been experiencing. You can install it via winget, so I’d recommend giving it a try.
I tested the mouse on Windows Server 2022 conditions (build 20348) against 3.3.6, 3.4.0 and master. Local terminals like WezTerm and Alacritty work on all of them, because they ship their own console host. The one case that still differs from 3.3.6 by default is connecting over SSH to a Server 2022 machine: since 3.3.7 psmux does not turn mouse reporting on there, because older console hosts could crash with it (#457). In 3.4.0 you can turn it back on yourself:
$env:PSMUX_FORCE_MOUSE="1"
set before starting psmux (for example in your PowerShell profile on the server).
Could you tell me two things? Do you reach the machine over SSH, or with a terminal running on the machine itself (which one)? And if PSMUX_FORCE_MOUSE=1 makes the mouse work for you, does psmux stay stable with it on? That tells me whether Server 2022's console host has the old crash, and whether I can safely lift the restriction there by default.
Hi @laciferin2024
I installed and tested Windows Server 2022 using Hyper-V on Windows11 Pro (26H2) machine.
Test environment
OS: Windows Server 2022 Standard Evaluation (Desktop) on Hyper-V
version: 21H2, OS build: 20348.5622
Windows Terminal 1.25.3131.0 (winget installed)
psmux 3.4.0 (officeial release, winget installed)
In my config, set set -g mouse on.
1).on the Server itself
The mouse works well. (can change panes or windows)
2).over SSH ( from Windows11 )
The mouse doesn't work, But PSMUX_FORCE_MOUSE=1 makes the mouse work properly. It appears to be running stably.
@tanaeakihiko thank you so much for setting up a whole Windows Server 2022 VM just to check this. That is exactly the measurement this issue needed: on the server itself the mouse works, and over SSH it works once PSMUX_FORCE_MOUSE=1 is set, and stays stable. It matches what I saw on build 20348.
@laciferin2024 so for your setup (SSH into Server 2022), please set PSMUX_FORCE_MOUSE=1 in the environment of the psmux server on that machine, for example in your PowerShell profile there:
$env:PSMUX_FORCE_MOUSE='1'
then start a fresh server (psmux kill-server once, then psmux again) so it picks the variable up. psmux leaves mouse reporting off by default over SSH on that build only because older console hosts could crash with it, and this switch is the way to opt in. If it works for you too, feel free to close this, and if anything still misbehaves, tell me and I will dig in.
Activity
psmux commentedon Aug 15, 2026
Thanks for flagging this. I went looking for it properly rather than guessing, and I could not make
set -g mouse onfail on 3.3.7. Here is exactly what I checked, so you can tell me which part looks different on your machine.What I tested on 3.3.7
Every route you could turn the mouse on, checking both that the option reads back and that the wheel actually does something:
onset-option -g mouse onat runtimeonset -g mouse on(alias)onset -g mouse offthen backonset -g mouse onin the config file at startuponset-option -g mouse onin configonset -g mouse 1in configonsetw -g mouse onin configonset -gq mouse onin configonAnd the behaviour behind the option:
So the option plumbing itself is healthy on 3.3.7.
What I think may actually have bitten you
3.3.7 did change mouse behaviour in two places. One of them is a genuine bug that I found and fixed today while working #570: psmux was reporting every wheel notch at the centre of the pane instead of at your pointer. Fixed in 7435244.
If your editor or terminal application has more than one window inside a single psmux pane, a file tree beside an editor for example, that bug meant the wheel scrolled whichever inner window happened to sit at the pane centre rather than the one you were pointing at. That very easily reads as "the mouse stopped working". Details are in #570.
3.3.7 also tightened when clicks and bare pointer motion get forwarded into a pane, so that container shells stop receiving stray escape sequences (#349). That gating keys off the application announcing a mouse mode. If your case is a click that no longer reaches something, this is the most likely suspect and I want to see it.
What would help me
Could you tell me:
psmux show-options -g -v mousewhile it is misbehavingA one line "wheel does nothing in nvim in Windows Terminal, worked in 3.3.6" is plenty. With a single line to go on I risk fixing the wrong thing, and I would rather fix yours.
Leaving this open until I hear back.
laciferin2024 commentedon Aug 16, 2026
Terminals: Alacritty, Wezterm
I was able to switch panes with my mouse but not anymore , same with scroll . Scroll not working.
I m using windows server 2022.
laciferin2024 commentedon Aug 16, 2026
@psmux thanks to choco i was able to downgrade without killing psmux . THe downgraded version 3.3.6 works flawlessly with my mouse across all terminal emulators. Able to itneract with pane, scroll all gud..
I guess a serious bug was intro'ed in 3.3.7
fix(#573): give the ConPTY mouse gate an escape hatch
psmux commentedon Aug 16, 2026
Windows Server 2022 was the missing piece. That single detail explains it, and I owe you an apology for my earlier reply: I tested every route to turn the option on, which is why I found nothing, when the option was never the problem. Thank you for going back and confirming 3.3.6 works on the same machine, that is what made this findable.
What is wrong
Windows Server 2022 is OS build 20348. In 3.3.7 I added a gate (c92aec0, for #457) that refuses to enable mouse reporting on any Windows build below 22523. Your build is under that line.
The gate exists for a real reason. On Windows 10 build 19045, enabling mouse meant the first click sent a mouse report into the console host, which fast failed with 0xc0000409 and killed the pane process along with it. Someone lost a long running session to a single click. So I chose a dead mouse over a dead session.
What I got wrong is the width of the net. The crash was only ever measured on Windows 10 era console hosts. I drew the line at 22523 and swept in every build beneath it, including Server 2022, which by your account had been running mouse perfectly happily for the whole 3.3.6 era.
The mechanism, since it explains why the option still reads
on: psmux writes the mouse enable sequence through a rawWriteFileon the console handle, specifically to bypass ConPTY on builds where ConPTY eats it rather than passing it to your terminal. That bypass is the only thing that puts your terminal into mouse reporting on a build like yours. 3.3.7 gates it off, your terminal is never told to report mouse, so it never sends any, so psmux never sees a click or a wheel notch. Themouseoption is set correctly and completely irrelevant, which is exactly the screenshot you sent.I proved this at byte level rather than by reading code, hosting a real attach inside a pseudo console and dumping every outward byte:
One more thing that widened this: in 3.3.7 I also started routing WezTerm through the same input path as SSH (#468, so WezTerm's mouse bytes stop leaking into panes as text). That means local WezTerm on a sub 22523 build now inherits this gate too, where in 3.3.6 it used a different path and was unaffected.
The fix, pushed as 237d93f
I have deliberately not lowered the threshold. I do not have crash data for 20348's console host, and if I guess wrong the failure mode is your session dying on a click, which is worse than what you have now. Guessing with someone else's sessions is not a trade I get to make.
What I did instead is give you the lever that did not exist. Setting
before attaching overrides the gate and restores mouse on your build. Put it in your PowerShell profile to make it permanent. It works in the other direction too (
"0"), for anyone on a modern build whose console host misbehaves. The default is completely unchanged, so nobody on 19045 loses the crash protection.What would help me
Two things, and the first one decides whether the above is even your bug:
Are you SSHing into the Server 2022 box, or sitting at it? This matters enormously. If you are SSHing in, everything above explains you exactly, and it also explains why two unrelated terminals broke identically, because the cause is on the server side and has nothing to do with the terminal. If instead you run Alacritty locally on the machine itself, I measured that path as byte identical between 3.3.6 and 3.3.7, and something else is going on that I have not found yet.
Does
PSMUX_FORCE_MOUSE=1bring your mouse back? You would need a build from master, or the next release. If it does, that confirms the root cause on your actual hardware, which is the one link I could not close from here, since this machine is on a modern build and I can only tell psmux to pretend otherwise. If it does not, this analysis is wrong and I want to know.And a warning that comes with it: if a click ever kills your session while that variable is set, unset it immediately and tell me. That would mean Server 2022's console host has the same fault as Windows 10's, and the threshold is right where it is.
If you confirm 20348 is safe, I will lower the threshold properly so nobody on Server 2019 or 2022 has to set anything at all. Your evidence is what unlocks that, so I would rather wait for it than ship a guess.
Leaving this open until I hear back.
psmux commentedon Aug 18, 2026
psmux 3.3.8 is released and contains the fix for this (the ConPTY mouse build gate escape hatch, commit 237d93f). Update via winget, scoop, choco, cargo install psmux, or the release page. Please retest on 3.3.8 and let me know; if mouse support works again for you this can be closed.
psmux commentedon Aug 19, 2026
A quick verified-install update for 3.3.8. Scoop is confirmed working end to end on a real machine (hash check passes, session creation, keys and capture all good), and it is already in scoop's main bucket so no extra bucket is needed:
WinGet is still serving 3.3.7 while Microsoft validates the 3.3.8 submission (microsoft/winget-pkgs PR 420116); until that merges, use scoop, Chocolatey, the installer from the release page, or cargo install psmux. I will keep an eye on the winget merge.
laciferin2024 commentedon Aug 24, 2026
Thanks @psmux , i used choco and
3.3.8does have the patch on.[-]mouse support stops working upgrading to 3.3.7[/-][+]mouse support stops working upgrading to 3.3.8[/+][-]mouse support stops working upgrading to 3.3.8[/-][+]mouse support stops working upgrading to 3.3.7, 3.3.8[/+]laciferin2024 commentedon Aug 25, 2026
@psmux correction i see the issue is back:
I should have created a new tmux session , instead of testing on already created session with 3.3.6
psmux commentedon Sep 3, 2026
Thanks for the correction, and your instinct about the stale session is exactly right, with one detail that matters: a session created under 3.3.6 keeps its 3.3.6 server process alive even after you upgrade the binary, so any test against that session is testing the old code.
psmux kill-server(or a reboot) and a fresh session is the only clean test.That said, seeing the problem on a genuinely fresh 3.3.8 session would not surprise me, and here is the honest state of it: 3.3.8 was tagged on 2026-08-18, and the substantial mouse path fixes landed on master after that tag. That includes the wheel attribution rework (7199f07), the gate that stops psmux writing mouse reports into applications that never asked for them (1357bc1, issue #598), and the registration keepalive that stops the terminal falling back to arrow key scrolling (9c7e44c, issue #597). The codex symptom you originally reported is precisely the #597 and #598 pair. So 3.3.8, even fresh, does not contain the full fix set for your scenario.
If you can build, this picks up everything:
then start a fresh session and try codex again. If you cannot build, the next release will include all of it and I will post here when it ships. Either way, if a fresh session on master still misbehaves for you, that is new information and I want to know.
test(#629): trace which branch consumes a wheel notch, and pin the SS…
tanaeakihiko commentedon Oct 17, 2026
Hi, @laciferin2024
This might be unsolicited advice, but a new version of psmux—version 3.4.0 (official release) —has been released. It includes fixes for many issues, including the one you’ve been experiencing. You can install it via
winget, so I’d recommend giving it a try.test(#573): make the mouse gate suite safe to run, and cover the SSH …
psmux commentedon Oct 17, 2026
@laciferin2024 an update, and thank you @tanaeakihiko for pointing to 3.4.0.
I tested the mouse on Windows Server 2022 conditions (build 20348) against 3.3.6, 3.4.0 and master. Local terminals like WezTerm and Alacritty work on all of them, because they ship their own console host. The one case that still differs from 3.3.6 by default is connecting over SSH to a Server 2022 machine: since 3.3.7 psmux does not turn mouse reporting on there, because older console hosts could crash with it (#457). In 3.4.0 you can turn it back on yourself:
set before starting psmux (for example in your PowerShell profile on the server).
Could you tell me two things? Do you reach the machine over SSH, or with a terminal running on the machine itself (which one)? And if
PSMUX_FORCE_MOUSE=1makes the mouse work for you, does psmux stay stable with it on? That tells me whether Server 2022's console host has the old crash, and whether I can safely lift the restriction there by default.tanaeakihiko commentedon Nov 12, 2026
Hi @laciferin2024
I installed and tested Windows Server 2022 using Hyper-V on Windows11 Pro (26H2) machine.
Test environment
OS: Windows Server 2022 Standard Evaluation (Desktop) on Hyper-V
version: 21H2, OS build: 20348.5622
Windows Terminal 1.25.3131.0 (winget installed)
psmux 3.4.0 (officeial release, winget installed)
In my config, set
set -g mouse on.1).on the Server itself
The mouse works well. (can change panes or windows)
2).over SSH ( from Windows11 )
The mouse doesn't work, But PSMUX_FORCE_MOUSE=1 makes the mouse work properly. It appears to be running stably.
psmux commentedon Nov 13, 2026
@tanaeakihiko thank you so much for setting up a whole Windows Server 2022 VM just to check this. That is exactly the measurement this issue needed: on the server itself the mouse works, and over SSH it works once
PSMUX_FORCE_MOUSE=1is set, and stays stable. It matches what I saw on build 20348.@laciferin2024 so for your setup (SSH into Server 2022), please set
PSMUX_FORCE_MOUSE=1in the environment of the psmux server on that machine, for example in your PowerShell profile there:then start a fresh server (
psmux kill-serveronce, thenpsmuxagain) so it picks the variable up. psmux leaves mouse reporting off by default over SSH on that build only because older console hosts could crash with it, and this switch is the way to opt in. If it works for you too, feel free to close this, and if anything still misbehaves, tell me and I will dig in.