Fix "VS Code Server for WSL closed unexpectedly" When Connecting to WSL

The Error

You click "Connect to WSL" in VS Code — or just open a WSL folder — and get this:

VS Code Server for WSL closed unexpectedly. Check the WSL terminal for more details.

The window hangs for 10–30 seconds, then dies. Nothing opens. It tends to happen right after a Windows update, a VS Code update, or when WSL has a bad day.

Why This Happens

Behind the scenes, VS Code installs a server binary inside your WSL distro at ~/.vscode-server/ and spawns it whenever you connect. When that process crashes or refuses to start, you get this error. The most common culprits:

• Stale or corrupted server files left over from an older VS Code version
• WSL2 networking issues — DNS broken, no internet to fetch the server binary
• Bad permissions on ~/.vscode-server
• VS Code updated on Windows, but the old server binary is still cached inside WSL
• WSL itself crashed or has corrupted state
• Antivirus (usually Windows Defender) quarantining the server binary

Step-by-Step Fix

Step 1: Kill Stale Server Processes

Open a WSL terminal directly — search "Ubuntu" (or your distro name) in the Start menu. Don't go through VS Code. Then kill any leftover server processes:

pkill -f vscode-server
pkill -f node

Confirm nothing survived:

ps aux | grep vscode

Step 2: Nuke the VS Code Server Cache

This single command fixes the problem 80% of the time. After a VS Code update, the cached server binary goes stale — deleting it forces a clean download on the next reconnect:

rm -rf ~/.vscode-server

On VS Code Insiders, also run:

rm -rf ~/.vscode-server-insiders

Try reconnecting now. VS Code pulls the correct server version automatically.

Step 3: Verify WSL Can Reach the Internet

On first connect, VS Code downloads the server binary from Microsoft's servers. A broken WSL network silently kills this step.

curl -I https://update.code.visualstudio.com

If it hangs or errors, WSL DNS is the culprit. Override it:

# Check what's currently in there
cat /etc/resolv.conf

# Replace with working nameservers
sudo tee /etc/resolv.conf <<EOF
nameserver 8.8.8.8
nameserver 1.1.1.1
EOF

WSL regenerates resolv.conf on every restart unless you disable that behavior:

# In /etc/wsl.conf
sudo tee -a /etc/wsl.conf <<EOF
[network]
generateResolvConf = false
EOF

Step 4: Restart WSL Completely

Run this from PowerShell or CMD — not inside WSL:

wsl --shutdown

Wait about 5 seconds, then reopen your distro. A full shutdown wipes the WSL2 VM state entirely. That clears networking glitches, zombie processes, and other gremlins that simply closing a terminal won't touch.

Step 5: Check Disk Space and Permissions

A full disk silently blocks the server install. Check it first:

df -h ~
ls -la ~ | grep .vscode

If ~/.vscode-server has wrong permissions after recreating:

chmod 755 ~/.vscode-server
chown -R $USER:$USER ~/.vscode-server

Step 6: Read the Server Logs

Connect to WSL manually and dig into what the server actually says:

ls ~/.vscode-server/
cat ~/.vscode-server/bin/*/server.log 2>/dev/null || echo "No log yet"

Even better — run the binary directly so errors go straight to stdout:

~/.vscode-server/bin/*/server.sh --port 0 --host 127.0.0.1

Getting cannot execute binary file? The download is corrupt. Go back to Step 2.

Step 7: Check Windows Defender

Defender occasionally quarantines the Node binary that VS Code Server relies on. Open Windows Security → Virus & threat protection → Protection history and look for anything flagged from a path like \\wsl$\Ubuntu\home\...\vscode-server. If you find it, restore the file and add an exclusion for that folder.

Step 8: Reinstall the Remote WSL Extension

Sometimes the fault is on the Windows side, not in WSL at all. Open the Extensions panel, find WSL (ms-vscode-remote.remote-wsl), click the gear icon → Uninstall. Restart VS Code, then reinstall. This clears corrupted extension state sitting in your AppData folder.

Step 9: Nuclear Option — Reset the WSL Distro

Last resort. Back up your data first:

# In PowerShell
wsl --export Ubuntu C:\backup\ubuntu-backup.tar

# Wipe and reimport
wsl --unregister Ubuntu
wsl --import Ubuntu C:\WSL\Ubuntu C:\backup\ubuntu-backup.tar

Verify the Fix

• Open VS Code on Windows
• Press Ctrl+Shift+P → type Remote-WSL: New Window
• The bottom-left corner should show WSL: Ubuntu (or your distro name)
• Open a terminal inside VS Code (Ctrl+``) and run uname -a` — you should see Linux output, not Windows
• Confirm the server process is alive: ps aux | grep vscode-server

Prevent It From Breaking Again After Updates

VS Code updates itself on Windows silently. The old server binary stays cached in WSL until the next connection cleans it up — and sometimes it doesn't bother. Drop this snippet into ~/.bashrc to trim stale versions automatically on login:

# Keep only the 2 most recent vscode-server versions
if [ -d ~/.vscode-server/bin ]; then
  ls -t ~/.vscode-server/bin | tail -n +3 | xargs -I{} rm -rf ~/.vscode-server/bin/{}
fi

Also keep VS Code current on Windows: Help → Check for Updates. A version mismatch between the Windows client and the WSL server binary is a reliable way to trigger this exact crash.