I've been having trouble with opening visual studio code.

The scenario is that I have a server filesystem mounted in my local pc (UBUNTU WSL) using SSHFS.

In normal cases, I can open file using visual studio code using the command code <filename>.
However, when I am inside the server filesystem directory and I try to use this command I get the error

/mnt/c/Users/kurti/AppData/Local/Programs/Microsoft VS Code/Code.exe: Invalid argument

Surprisingly, I can use gedit in the same manner without any problem e.g. gedit <filename>.

Then what is weird is that I can use the code to open a file/directory in the server filesystem when I am any folder in my local fileystem. With this I can easily open the server file using code </full/path/to/file>.

Is this a possible bug in visual studio code or a problem with my system ?

Edit: I created a new work around function/command which is
command name: vcode

fpath=$(realpath $1)
(cd $HOME; code fpath)

Update: I reported it in the WSL github page as an issue https://github.com/microsoft/WSL/issues/7890

More specific details as follows

Repo steps

In WSL terminal,

  1. Mount a server filesystem using sshfs (in my case it is a university supercomputer)
    sshfs -C <server_name_and_ip> <mount_location>
    designated mount_location is an empty directory called smith_server with path /home/k/smith_server/
  2. Go to directory cd /home/k/smith_server
  3. Open directory in visual studio code code .

Expected behavior

The expected behavior is that visual studio will open the directory/file regardless of the current working directory.

Actual behavior

The actual behavior is that when the current working directory is inside the mounted server filesystem, launching the command code . or code <filename> will result in the error code.

/mnt/c/Users/kurti/AppData/Local/Programs/Microsoft VS Code/Code.exe: Invalid argument

Some examples that are working,

  1. When the working directory is not part of the mounted server filesystem, code . or code <file> works fine.
  2. When the working directory is not part of the mounted server filesystem, using code to a full path of a file/directory in the server filesystem e.g. code /home/k/smith_server can successfully open the file/directory without problems.
  3. When the working directory is inside the mounted server filesystem, gedit <file> works fine
  4. When the working directory is inside the mounted server filesystem, code $HOME also gets an error.

The conclusion on my end is that there are problems when invoking code command when inside the mounted server filesystem. Additionally, this doesn't happen when gedit was used. However, when outside the mounted server filesystem, the code command can be invoked and also access the mounted filesystem by using a full path. Perhaps for something is happening when tracing the Code.exe file. Linux-based software like gedit is not affected but perhaps the Windows-based software like Code.exe, that are just being interfaced are affected?

  • This might be a bug with how VS Code works in WSL. I suggest filing an GitHub issue to report this.
    – cocomac
    Jan 4, 2022 at 4:12
  • I'll try to give this a try on my system later today. Good to see you at least have a workaround. Jan 4, 2022 at 13:48
  • 1
    @cocomac Thanks for the suggestion. I submitted a report on the github.
    – Kurt Rojas
    Jan 5, 2022 at 1:59
  • @NotTheDr01ds Thanks, you can see the more specific steps in the update or in the issue I submitted in github
    – Kurt Rojas
    Jan 5, 2022 at 2:10

1 Answer 1


I was able to reproduce this quite readily.


  • Unmount the existing fuse mount:

    fusermount -u /home/k/smith_server
  • Edit /etc/fuse.conf as root:

    sudo -e /etc/fuse.conf
  • Uncomment the user_allow_other option

  • Remount with the allow_root option:

    sshfs -o allow_root [user@]<remote_server>:/path /home/k/smith_server

More Details:

Note that this isn't just a problem with sshfs. You'd run into it when launching VSCode from within any fuse-based mount point.

I'm honestly not quite sure of the root cause here, but ...

You'll notice that, without the above solution in place, if you attempt to browse to \\wsl$\Ubuntu\home\k\smith_server\, you won't be able to enter that directory. You'll have access to your home directory, but you won't be able to access smith_server.

That tells me that even though Windows/WSL enforces permissions for your user when browsing (by default, unless you override this in /etc/wsl.conf), it still seems to be doing so as root in the background.

So, once we figure this out, it's no surprise that VSCode can't handle being launched from a directory which, to it, doesn't exist.

This works when you launch it from $HOME because VSCode initializes, then switches to the "Remote - WSL" extension, which communicates with the VSCode server that was installed in your WSL instance (in ~/.vscode-server). Once that happens, it's accessing the fuse-mounted filesystem as your user, and everything's happy.

Per man fuse:

No other user (including root) can access the contents of the mounted filesystem.

But, there is the option to override this with either -o allow_other or -o allow_root. And to enable either of these, the aforementioned /etc/fuse.conf option needs to be set appropriately.

Then, VSCode has proper access to the directory when launching.

You'll also see that you can now browse, via Windows, to \\wsl$\Ubuntu\home\k\smith_server\.

  • 1
    Thank you very much for the effort. It actually helped!
    – Kurt Rojas
    Jan 11, 2022 at 4:31

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.