Issue with WSL losing remote connection randomly - Cannot reconnect. Please reload the window #2

PylotLight · 2023-09-09T02:18:17Z

Having issues with the extension losing connection randomly, not sure where to find any logs for this issues.
So far after testing, downloading the original WSL extension vsix, does not have the same timeout issue, so should be related to this extension I think.

2023-09-09 12:35:26.139 [info] [remote-connection][ExtensionHost][7c117…][reconnect] received socket timeout event (unacknowledgedMsgCount: 523, timeSinceOldestUnacknowledgedMsg: 1654689, timeSinceLastReceivedSomeData: 1658676).
2023-09-09 11:57:57.775 [error] Missing 'tunnelApplicationConfig' or 'tunnelApplicationName' in product.json. Remote tunneling is not available

The text was updated successfully, but these errors were encountered:

jeanp413 · 2023-09-09T04:47:47Z

Hi @PylotLight I can repro with vscodium 1.82.0, but it works fine with 1.81.1, in the meantime you can downgrade vscodium
Will take a deeper look, not sure what have changed in the latest stable release that causes this disconnection

PylotLight · 2023-09-09T05:32:44Z

If you prove it's purely vscodium issue then feel free to close but given there's no issues with the official extension there must be something different, I imagine would be hard to resolve given the closed source nature, but ye hopefully its fixable.

jeanp413 · 2023-09-09T06:20:18Z

Actually I only could repro once, the first time I updated to 1.82, after downgrade to 1.81 and then update back to 1.82 I can't repro anymore 🤔
Does it happen for you consistently? Which WSL distro are you using? Is it wsl 1 or wsl 2? Also when it happens again, please share logs from window in output panel and logs from vscodium server in ~/.vscodium-server/.13ae69686c4390a9aee7b71b44337eb488319f26.log inside WSL

PylotLight · 2023-09-09T08:09:15Z

I have left the connection open for several minutes at this point without a repeat of the error after I reinstalled the extension so will have to keep testing and monitoring. Perhaps we close for now and I'll report back with requested logs and reopen if the issue returns.

2023-09-09 18:00:05.907 [info] [LocalProcess0][resolveAuthority(wsl,1)][16005ms] waiting... 2023-09-09 18:00:06.430 [info] [LocalProcess0][resolveAuthority(wsl,1)][16529ms] returned WebSocket(127.0.0.1:51235) 2023-09-09 18:00:06.430 [info] resolveAuthority(wsl) returned 'WebSocket(127.0.0.1:51235)' after 16530 ms 2023-09-09 18:00:06.431 [info] Creating a socket (renderer-Management-b88d0779-524f-4882-942e-ecc741c04c2b)... 2023-09-09 18:00:06.432 [info] Creating a socket (renderer-ExtensionHost-517895a4-6bbf-485a-b603-c4995472519f)... 2023-09-09 18:00:06.897 [info] Creating a socket (renderer-Management-b88d0779-524f-4882-942e-ecc741c04c2b) was successful after 466 ms. 2023-09-09 18:00:07.036 [info] Creating a socket (renderer-ExtensionHost-517895a4-6bbf-485a-b603-c4995472519f) was successful after 602 ms. 2023-09-09 18:00:08.870 [info] [perf] Render performance baseline is 30ms 2023-09-09 18:01:30.481 [error] semantictokens are disabled: Error: semantictokens are disabled

It's WSL2 using Debian. Btw being able to open with distro option would be highly valuable, but there is a way around it for now as currently it just uses default distro which may or may not be the one we want to launch with.

PylotLight · 2023-09-11T01:40:18Z

Repeated the issue on my work machine now:

2023-09-11 11:10:39.336 [info] Creating a socket (renderer-Management-901f0967-2161-4294-be99-6e6bc8f918a5) was successful after 6 ms. 2023-09-11 11:10:39.353 [info] Creating a socket (renderer-ExtensionHost-873325fc-630f-4194-b537-47fd766b3afb) was successful after 23 ms. 2023-09-11 11:10:40.741 [info] [perf] Render performance baseline is 35ms 2023-09-11 11:19:57.667 [info] [remote-connection][ExtensionHost][87332…][reconnect] received socket close event (wasClean: false, code: 1006, reason: ). 2023-09-11 11:19:57.667 [error] {"isTrusted":true} 2023-09-11 11:19:57.668 [info] [remote-connection][ExtensionHost][87332…][reconnect] starting reconnecting loop. You can get more information with the trace log level. 2023-09-11 11:19:57.668 [info] [remote-connection][ExtensionHost][87332…][reconnect] resolving connection... 2023-09-11 11:19:57.668 [info] [remote-connection][ExtensionHost][87332…][reconnect] connecting to WebSocket(127.0.0.1:37209)... 2023-09-11 11:19:57.668 [info] Creating a socket (renderer-ExtensionHost-873325fc-630f-4194-b537-47fd766b3afb)... 2023-09-11 11:19:57.689 [info] [remote-connection][Management ][901f0…][reconnect] received socket close event (wasClean: false, code: 1006, reason: ). 2023-09-11 11:19:57.689 [error] {"isTrusted":true} 2023-09-11 11:19:57.689 [info] [remote-connection][Management ][901f0…][reconnect] starting reconnecting loop. You can get more information with the trace log level. 2023-09-11 11:19:57.691 [info] [remote-connection][Management ][901f0…][reconnect] resolving connection... 2023-09-11 11:19:57.691 [info] Invoking resolveAuthority(wsl)... 2023-09-11 11:19:57.691 [info] [LocalProcess0][resolveAuthority(wsl,2)][0ms] obtaining proxy... 2023-09-11 11:19:57.691 [info] [LocalProcess0][resolveAuthority(wsl,2)][0ms] invoking... 2023-09-11 11:19:57.695 [info] Creating a socket (renderer-ExtensionHost-873325fc-630f-4194-b537-47fd766b3afb) returned an error after 27 ms. 2023-09-11 11:19:57.695 [error] CodeExpectedError: WebSocket close with status code 1006

jeanp413 · 2023-09-11T04:52:22Z

Current logs tell that the connection got closed for some reason, server logs should be more useful, when it happens again could you share server logs from ~/.vscodium-server/.13ae69686c4390a9aee7b71b44337eb488319f26.log inside WSL distro 🙏

I can repro now, will work on a fix.

PylotLight · 2023-09-12T03:52:58Z

Just to make sure you have my example, heres some of my server logs;
[12:33:14] Error: Throttler is disposed 0400 at l.queue (/home/user/.vscodium-server/bin/13ae69686c4390a9aee7b71b44337eb488319f26/out/vs/server/node/server.main.js:70:16246) 0400 at /home/user/.vscodium-server/bin/13ae69686c4390a9aee7b71b44337eb488319f26/out/vs/server/node/server.main.js:70:18427 0400 at /home/user/.vscodium-server/bin/13ae69686c4390a9aee7b71b44337eb488319f26/out/vs/server/node/server.main.js:70:17883 0400 at runNextTicks (node:internal/process/task_queues:60:5) 0400 at listOnTimeout (node:internal/timers:538:9) 0400 at process.processTimers (node:internal/timers:512:7) [12:33:14] Error: Throttler is disposed 0400 at l.queue (/home/user/.vscodium-server/bin/13ae69686c4390a9aee7b71b44337eb488319f26/out/vs/server/node/server.main.js:70:16246) 0400 at /home/user/.vscodium-server/bin/13ae69686c4390a9aee7b71b44337eb488319f26/out/vs/server/node/server.main.js:70:18427 0400 at /home/user/.vscodium-server/bin/13ae69686c4390a9aee7b71b44337eb488319f26/out/vs/server/node/server.main.js:70:17883 0400 at runNextTicks (node:internal/process/task_queues:60:5) 0400 at listOnTimeout (node:internal/timers:538:9) 0400 at process.processTimers (node:internal/timers:512:7) [12:33:14] [127.0.0.1][6433e02c][ExtensionHostConnection] <25443> Extension Host Process exited with code: 0, signal: null. Cancelling previous shutdown timeout [12:33:14] Cancelling previous shutdown timeout 4300 Last EH closed, waiting before shutting down [12:33:14] Last EH closed, waiting before shutting down 4300 Last EH closed, shutting down [12:38:14] Last EH closed, shutting down

