How to Use VS Code with WSL via the Remote-WSL Extension

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.

Where the VS Code Server component actually lives, and updating it

The VS Code Server component that Remote-WSL installs inside your distribution lives under a hidden directory in your Linux home folder, versioned to match your Windows-side VS Code installation. Updating VS Code on Windows normally triggers a matching update to this server component automatically the next time you connect — if a Remote-WSL connection behaves unexpectedly after a VS Code update, confirming both sides report the same version is a reasonable first diagnostic step before assuming a genuine bug.

Handling multiple WSL windows for different projects at once

Opening several Remote-WSL windows simultaneously, each connected to a different project (potentially even in different distros), works the same way multiple ordinary VS Code windows would — each maintains its own independent connection and its own VS Code Server session, so activity in one doesn’t affect another’s terminal state or running extensions. This independence extends to crashes as well: a hung or crashed Remote-WSL connection in one window generally doesn’t take down a separate window’s own, entirely independent connection to a different distro or project.

Debugging performance issues specific to the Remote-WSL connection itself

If VS Code feels sluggish specifically when Remote-WSL connected — distinct from the underlying project’s own build or test performance — checking the Remote-WSL extension’s own log output (via the Command Palette’s “Remote-WSL: Show Log” command) can reveal connection-specific issues, like a slow-to-respond distribution or a resource-constrained WSL2 VM, that a purely Windows-side performance investigation wouldn’t surface.

Treat a persistently slow connection as worth investigating specifically at this layer first, rather than immediately assuming your project itself has simply grown too large for comfortable editing.

Related:

Sources: