WSL moves my gvim/X client windows to a random virtual desktop overnight

[a-bj-q]

Windows Version

Microsoft Windoze [Version 10.0.22631.6060]

WSL Version

2.6.1.0

Are you using WSL 1 or WSL 2?

• WSL 2
• WSL 1

Kernel Version

No response

Distro Version

Release: 22.04

Other Software

VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Apr 02 2025 12:39:01)

Repro Steps

configure windows to run 6 "multiple desktops", virtual desktops if you like.
move to desktop 3
open cmd shell (dos box)
Run wsl from cmd shell
cd to /home/your-username
type "gvim foo" and add some text [ "a", blah blah, "^ESC" :w ]
[the vim window should open in desktop 3 next to the dos box]
do not close the editor
move to desktop 1 and do some windows stuff
lock the PC and allow it to sleep overnight (I'm on a Dell laptop).
the next day, unlock the laptop (log in)
type [^Windows key][TAB] to see where the windows are on which desktop
if the bug is reproduced, the gvim windows will not be on desktop 3.
if the bug is not reproduced [yet] then lock and repeat.

Expected Behavior

VIM sessions stay where they are and I don't have to go hunting every morning.

Actual Behavior

VIM sessions have moved to a different virtual desktop, the wsl and any vscode containers stay where they are.

Diagnostic Logs

I believe this is a behaviour of X, I'll try it with some other X clients and see if it also reproduces, and if so, update here.

[github-actions]

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:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The script will output the path of the log file once done.

If this is a networking issue, please use collect-networking-logs.ps1, following the instructions in Collect WSL logs for networking issues

Once 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'.

[sirredbeard]

@a-bj-q Interesting issue. Curious if this occurs with other X clients.

@OneBlue I suggest relocating this issue to microsoft/WSLg.

[a-bj-q]

WslLogs-2025-11-03_22-49-28.zip

This is now reproduced with the bundled xmessage client, e.g.:
xmessage "this should remain on desktop 3" &

the xmessage box gets moved to a.n.other desktop overnight. Log of that happening attached.

[a-bj-q]

I also have another maybe related issue, while reproducing this something worse happened which was the X server crashed:

`$me:~/pos/qemu$ X connection to :0 broken (explicit kill or server shutdown).
X connection to :0 broken (explicit kill or server shutdown).
xterm: fatal IO error 11 (Resource temporarily unavailable) or KillClient on X server ":0"
X connection to :0 broken (explicit kill or server shutdown).

[1] Exit 84 xterm
[2] Exit 1 xfontsel
[5] Exit 1 xmessage "this should remain on desktop 3"
[6]- Exit 1 xmessage "this should remain on desktop 3"`

I have a separate log of this from collect-wsl-logs.ps1
the log here just covers the more frequent window moving bug (X server stays up).

[a-bj-q]

@OneBlue Sorry clicked the wrong button, please reopen this issue (I can't reopen my own issue!???)

[jmercouris-sym]

I confirm that this exact behavior occurs with Emacs. I don't believe it is application specific.

[a-bj-q]

I confirm that this exact behavior occurs with Emacs. I don't believe it is application specific.

Thanks! Now we're reproduced it with emacs hopefully it will be taken seriously :-) gvim is usually looked at with disdain.