GitMensch · 2023-10-19T19:38:22Z

I can repro now, will work on a fix.

Yay (this affects me, a first time-user of Open Remote WSL, too; at least on earlier versions the manual "start ssh server, get ip, connect via your SSH extension" did work without any aborts; but the nice integration of Open Remote WSL is really good!)

informeti · 2023-12-01T12:56:08Z

The issue exists in 1.83.1 as well:

Version: 1.83.1
Release: 23285
Commit: 36d13de33ac0d6c684f10f99cff352e2f58228b3
Date: 2023-10-12T18:42:10.077Z
Electron: 25.8.4
ElectronBuildId: undefined
Chromium: 114.0.5735.289
Node.js: 18.15.0
V8: 11.4.183.29-electron.0
OS: Windows_NT x64 10.0.19045

Moortu · 2023-12-05T16:41:42Z

I've been having this as well

jeanp413 · 2023-12-06T15:24:57Z

I know the reason but been short of time lately to work on this, I'll see if have some time this month 🙏

subnut · 2023-12-19T12:08:34Z

Current logs tell that the connection got closed for some reason, server logs should be more useful, when it happens again could you share server logs from ~/.vscodium-server/.13ae69686c4390a9aee7b71b44337eb488319f26.log inside WSL distro 🙏

I can repro now, will work on a fix.

It's impossible to fetch the ~/.vscodium-server/.*.log file after a crash because it immediately gets truncated by the output of the restarted server.... is there any way to ensure that the server doesn't restart by itself?

nvm i just created a hardlink to the file... that way i still got the old logs.

...Also, pls fix ASAP if possible...thanks!

subnut · 2023-12-19T12:18:07Z

Or you could tell me in short what's causing it... and I could try looking into how to fix it...

I'm relatively free till this weekend...

PylotLight · 2023-12-30T08:42:56Z

From what I'm seeing in these logs there seems to be 2 issues.

The WS connection gets a received socket close event
Failure to reconnect upon getting that close event. Error: Connection error: Unknown reconnection token (never seen) - permanent failure occurred while running the reconnecting loop. - received socket timeout event

jeanp413 · 2023-12-31T01:58:06Z

Let me explain the issue:

It happens when you have 2 or more vscode window connected to the same wsl distro
The first WSL vscode window will run the vscode server on the wsl distro, once you open a new window it will detect the running server and use it.
If you close the WSL vscode window that started the vscode server then the process will die (this seems a specific behavior of WSL as it does not happen when using SSH) so the other vscode window will lose connection
The fix for this is to run this function independently of the vscode extension host lifecycle, so in the extension we need to create a detached child process to execute the wsl command the will launch the vscode server, now if the vscode window is closed then the process running the vscode server will keep running

PylotLight · 2024-01-01T11:36:54Z

This confuses me slightly as I get errors on just 1 window, after opening vscodium and touching nothing else, what do you mean 2+ windows?

jeanp413 · 2024-01-03T15:19:45Z

what do you mean 2+ windows?

At least two vscode windows connected to the same WSL distro, only one will start the vscode server, so if that window is closed then the other vscode window connected to the same server will disconnect as there's no server running.

@PylotLight in your case if you only have one window, do you see a pattern? does it happen after an update or after a window reload?

PylotLight · 2024-01-06T06:58:07Z

At least two vscode windows connected to the same WSL distro

As shown in my pic, I was getting the disconnect error with no other windows open, so I've seen this issue occur in various senarios, e.g where I would open codium, do nothing, leave it for a few minutes and it would just disconnect on its own.

And other cases where I have a spilt view which I assume counts as two windows which works fine for hours with no issues.

@PylotLight in your case if you only have one window, do you see a pattern? does it happen after an update or after a window reload?

Unfortunately I don't have any patterns to report at this time, is there any way we could add extra logging into the extension to try narrow down some issues to provide better feedback?
Perhaps an alternative version could be used?

orariley70 · 2024-01-06T10:11:22Z

Hello @PylotLight. Glad seeing that you're not the only one that has this problem. It does seem harmless, but a pretty annoying bug every couple of minutes. I can repro as well.

PylotLight · 2024-01-06T10:33:06Z

Hello @PylotLight. Glad seeing that you're not the only one that has this problem. It does seem harmless, but a pretty annoying bug every couple of minutes. I can repro as well.

The question is can you repro consistently? I do often get the issue, but sometimes its fine and sometimes it's not, I haven't figured out a pattern for it.

orariley70 · 2024-01-07T07:04:15Z

It will do it after a certain minutes of usage. Doesn't care if there's anything or nothing going on. I had this happen when there's a process running on the terminal or when I'm editing.
I know, it isn't really helpful.

orariley70 · 2024-01-13T02:36:15Z

I realized when the host VSCodium says it's disconnected, the server will have different PIDs like it was restarting itself, but I can't find any relevant log (lines). When server (re)starts, it overwrites the log instantly.

subnut · 2024-01-14T05:54:46Z

When server (re)starts, it overwrites the log instantly

That was the exact same problem when I was trying to debug this issue.

You could try creating a hard link to the log file, with a different name using the ln command... eg

ln logfile logfile2

Then, after the server restarts, theoretically you could get the older logs in logfile2.

HTGAzureX1212 · 2024-01-23T09:55:40Z

Greetings, I have also encountered this issue today. Indeed this is quite annoying.

Please see the console logs below, from within DevTools:

This happens when I only have one VSCodium window open.

ColorfulRhino · 2024-02-01T17:50:46Z

I believe this issue is gone for me since I switched to WSL Kernel 6.1.

Can anyone else try and confirm?

Here are instructions on how to do use the new kernel: https://learn.microsoft.com/en-us/community/content/wsl-user-msft-kernel-v6

PylotLight · 2024-02-03T11:48:39Z

I've also compiled and upgraded, will leave this comment here and update it if I have any errors.
Status: Still getting errors on work machine, and home machine unfortunately.

P.S MS docs suck and defs required some extra not included steps.

entepe85 · 2024-03-01T07:49:36Z

Yeah, the documentation from MS definitely fails to mention that on distros other than Ubuntu (using Debian 12 here) some packages like bc could be missing and causing the kernel build to fail. Moreover, copying to /mnt/c/ isn't working and the Windows Explorer must be used to copy the bzImage file. But I digress...

@ColorfulRhino - Since I updated the WSL kernel to 6.1 the issue hasn't reappeared.

ColorfulRhino · 2024-03-01T19:53:21Z

I still get the "Please reconnect" sometimes with kernel 6.1, but rarely compared to before with kernel 5.15. It's definitely managable with 6.1

brandochn · 2024-04-04T20:24:51Z

The same issue here:

Version: 1.87.2 (system setup)
Release: 24072
Commit: f7ed6417a7cfae92f98129384c13b505bb9cfc53
Date: 2024-03-12T18:37:03.663Z
Electron: 27.3.2
ElectronBuildId: undefined
Chromium: 118.0.5993.159
Node.js: 18.17.1
V8: 11.8.172.18-electron.0
OS: Windows_NT x64 10.0.19045

I am using WSL2 with Ubuntu Preview.

Morpheus0x · 2024-04-23T12:59:42Z

Also experiencing the same issue on Windows 10 (22H2 19045.4170) with latest VSCodium 1.88.1.24104 and WSL 2.0 Debian 10 (Kernel: 5.15.150.1-microsoft-standard-WSL2). I have only a single VSCodium window open connected to the only installed WSL distro with a Workspace opened at /mnt/c/Users/...

I noticed the issue when the VSCodium window is open on my second monitor but not focused, or when unlocking windows after coming back from a coffee break. The second one isn't a big deal since I just need to reload to continue, but having to do this every time switching back to the editor when researching something is annoying.
Edit: This also happens when the window is focused and I am actively working on a file

VSCodium Window Log Output for Error (Trace log level):

2024-04-23 14:54:50.146 [info] [remote-connection][ExtensionHost][2247b…][reconnect] received socket close event (wasClean: false, code: 1006, reason: ).
2024-04-23 14:54:50.146 [error] {"isTrusted":true}
2024-04-23 14:54:50.147 [info] [remote-connection][ExtensionHost][2247b…][reconnect] starting reconnecting loop. You can get more information with the trace log level.
2024-04-23 14:54:50.147 [info] [remote-connection][ExtensionHost][2247b…][reconnect] resolving connection...
2024-04-23 14:54:50.148 [info] [remote-connection][ExtensionHost][2247b…][reconnect] connecting to WebSocket(127.0.0.1:38469)...
2024-04-23 14:54:50.148 [trace] [remote-connection][ExtensionHost][2247b…][reconnect][WebSocket(127.0.0.1:38469)] 1/6. invoking socketFactory.connect().
2024-04-23 14:54:50.148 [info] Creating a socket (renderer-ExtensionHost-2247b5dd-fd0b-42c5-8f0d-24542ad7e76b)...
2024-04-23 14:54:50.205 [info] [remote-connection][Management   ][e7210…][reconnect] received socket close event (wasClean: false, code: 1006, reason: ).
2024-04-23 14:54:50.206 [error] {"isTrusted":true}
2024-04-23 14:54:50.206 [info] [remote-connection][Management   ][e7210…][reconnect] starting reconnecting loop. You can get more information with the trace log level.
2024-04-23 14:54:50.207 [info] [remote-connection][Management   ][e7210…][reconnect] resolving connection...
2024-04-23 14:54:50.208 [info] Invoking resolveAuthority(wsl)...
2024-04-23 14:54:50.208 [info] [LocalProcess0][resolveAuthority(wsl,2)][0ms] obtaining proxy...
2024-04-23 14:54:50.209 [info] [LocalProcess0][resolveAuthority(wsl,2)][0ms] invoking...
2024-04-23 14:54:50.219 [info] Creating a socket (renderer-ExtensionHost-2247b5dd-fd0b-42c5-8f0d-24542ad7e76b) returned an error after 71 ms.
2024-04-23 14:54:50.219 [error] CodeExpectedError: WebSocket close with status code 1006
    at WebSocket.<anonymous> (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:688:4976)
2024-04-23 14:54:50.219 [error] [remote-connection][ExtensionHost][2247b…][reconnect][WebSocket(127.0.0.1:38469)] socketFactory.connect() failed or timed out. Error:
2024-04-23 14:54:50.220 [error] CodeExpectedError: WebSocket close with status code 1006
    at WebSocket.<anonymous> (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:688:4976)
2024-04-23 14:54:50.220 [info] [remote-connection][ExtensionHost][2247b…][reconnect] A temporarily not available error occurred while trying to reconnect, will try again...
2024-04-23 14:54:50.220 [trace] WebSocket close with status code 1006: CodeExpectedError: WebSocket close with status code 1006
    at WebSocket.<anonymous> (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:688:4976)
