Skip to content
daniel@cosenza:~/blog
WSLHow-To August 24, 2026 3 min read

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.