Windows Subsystem for Linux (WSL) works pretty well for making most commandline Linux tools available and working on Windows without modification. However, it gets a little tricky for development, when one wants to

  • Build a project using a Linux toolchain that doesn't have a well-supported Windows equivalent (Ruby, Node, etc)
  • Edit files using a Windows-based GUI editor such as Visual Studio code.

The problem is that Windows apps cannot modify files inside the virtual lxss filesystem. Directly modifying these files is known to cause all sorts of issues.

Therefore, there seem to be only two suboptimal choices when it comes to using WSL for development:

  1. Store the project under lxss (/home/foo). The normal toolchain works properly. However, editing is limited to either terminal-based Vim/Emacs or whatever can be run under a janky X server, which is less smooth than native editors running on Windows.

  2. Store the project under the Windows filesystem (/mnt/c/Users/foo). Now any Windows-based editor can be used for development. However, the Linux-based toolchain is fragile as it's not designed to be used on a "network drive", and can cause problems with file watching or databases.

Is there any way to get the best of both worlds here - that is, to be able to edit using a native Windows application, but still have the Linux toolchain work as it normally would on a local drive?

6 Answers 6


Microsoft has recently added comprehensive support for this, and it should be generally available in the April 2019 (19H1) update. Once it's ready, a 9P server will run in the background whenever a Linux distro is running. The 9P server will be able to handle Linux filesystem metadata, and Windows will be able to treat it as a network drive so it can access it safely. You can read about it at https://blogs.msdn.microsoft.com/commandline/2019/02/15/whats-new-for-wsl-in-windows-10-version-1903/.

With the new feature, you'll be able to safely access both Windows and Linux filesystem files from Windows, as long as you go through the 9P server. This will be handled natively from within WSL. For example, from the WSL command line you'll be able to type code /mnt/c/Users/username/src/windows-file.txt to open a Windows file in VS Code, or type code /home/username/src/linux-file.txt to open a Linux file in VS Code.

If you're not part of the Windows Insider Program, you won't have access to this yet so you'll still have to use an older method, such as wslpath.

wslpath will convert between Windows- and Linux-style paths so you can easily open Windows files from the WSL command line. As per https://github.com/Microsoft/WSL/issues/3146#issuecomment-388118689, it will refuse to convert Linux filesystem paths (i.e. %AppData%\lxss), because without 9P it's unsafe to modify these files from Windows. This means you can't open /home/username/src/linux-file.txt, but you can use code "$(wslpath -aw /mnt/c/Users/username/src/windows-file.txt)".

In the past, there were a number of third-party tools to perform the same conversion but wslpath does it natively-- in fact, ls -l /bin/wslpath shows that it's just a link to /init.

  • @alex wsltools can convert the Linux paths to their Windows equivalents. This way, you can open a Windows program from the Linux command line, and tell it to open a file on the Windows filesystem. Mar 1, 2019 at 17:36
  • Don't think so. blogs.msdn.microsoft.com/commandline/2016/11/17/…. Can you provide any reference that it is safe to do so?
    – Alex
    Mar 3, 2019 at 16:37
  • @alex thanks for bringing this up. This is a good point to clarify. The link you shared (which is also in OP's question) is telling you not to open files in the Linux filesystem from Windows (i.e. don't use Windows apps to change things under %AppData%\lxss). My answer and my previous comment both describe how to open Windows files inside Windows programs from the WSL command line (e.g. open "C:\Users\Username\src\example.txt" from its WSL path "/mnt/c/Users/Username/src/example.txt"). There's also a new method coming out. I've updated my answer to show the distinction and new method. Mar 3, 2019 at 21:48
  • 2
    Good news: WSL can now edit linux files without issues with Win10 1903: devblogs.microsoft.com/commandline/… "In the past, creating and changing Linux files from Windows resulted in losing files or corrupting data. Making this possible has been a highly requested and long anticipated feature. We’re proud to announce you can now easily access all the files in your Linux distros from Windows."
    – KERR
    May 13, 2019 at 1:20
  • 1
    I'm confused. First you said that 1) you can use code /mnt/c/Users/username/src/windows-file.txt and 2 ) you can use code /home/username/src/linux-file.txt. Then you said that 3) you can't open /home/username/src/linux-file.txt, but 4) you can use code "$(wslpath -aw /mnt/c/Users/username/src/windows-file.txt)". Doesn't 3) contradict 2)? And why do you need wslpath in 4), since you can use 1)? Jul 2, 2021 at 16:45

In the first half of 2018, Microsoft released some improvements to WSL that address some of these issues:

Neither of these wholly address the issues in my original question, but they may improve usability in certain specific cases.

  • Thanks! Keep it updated. I would even be fine if it let me "safely" use my favourite GUI editor for select files, I can live without proper build-tools integration (could be done from the console). Even temporarily "rsync-ing" files to local windows copy would be fine as long as it's done transparently. I'm approaching an annoying point there it's too hard to edit and keep track of all the files from CLI (at least for me), and I really just want "do all the stuff on windows, "send/copy" code to WSL, run tools there.
    – Dan M.
    Sep 27, 2018 at 11:45

If you want to run linux commands and edit with windows editors. You could hold your source code ( that you want to edit and test ), somewhere in your file system ( like c:\source\ ) And access that in the linux console through /mnt/c/source. Hope this helps.


I'm sure smarter people than me have looked at this question. But I'll answer it. I honestly believe the answer is currently no. There is no better way to get the best of both worlds, other than the ones you have mentioned (that I know of).

I'm sure it's not the answer anyone wants, but I think it's the correct answer. I know it's something that Microsoft is trying to make smoother, but it's not there yet.


I found Cygwin is capable of working with WSL out of the box.

P9 network FS is exposed via UNC path pattern \\wsl$\DISTRO, like \\wsl$\debian.

Cygwin has syntax for mounting UNC, like:

mount '//wsl$/debian' /wsl/debian

Find the list of your distros with wsl -l and mount them permanently in Cygwin's /etc/fstab:

//wsl$/debian /wsl/debian      ntfs binary,noacl,posix=0 0 0
//wsl$/ubuntu /wsl/ubuntu      ntfs binary,noacl,posix=0 0 0
//wsl$/alpine /wsl/alpine      ntfs binary,noacl,posix=0 0 0

Now you can use Cygwin's Emacs W32, Midnight commander, etc.


UPDATE 2022 MS Code supports WSL: https://docs.microsoft.com/en-us/windows/wsl/tutorials/wsl-vscode

Support in other IDEs is coming.


Now Visual Studio Code supports (As I am using it). "WSL extension" which allows you to perform CRUD (Create, read, update, delete )files/folder from Linux location. Though I am still struggling getting the same setup for atom, which was my choice of editor for Rails application development at Linux platform.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .