How to Use VS Code with WSL via the Remote-WSL Extension
A complete walkthrough editing and debugging code that lives inside your WSL distro, using a Windows-installed VS Code, without ever copying files to the Windows side or fighting cross-filesystem performance.
The Remote-WSL extension lets VS Code, installed normally on Windows, edit and run code that lives entirely inside your WSL distro — genuinely running VS Code’s server-side components inside Linux, not just displaying remote files.
Step 1: install VS Code on Windows
Download and install VS Code normally on Windows —
not inside WSL itself
Step 2: install the WSL extension
VS Code → Extensions → search "WSL" →
install the official Microsoft "WSL" extension
Step 3: open a WSL folder directly from the command line
# from inside your WSL distro:
cd ~/myproject
code .
Running code . from inside a WSL shell automatically launches VS Code (on Windows) connected to that specific folder inside WSL — no manual connection setup required.
Step 4: understand what’s actually running where
VS Code’s UI runs natively on Windows, but a VS Code Server component runs inside your WSL distro, handling file access, extensions, and any integrated terminal — this split means file operations and language server processing happen on the Linux side, avoiding the cross-filesystem performance overhead you’d hit editing /mnt/c files with a Windows-native tool instead.
Step 5: verify you’re actually connected to WSL, not browsing a network path
Check the green indicator in VS Code's bottom-left corner —
it should read "WSL: <DistroName>"
This confirms VS Code is running its remote server inside WSL, rather than just displaying files via the \\wsl$\ network path from a purely Windows-side VS Code instance.
Step 6: install extensions specifically for the WSL side
Extensions needed for your actual development work (language support, linters, debuggers) need to be installed into the WSL-connected VS Code window specifically — a UI-focused extension installed only on the Windows side doesn’t automatically apply to your WSL-connected session.
Step 7: use the integrated terminal for a genuinely native Linux shell
VS Code → Terminal → New Terminal
The integrated terminal in a WSL-connected VS Code window is a genuine WSL shell, not a Windows shell with WSL commands available — everything you run there executes inside your Linux distro directly.
Step 8: debug applications running inside WSL directly
Language-specific debugger extensions (Python, Node.js, and others) work through the same Remote-WSL connection, letting you set breakpoints and step through code running inside your Linux distro exactly as you would debugging a purely native Windows or Linux setup.
Step 9: open a project on a specific distro if you have multiple installed
# from inside the specific distro you want:
code .
Since the connection is initiated from inside whichever distro’s shell you run code . from, working with multiple installed distros just means running the command from the correct one.
Why this architecture is meaningfully better than editing via the \wsl$\ network path directly
Opening WSL files in a purely Windows-side VS Code via the \\wsl$\ network path works, but incurs the same cross-filesystem overhead as any other Windows-side access to Linux files — Remote-WSL’s actual server-inside-Linux architecture avoids this entirely by keeping file access, language processing, and terminal execution all genuinely running on the Linux side, with only the UI itself running on Windows.