2024-04-23 14:54:50.221 [info] [remote-connection][ExtensionHost][2247b…][reconnect] waiting for 5 seconds before reconnecting...
2024-04-23 14:54:51.075 [info] [LocalProcess0][resolveAuthority(wsl,2)][867ms] returned WebSocket(127.0.0.1:46507)
2024-04-23 14:54:51.075 [info] resolveAuthority(wsl) returned 'WebSocket(127.0.0.1:46507)' after 868 ms
2024-04-23 14:54:51.076 [info] [remote-connection][Management   ][e7210…][reconnect] connecting to WebSocket(127.0.0.1:46507)...
2024-04-23 14:54:51.076 [trace] [remote-connection][Management   ][e7210…][reconnect][WebSocket(127.0.0.1:46507)] 1/6. invoking socketFactory.connect().
2024-04-23 14:54:51.076 [info] Creating a socket (renderer-Management-e7210d8e-23dd-49b6-b481-a6aa5f4d188a)...
2024-04-23 14:54:51.590 [info] Creating a socket (renderer-Management-e7210d8e-23dd-49b6-b481-a6aa5f4d188a) was successful after 514 ms.
2024-04-23 14:54:51.590 [trace] [remote-connection][Management   ][e7210…][reconnect][WebSocket(127.0.0.1:46507)] 2/6. socketFactory.connect() was successful.
2024-04-23 14:54:51.590 [trace] [remote-connection][Management   ][e7210…][reconnect][WebSocket(127.0.0.1:46507)] 3/6. sending AuthRequest control message.
2024-04-23 14:54:51.598 [trace] [remote-connection][Management   ][e7210…][reconnect][WebSocket(127.0.0.1:46507)] 4/6. received SignRequest control message.
2024-04-23 14:54:51.601 [trace] [remote-connection][Management   ][e7210…][reconnect][WebSocket(127.0.0.1:46507)] 5/6. sending ConnectionTypeRequest control message.
2024-04-23 14:54:51.603 [info] [remote-connection][Management   ][e7210…][reconnect] received socket close event (wasClean: false, code: 1006, reason: ).
2024-04-23 14:54:51.603 [error] {"isTrusted":true}
2024-04-23 14:54:51.604 [error] [remote-connection][Management   ][e7210…][reconnect][WebSocket(127.0.0.1:46507)] received error control message when negotiating connection. Error:
2024-04-23 14:54:51.604 [error] Error: Connection error: Unknown reconnection token (never seen)
    at G (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:688:22436)
    at u.value (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:688:12069)
    at n._deliver (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:89:837)
    at n.fire (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:89:1156)
    at s.fire (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:628:17272)
    at l._receiveMessage (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:628:22215)
    at u.value (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:628:21186)
    at n._deliver (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:89:837)
    at n.fire (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:89:1156)
    at c.acceptChunk (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:628:14096)
    at vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:628:13226
    at u.value (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:688:6052)
    at n._deliver (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:89:837)
    at n.fire (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:89:1156)
    at _fileReader.onload (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:688:4102)
