Trying to run "code <directory>" in terminal gives "Error: Cannot find module '<directory>'"

[kfish610]

Bug description

When I try to open a directory with code <directory>, I get Error: Cannot find module '<directory>'. This happens no matter what directory I try to open, whether it is in the WSL filesystem or the Windows filesystem.

To Reproduce

Steps to reproduce the behavior:

1. Open a NixOS-WSL terminal (NOT the VSCode integrated terminal, since this uses a different binary for code)
2. Navigate to any directory and type code .
3. Get error

Expected behavior

Should open the folder in VSCode Remote

Logs

My home-manager settings can be seen at https://github.com/kfish610/wsl-dots/blob/main/home.nix

neofetch:

kfish@KDESKTOP
--------------
OS: NixOS 22.05 (Quokka) on Windows x86_64
Kernel: 5.10.102.1-microsoft-standard-WSL2
Uptime: 16 mins
Packages: 198 (nix-system), 4327 (nix-user), 71 (nix-default)
Shell: zsh 5.8.1
Terminal: Windows Terminal
CPU: AMD Ryzen 5 3600 (12) @ 3.600GHz
GPU: Microsoft Corporation Device 008e
Memory: 606MiB / 7910MiB

code $HOME

node:internal/modules/cjs/loader:990
  throw err;
  ^

Error: Cannot find module '\\wsl.localhost\NixOS\home\kfish'
    at Function.Module._resolveFilename (node:internal/modules/cjs/loader:987:15)
    at Module._load (node:internal/modules/cjs/loader:832:27)
    at Function.c._load (node:electron/js2c/asar_bundle:5:13343)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12)
    at node:internal/main/run_main_module:17:47 {
  code: 'MODULE_NOT_FOUND',
  requireStack: []
}

VSCODE_WSL_DEBUG_INFO=true code $HOME (click expand):

Expand (this one's long)

+ COMMIT=c3511e6c69bb39013c4a4b7b9566ec1ca73fc4d5
+ APP_NAME=code
+ QUALITY=stable
+ NAME=Code
+ SERVERDATAFOLDER=.vscode-server
++++ realpath '/mnt/c/Users/kfish/AppData/Local/Programs/Microsoft VS Code/bin/code'
+++ dirname '/mnt/c/Users/kfish/AppData/Local/Programs/Microsoft VS Code/bin/code'
++ dirname '/mnt/c/Users/kfish/AppData/Local/Programs/Microsoft VS Code/bin'
+ VSCODE_PATH='/mnt/c/Users/kfish/AppData/Local/Programs/Microsoft VS Code'
+ ELECTRON='/mnt/c/Users/kfish/AppData/Local/Programs/Microsoft VS Code/Code.exe'
+ IN_WSL=false
+ '[' -n NixOS ']'
+ IN_WSL=true
+ '[' true = true ']'
+ export WSLENV=ELECTRON_RUN_AS_NODE/w:WT_SESSION::WT_PROFILE_ID
+ WSLENV=ELECTRON_RUN_AS_NODE/w:WT_SESSION::WT_PROFILE_ID
++ wslpath -m '/mnt/c/Users/kfish/AppData/Local/Programs/Microsoft VS Code/resources/app/out/cli.js'
+ CLI='C:/Users/kfish/AppData/Local/Programs/Microsoft VS Code/resources/app/out/cli.js'
+ WSL_EXT_ID=ms-vscode-remote.remote-wsl
+ ELECTRON_RUN_AS_NODE=1
+ '/mnt/c/Users/kfish/AppData/Local/Programs/Microsoft VS Code/Code.exe' 'C:/Users/kfish/AppData/Local/Programs/Microsoft VS Code/resources/app/out/cli.js' --ms-enable-electron-run-as-node --locate-extension ms-vscode-remote.remote-wsl
++ cat /tmp/remote-wsl-loc.txt
+ WSL_EXT_WLOC=
+ '[' -n '' ']'
+ ELECTRON_RUN_AS_NODE=1
+ '/mnt/c/Users/kfish/AppData/Local/Programs/Microsoft VS Code/Code.exe' 'C:/Users/kfish/AppData/Local/Programs/Microsoft VS Code/resources/app/out/cli.js' --ms-enable-electron-run-as-node .
node:internal/modules/cjs/loader:990
  throw err;
  ^

Error: Cannot find module '\\wsl.localhost\NixOS\home\kfish'
    at Function.Module._resolveFilename (node:internal/modules/cjs/loader:987:15)
    at Module._load (node:internal/modules/cjs/loader:832:27)
    at Function.c._load (node:electron/js2c/asar_bundle:5:13343)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12)
    at node:internal/main/run_main_module:17:47 {
  code: 'MODULE_NOT_FOUND',
  requireStack: []
}
+ exit 1

For what it's worth, I also tested this in the default Ubuntu installation for WSL, and it worked. The debug output is: VSCODE_WSL_DEBUG_INFO=true code $HOME (click expand):

Expand (Ubuntu)

+ COMMIT=c3511e6c69bb39013c4a4b7b9566ec1ca73fc4d5
+ APP_NAME=code
+ QUALITY=stable
+ NAME=Code
+ SERVERDATAFOLDER=.vscode-server
+ realpath /mnt/c/Users/kfish/AppData/Local/Programs/Microsoft VS Code/bin/code
+ dirname /mnt/c/Users/kfish/AppData/Local/Programs/Microsoft VS Code/bin/code
+ dirname /mnt/c/Users/kfish/AppData/Local/Programs/Microsoft VS Code/bin
+ VSCODE_PATH=/mnt/c/Users/kfish/AppData/Local/Programs/Microsoft VS Code
+ ELECTRON=/mnt/c/Users/kfish/AppData/Local/Programs/Microsoft VS Code/Code.exe
+ IN_WSL=false
+ [ -n Ubuntu ]
+ IN_WSL=true
+ [ true = true ]
+ export WSLENV=ELECTRON_RUN_AS_NODE/w:WT_SESSION::WT_PROFILE_ID
+ wslpath -m /mnt/c/Users/kfish/AppData/Local/Programs/Microsoft VS Code/resources/app/out/cli.js
+ CLI=C:/Users/kfish/AppData/Local/Programs/Microsoft VS Code/resources/app/out/cli.js
+ WSL_EXT_ID=ms-vscode-remote.remote-wsl
+ ELECTRON_RUN_AS_NODE=1 /mnt/c/Users/kfish/AppData/Local/Programs/Microsoft VS Code/Code.exe C:/Users/kfish/AppData/Local/Programs/Microsoft VS Code/resources/app/out/cli.js --ms-enable-electron-run-as-node --locate-extension ms-vscode-remote.remote-wsl
+ cat /tmp/remote-wsl-loc.txt
+ WSL_EXT_WLOC=c:\Users\kfish\.vscode\extensions\ms-vscode-remote.remote-wsl-0.66.3
+ [ -n c:\Users\kfish\.vscode\extensions\ms-vscode-remote.remote-wsl-0.66.3 ]
+ wslpath -u c:\Users\kfish\.vscode\extensions\ms-vscode-remote.remote-wsl-0.66.3
+ WSL_CODE=/mnt/c/Users/kfish/.vscode/extensions/ms-vscode-remote.remote-wsl-0.66.3/scripts/wslCode.sh
+ /mnt/c/Users/kfish/.vscode/extensions/ms-vscode-remote.remote-wsl-0.66.3/scripts/wslCode.sh c3511e6c69bb39013c4a4b7b9566ec1ca73fc4d5 stable /mnt/c/Users/kfish/AppData/Local/Programs/Microsoft VS Code/Code.exe code .vscode-server /home/kfish
+ [ -z .vscode-server ]
+ [ .vscode-server = .vscode-insiders ]
+ [ ! -t 0 ]
+ VSCODE_REMOTE_BIN=/home/kfish/.vscode-server/bin
+ AUTHORITY=wsl+default
+ [ Ubuntu ]
+ AUTHORITY=wsl+Ubuntu
+ dirname /mnt/c/Users/kfish/.vscode/extensions/ms-vscode-remote.remote-wsl-0.66.3/scripts/wslCode.sh
+ /mnt/c/Users/kfish/.vscode/extensions/ms-vscode-remote.remote-wsl-0.66.3/scripts/wslDownload.sh c3511e6c69bb39013c4a4b7b9566ec1ca73fc4d5 stable /home/kfish/.vscode-server/bin
+ [ ! -d /home/kfish/.vscode-server/bin/c3511e6c69bb39013c4a4b7b9566ec1ca73fc4d5 ]
+ RC=0
+ [ 0 -ne 0 ]
+ mktemp /tmp/vscode-distro-env.XXXXXX
+ STORED_ENV=/tmp/vscode-distro-env.WD3oQH
+ env
+ dirname /mnt/c/Users/kfish/.vscode/extensions/ms-vscode-remote.remote-wsl-0.66.3/scripts/wslCode.sh
+ VSCODE_CLIENT_COMMAND=/mnt/c/Users/kfish/AppData/Local/Programs/Microsoft VS Code/Code.exe VSCODE_CLIENT_COMMAND_CWD=/mnt/c/Users/kfish/.vscode/extensions/ms-vscode-remote.remote-wsl-0.66.3/scripts VSCODE_CLI_AUTHORITY=wsl+Ubuntu VSCODE_CLI_REMOTE_ENV=/tmp/vscode-distro-env.WD3oQH VSCODE_STDIN_FILE_PATH= WSLENV=VSCODE_CLI_REMOTE_ENV/w:ELECTRON_RUN_AS_NODE/w:WT_SESSION::WT_PROFILE_ID /home/kfish/.vscode-server/bin/c3511e6c69bb39013c4a4b7b9566ec1ca73fc4d5/bin/remote-cli/code /home/kfish
+ exit 0

As far as I can tell, the place it breaks is where it tries to locate the remote extension. If you isolate the line, you can run (the exact directory will vary slightly by your username):

> export WSLENV="ELECTRON_RUN_AS_NODE/w:$WSLENV"
> ELECTRON_RUN_AS_NODE=1 "/mnt/c/Users/kfish/AppData/Local/Programs/Microsoft VS Code/Code.exe" "C:/Users/kfish/AppData/Local/Programs/Microsoft VS Code/resources/app/out/cli.js" --ms-enable-electron-run-as-node --locate-extension ms-vscode-remote.remote-wsl
cli.js: bad option: --locate-extension

This is supposed to output the folder of the VSCode remote extension (and on Ubuntu the exact same command does output /mnt/c/Users/kfish/.vscode/extensions/ms-vscode-remote.remote-wsl-0.66.3/ for me), but instead it gives that weird error. I have absolutely no clue what makes NixOS-WSL different enough to cause that error, but it does only happen on NixOS.

[kfish610]

I should note, I do have VSCode remote working in general, I just have to open VSCode normally first and then click New WSL Window. It's just very annoying to have to do that in order to open a folder, rather than just being able to do it from the terminal.

[nzbr]

This seems to be (yet another) interop issue. Can you try setting wsl.interop.register = false; in configuration.nix? You'll need to fully restart the WSL VM (wsl --shutdown) after rebuilding for this to take effect

[kfish610]

@nzbr Oh that did fix it, is there anything im missing out on by having that off? Thanks though!

[nzbr]

It is needed to be able to register binfmt handlers without breaking running .exe files from NixOS. If you don't use that, you don't need wsl.interop.register

[K900]

Wild guess: when have you last updated the nixos-wsl channel/input? This might be fixed by https://github.com/nix-community/NixOS-WSL/commit/28185e373de03bcc0ef5bf2479cb2868fa88e6bb

[nzbr]

