[WSL] Cannot open `code` via integrated terminal in VS Code when systemd is enabled

[marveloo]

• VSCode Version: 1.82.2
• Local OS Version: Windows 10.0.19045
• Remote OS Version: Ubuntu 22.04.3 LTS
• Remote Extension/Connection Type: WSL v0.81.7

Steps to Reproduce:

1. Enable systemd in WSL
2. Restart WSL
3. Open a WSL terminal in VS Code
4. Wait up to several minutes
5. Excecute code

Expected behavior:

Instance of VS Code gets opened

Actual behavior:

After several minutes (mentioned in step 4) of using VSCode in remote mode, a new VSCode instance no longer opens via integrated terminal in bash and shows the following output:

Unable to connect to VS Code server: Error in request.
Error: connect ENOENT /run/user/1000/vscode-ipc-86dee205-d158-4f59-a6a8-e7ccf715f33f.sock
    at PipeConnectWrap.afterConnect [as oncomplete] (node:net:1494:16) {
  errno: -2,
  code: 'ENOENT',
  syscall: 'connect',
  address: '/run/user/1000/vscode-ipc-86dee205-d158-4f59-a6a8-e7ccf715f33f.sock'
}

Additional notes:

• I can still open a new instance of VS Code using an external terminal, e.g. via bash in Windows Terminal App.
• I used sudo systemctl mask systemd-binfmt.service to fix the well known systemd issue #8843, however that seems to be unrelated to the issue I am reporting here.

[jpalpant]

I just ran into this as well. I'm not sure what happened, but I noticed that my /run/user/$UID directory was owned by root:root, and it was also empty!

$ ls -larth /run/user/1000
total 0
drwxr-xr-x 3 root   root    60 Sep 24 10:42 ..
drwx------ 3 root   root   140 Oct  6 19:05 .

VSCode clearly expects something to exist in this directory, and can't make it when root:root owns the directory and the permissions are drwx------. As a test, I ran sudo chown $UID /run/user/$UID and closed VSCode. When I reopened, I noticed that the files VSCode expects were in the directory and that commands like code . and git interactions worked again:

$ ls -larth /run/user/1000
total 0
drwxr-xr-x 3 root   root    60 Sep 24 10:42 ..
drwx------ 2 justin justin 120 Oct  6 19:05 gnupg
srwxr-xr-x 1 justin justin   0 Oct  6 19:05 vscode-ipc-212010df-3241-4a6c-b333-6f4d7d0a91ad.sock
srwxr-xr-x 1 justin justin   0 Oct  6 19:05 vscode-git-148fd1b6cb.sock
srwxr-xr-x 1 justin justin   0 Oct  6 19:05 vscode-ipc-f9352884-97c4-4ded-879a-b4979d996324.sock
drwx------ 3 justin root   140 Oct  6 19:05 .

[adrianghc]

I'm having the same issue, though I think it only started recently and not three weeks ago. It makes certain workflows very difficult and annoying, like Git workflows that spawn VS Code as the editor, such as rebasing. The only fix is to fully shutdown WSL or to use vim as the Git editor.

• VSCode Version: 1.83.1
• Local OS Version: Windows 11 10.0.22631
• Remote OS Version: Ubuntu 22.04.3 LTS
• Remote Extension/Connection Type: WSL 0.81.0

[Dawn-K]

@jpalpant This method works! As you said, after setting the permissions, it will be in the corresponding directory. Thank you!

[adrianghc]

This method doesn't work for me, as the problem is that the /run/user/$UID directory exists in the beginning of a WSL session (with correct permissions), but disappears entirely after a short while. At this point, systemctl --failed shows that the systemd-networkd-wait-online.service and systemd-remount-fs.service have failed to load.

EDIT: The systemd-remount-fs.service failure was caused by a faulty line in /etc/fstab. That leaves the networkd-wait-online.service failure, for which it seems that disabling systemd-networkd might have fixed it, and with it this issue. systemctl status doesn't report any failures now, and /run/user/$UID seems to persist for now. Fingers crossed.