2024-04-23 14:54:51.604 [error] [remote-connection][Management   ][e7210…][reconnect] A permanent error occurred in the reconnecting loop! Will give up now! Error:
2024-04-23 14:54:51.604 [error] Error: Connection error: Unknown reconnection token (never seen)
    at G (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:688:22436)
    at u.value (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:688:12069)
    at n._deliver (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:89:837)
    at n.fire (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:89:1156)
    at s.fire (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:628:17272)
    at l._receiveMessage (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:628:22215)
    at u.value (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:628:21186)
    at n._deliver (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:89:837)
    at n.fire (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:89:1156)
    at c.acceptChunk (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:628:14096)
    at vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:628:13226
    at u.value (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:688:6052)
    at n._deliver (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:89:837)
    at n.fire (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:89:1156)
    at _fileReader.onload (vscode-file://vscode-app/c:/Program%20Files/VSCodium/resources/app/out/vs/workbench/workbench.desktop.main.js:688:4102)
2024-04-23 14:54:51.605 [trace] DialogService#confirm Cannot reconnect. Please reload the window.
2024-04-23 14:54:53.647 [info] Extension host (Remote) is unresponsive.

PylotLight · 2024-04-23T14:46:54Z

Attempting to dig into the code which is way out of my wheelhouse:
This didn't work and defs broke things.
const cmd = cp.spawn(wslBinary, args, { windowsHide: true, windowsVerbatimArguments: true, detached: true });

Also a child process already seems to be calling wsl commands so I feel like the earlier suggestion doesn't quite make sense.
Finding where the socket management is done is a bit confusing as there's likely a lot happening on the vsce side that we can't see.

CompeyDev · 2024-04-26T16:01:24Z

As a workaround, you can manually launch the server on the WSL instance.

Simply navigate to $HOME/.vscodium-server/bin/{{VERSION_HASH}}/bin on the WSL machine and call ./codium-server. You can find your version hash in VSCodium in help > about > commit.

sneakylenny · 2024-05-07T10:25:10Z

Workaround

A good work around is to:

Close all Codium windows
Run htop in wsl (or any other task manager)
Kill the vscode server process (/home/<username>/.vscodium-server/...)
...
PROFIT $$$

All jokes aside, when you follow these steps you'll be able to use Codium without having to "reload window" every 10 minutes or so.

entepe85 · 2024-05-08T10:46:09Z

Unfortunately, this issue still persists on the most recent WSL2 kernel under certain circumstances, e.g. reconnecting after opening a different workspace.

While the workaround might be feasible it's potentially less effort to start the remote extension host (i.e. vscodium-server) in a detached shell in the WSL2 and connecting manually.

ubidev · 2024-06-02T15:09:28Z

Hi!
I just started using that extension and have the same problem alas on latest w11 enterprise 23h2 latest build

GitMensch · 2024-06-12T08:41:12Z

@entepe85 wrote:

While the workaround might be feasible it's potentially less effort to start the remote extension host (i.e. vscodium-server) in a detached shell in the WSL2 and connecting manually.

How would you exactly do that? I guess you would connect once with this extension to have the server installed and after first disconnect do ???

CompeyDev · 2024-06-12T11:47:49Z

I guess you would connect once

That's correct - you would need to initially set the extension up, or download the codium-reh from GitHub releases for VSCodium.

PylotLight · 2024-06-12T13:20:42Z

I've found what works for me is just using wsl --shutdown to restart the whole session which makes it work for a while fixing whatever is broken in the background.

jeanp413 added the bug Something isn't working label Sep 11, 2023

PylotLight mentioned this issue Feb 4, 2024

Will error connecting to WSL target the second time and beyond #4

Open

theAkito mentioned this issue Sep 21, 2024

WSL First Setup Utterly Broken #10

Open

Issue with WSL losing remote connection randomly - Cannot reconnect. Please reload the window #2

Issue with WSL losing remote connection randomly - Cannot reconnect. Please reload the window #2

Comments

PylotLight commented Sep 9, 2023 • edited Loading

jeanp413 commented Sep 9, 2023 • edited Loading

PylotLight commented Sep 9, 2023

jeanp413 commented Sep 9, 2023 • edited Loading

PylotLight commented Sep 9, 2023 • edited Loading

PylotLight commented Sep 11, 2023

jeanp413 commented Sep 11, 2023 • edited Loading

PylotLight commented Sep 12, 2023

GitMensch commented Oct 19, 2023

informeti commented Dec 1, 2023

Moortu commented Dec 5, 2023

jeanp413 commented Dec 6, 2023

subnut commented Dec 19, 2023 • edited Loading

subnut commented Dec 19, 2023

PylotLight commented Dec 30, 2023 • edited Loading

jeanp413 commented Dec 31, 2023 • edited Loading

PylotLight commented Jan 1, 2024

jeanp413 commented Jan 3, 2024

PylotLight commented Jan 6, 2024

orariley70 commented Jan 6, 2024

PylotLight commented Jan 6, 2024

orariley70 commented Jan 7, 2024

orariley70 commented Jan 13, 2024

subnut commented Jan 14, 2024

HTGAzureX1212 commented Jan 23, 2024 • edited Loading

ColorfulRhino commented Feb 1, 2024

PylotLight commented Feb 3, 2024 • edited Loading

entepe85 commented Mar 1, 2024

ColorfulRhino commented Mar 1, 2024

brandochn commented Apr 4, 2024

Morpheus0x commented Apr 23, 2024 • edited Loading

PylotLight commented Apr 23, 2024

CompeyDev commented Apr 26, 2024

sneakylenny commented May 7, 2024

Workaround

entepe85 commented May 8, 2024

ubidev commented Jun 2, 2024 • edited Loading

GitMensch commented Jun 12, 2024

CompeyDev commented Jun 12, 2024

PylotLight commented Jun 12, 2024

PylotLight commented Sep 9, 2023 •

edited

Loading

jeanp413 commented Sep 9, 2023 •

edited

Loading

jeanp413 commented Sep 9, 2023 •

edited

Loading

PylotLight commented Sep 9, 2023 •

edited

Loading

jeanp413 commented Sep 11, 2023 •

edited

Loading

subnut commented Dec 19, 2023 •

edited

Loading

PylotLight commented Dec 30, 2023 •

edited

Loading

jeanp413 commented Dec 31, 2023 •

edited

Loading

HTGAzureX1212 commented Jan 23, 2024 •

edited

Loading

PylotLight commented Feb 3, 2024 •

edited

Loading

Morpheus0x commented Apr 23, 2024 •

edited

Loading

ubidev commented Jun 2, 2024 •

edited

Loading