I definitely have the latest commit, and as soon as I set wsl.interop.register = true it stops working

[K900]

Please try https://github.com/nix-community/NixOS-WSL/pull/99

[ajaxbits]

Getting the exact same error on Windows 10. I'm on the latest NixOS-WSL commit.

Setting wsl.interop.register = false; fixes the issue.

Output from nix flake info for my system flake, where I import the wsl module:

<...>
└───wsl: github:nix-community/NixOS-WSL/afc01c08692b007998b6cee277a3b8d76b9fe1c5
    ├───flake-compat: github:edolstra/flake-compat/b4a34015c698c7793d592d66adbab377907a2be8
    ├───flake-utils: github:numtide/flake-utils/1ed9fb1935d260de5fe1c2f7ee0ebaae17ed2fa1
    └───nixpkgs follows input 'nixpkgs'
<...>

[K900]

Can you run file /run/binfmt/WSLinterop?

[ajaxbits]

Can you run file /run/binfmt/WSLinterop?

Tested with wsl.interop.register = false and wsl.interop.register = true and got the same output either way:

c/windows/System32
❯ nix run nixpkgs#file /run/binfmt/WSLinterop
/run/binfmt/WSLinterop: cannot open `/run/binfmt/WSLinterop' (No such file or directory)

(also, I installed this system fresh an hour ago from the nixos-wsl-installer-fixed.tar.gz file from releases)

[nzbr]

Can you try installing from the latest tarball? (the tarball is inside a zip file due to how GitHub Actions work)

[ajaxbits]

Thanks for the idea -- makes a ton of sense, should have thought of that. Unfortunately, it didn't work.

Installed from the link provided and got the following:

[nixos@nixos:~]$ mkdir test

[nixos@nixos:~]$ touch test/index.js

[nixos@nixos:~]$ cd test

[nixos@nixos:~/test]$ code .
node:internal/modules/cjs/loader:990
  throw err;
  ^

Error: Cannot find module '\\wsl$\nixtest\mnt\c\Program Files\Microsoft VS Code\Code.exe'
    at Function.Module._resolveFilename (node:internal/modules/cjs/loader:987:15)
    at Module._load (node:internal/modules/cjs/loader:832:27)
    at Function.c._load (node:electron/js2c/asar_bundle:5:13343)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12)
    at node:internal/main/run_main_module:17:47 {
  code: 'MODULE_NOT_FOUND',
  requireStack: []
}

For file:

[nixos@nixos:~/test]$ nix run nixpkgs#file /run/binfmt/WSLInterop
/run/binfmt/WSLInterop: symbolic link to /nix/store/8rw41lzvsyzvrcfa33b05i1h4mh97jk3-nixos-wsl-binfmt-hack

[nzbr]

Does setting wsl.compatibility.interopPreserveArgvZero to either true or false (the default is null) help?

[ajaxbits]

Looks like wsl.compatibility.interopPreserveArgvZero = false; is the way forward. I get a new error that seems easier to debug.

Installing wget is sufficient to get around the new error. However, I'm running into a VSCode bug right now where the latest version of the VSCode remote server won't run due to some kind of issue with the node binary they bundle 😅. However, the bug referred to in this issue is solved by setting interopPreserveArgvZero = false and having wget available.

The details of my testing are below.

---

Steps taken

• Added wsl.compatibility.interopPreserveArgvZero = true or false to /etc/nixos/configuration.nix
• nixos-rebuild switch
• Restarted the wsl distro
• Booted up and tried to run code .

Results

With wsl.compatibility.interopPreserveArgvZero = true:

PS C:\Users\Alexja> wsl -d nixtest
Copying /usr/share/applications
Copying /usr/share/icons
setting up /etc...
Starting systemd...

[nixos@US-ALEXJA-L:/mnt/c/Users/Alexja]$ code .
node:internal/modules/cjs/loader:990
  throw err;
  ^

Error: Cannot find module 'C:\mnt\c\Program Files\Microsoft VS Code\Code.exe'
    at Function.Module._resolveFilename (node:internal/modules/cjs/loader:987:15)
    at Module._load (node:internal/modules/cjs/loader:832:27)
    at Function.c._load (node:electron/js2c/asar_bundle:5:13343)
    at Function.executeUserEntryPoint [as runMain] (node:internal/modules/run_main:81:12)
    at node:internal/main/run_main_module:17:47 {
  code: 'MODULE_NOT_FOUND',
  requireStack: []
}

With wsl.compatibility.interopPreserveArgvZero = false:

PS C:\Users\Alexja> wsl -d nixtest
Copying /usr/share/applications
Copying /usr/share/icons
setting up /etc...
Starting systemd...

[nixos@US-ALEXJA-L:/mnt/c/Users/Alexja]$ code .
ERROR: Failed to download the VS Code server. 'wget' not installed.
Please install wget:
Debian/Ubuntu: sudo apt-get install wget

And after getting a nix-shell with wget:

[nix-shell:/mnt/c/Users/Alexja]$ which wget
/nix/store/a1csfsg5xb0dqdikxdjx8r2h055gw7fw-wget-1.21.3/bin/wget

[nix-shell:/mnt/c/Users/Alexja]$ code .
Updating VS Code Server to version 4af164ea3a06f701fe3e89a2bcbb421d2026b68f
Removing previous installation...
Installing VS Code Server for x64 (4af164ea3a06f701fe3e89a2bcbb421d2026b68f)
Downloading: 100%
Unpacking: 100%
Unpacked 2377 files and folders to /home/nixos/.vscode-server/bin/4af164ea3a06f701fe3e89a2bcbb421d2026b68f.
/home/nixos/.vscode-server/bin/4af164ea3a06f701fe3e89a2bcbb421d2026b68f/bin/remote-cli/code: line 12: /home/nixos/.vscode-server/bin/4af164ea3a06f701fe3e89a2bcbb421d2026b68f/node: No such file or directory

This is the other VSCode-specific error I've been seeing. To get around it, I do the following

[nix-shell:/mnt/c/Users/Alexja]$ cd /home/nixos/.vscode-server/bin/4af164ea3a06f701fe3e89a2bcbb421d2026b68f/

[nix-shell:~/.vscode-server/bin/4af164ea3a06f701fe3e89a2bcbb421d2026b68f]$ nix build nixpkgs#nodejs

[nix-shell:~/.vscode-server/bin/4af164ea3a06f701fe3e89a2bcbb421d2026b68f]$ rm node

[nix-shell:~/.vscode-server/bin/4af164ea3a06f701fe3e89a2bcbb421d2026b68f]$ ln -s result/bin/node node

[nix-shell:~/.vscode-server/bin/4af164ea3a06f701fe3e89a2bcbb421d2026b68f]$ ls -la
total 84
drwxr-xr-x   6 nixos users  4096 Jun 14 10:17 .
drwxr-xr-x   3 nixos users  4096 Jun 14 10:12 ..
drwxr-xr-x   4 nixos users  4096 Jun  8 11:50 bin
drwxr-xr-x  33 nixos users  4096 Jun  8 11:50 extensions
-rw-r--r--   1 nixos users 13380 Jun  8 11:49 LICENSE
lrwxrwxrwx   1 nixos users    15 Jun 14 10:17 node -> result/bin/node
drwxr-xr-x 166 nixos users  4096 Jun  8 11:50 node_modules
drwxr-xr-x   3 nixos users  4096 Jun  8 11:50 out
-rw-r--r--   1 nixos users    62 Jun  8 11:49 package.json
-rw-r--r--   1 nixos users 36857 Jun  8 11:50 product.json
lrwxrwxrwx   1 nixos users    58 Jun 14 10:17 result -> /nix/store/5yd3np2ljp6xpj1nsf1p3kdi3qaq8h4b-nodejs-16.15.0
-rwxr-xr-x   1 nixos users   240 Jun  8 11:47 server.sh

[nix-shell:~/.vscode-server/bin/4af164ea3a06f701fe3e89a2bcbb421d2026b68f]$ code .

< VSCode opens successfully >

[SuperSandro2000]

Installing wget is sufficient to get around the new error. However, I'm running into a VSCode bug right now where the latest version of the VSCode remote server won't run due to some kind of issue with the node binary they bundle 😅. However, the bug referred to in this issue is solved by setting interopPreserveArgvZero = false and having wget available.

I solved that with the following bash function which works with user and system wide code installations and without having windows binaries in $PATH because that slows down PATH enumeration by 300x times.

code() {
  if [[ -n ${WSL_DISTRO_NAME:-} ]]; then
    local bin node node_package user_install system_install
    if [[ -d ~/.vscode-server/bin ]]; then
      for bin in ~/.vscode-server/bin/*/node; do
        if [[ ! -L $bin || -n $(find "$bin" -mtime +10 -print) ]]; then
          echo "
  Fixing vendored nodejs...
  If a new VSCode is downloaded please re-run to fix a new download
"
          node_package=nixpkgs#nodejs-16_x
          [[ ! -v node ]] && node=$(nix eval "$node_package")/bin/node
          [[ ! -f $node ]] && nix build "/nix/var/nix/gcroots/per-user/$USER/$node_package"
          ln -s -fs "$node" "$bin"
          ln -s -fs "$bin" "$(uuidgen)"
        fi
      done
    else
      echo "
  VSCode is now downloading its binary blob remote server.
  After that please re-run to fix the vendored node binary.
"
    fi
    user_install="/mnt/c/Users/$(wslvar USERNAME)/AppData/Local/Programs/Microsoft VS Code/bin/code"
    system_install="/mnt/c/Program Files/Microsoft VS Code/bin/code"
    if [[ -e $user_install ]]; then
      "$user_install" "$@"
    else
      if [[ -e $system_install ]]; then
        "$system_install" "$@"
      else
        ansi --red "No VSCode installation found"
      fi
    fi
  else
    command code "$@"
  fi
}

[zeratax]

@ajaxbits on this commit https://github.com/nix-community/NixOS-WSL/commit/504fb4c305b0a233e79c666293feea7df625ce58 and doing the weird replacing node thing it works for me without having to adjust my configuration.nix in regard to wsl.compatibility.interopPreserveArgvZero

[zeratax]

@SuperSandro2000 i am trying this again and wanted to try your approach, but something seems to be going wrong? https://asciinema.org/a/c3TCfnAl8f24lNCPi6d4Jn0m4

error: stack overflow (possible infinite recursion)
path '/nix/var/nix/gcroots/per-user/nixos/nixpkgs' does not contain a 'flake.nix', searching up error: getting status of '/nix/var/nix/gcroots/per-user/nixos/nixpkgs': No such file or directory /home/nixos/.vscode-server/bin/92da9481c0904c6adfe372c12da3b7748d74bdcb/bin/remote-cli/code: line 12: /home/nixos/.vscode-server/bin/92da9481c0904c6adfe372c12da3b7748d74bdcb/node: No such file or directory 

wsl.compatibility.interopPreserveArgvZero = false or true doesn't seem to affect this

[SuperSandro2000]

You're WSL probably run out of memory while trying to eval/build nodejs

[zeratax]

You're WSL probably run out of memory while trying to eval/build nodejs

huh you're probably right, but I can not really see that? checking taskmanager I never go over 60% and checking free there still seems to be over 6GB free and swap not being used at all? am I overlooking a metric?

[SuperSandro2000]

The little function is not written very robust and well could be broken outside of my machines but try running the following and see what happens:

nix eval nixpkgs#nodejs-16_x

and then symlink that to where vscode-server downloaded its node binary and add a gcroot for it.

[zeratax]

sorry for the late reply, hmm yea also just fails with a stackoverflow :/

[K900]

Is this still an issue?

[K900]

Let's keep all the VSCode issues to #238.