Fix VS Code WSL Server 404

After a VS Code update, I hit a Remote WSL failure even though WSL itself still worked from the command line.

The WSL terminal opened normally:

wsl

But VS Code could not connect to the WSL distro. The Remote WSL log showed a failed download like this:

https://update.code.visualstudio.com/commit:<commit-id>/server-linux-x64/insider

HTTP request sent, awaiting response...
404 Not Found

ERROR: Failed to download
https://update.code.visualstudio.com/commit:<commit-id>/server-linux-x64/insider
to /home/<user>/.vscode-server-insiders/bin/<commit-id>-<timestamp>.tar.gz

The important details are:

This is a VS Code Remote WSL server install problem, not a general WSL failure.

Quick answer

If VS Code Remote WSL fails with 404 Not Found while downloading server-linux-x64/insider, WSL is probably fine. The VS Code client is trying to install a matching VS Code Server build inside WSL, but the update service does not have that exact Insiders server package. In this case, the missing commit was fcff1a779c023e586c6d44a18c04a04166b59f37. Close VS Code, update VS Code and the WSL extension again, delete the broken WSL server install under ~/.vscode-server-insiders/bin/<commit-id> or ~/.vscode-server-insiders/bin, then reconnect. If the Insiders build still returns 404, use a previous VS Code Insiders client build and manually install the matching previous server commit, or switch to stable VS Code until the broken Insiders commit is replaced.

Why WSL works but VS Code WSL fails

This failure is confusing because wsl.exe still works. That makes it look like VS Code is falsely reporting a WSL problem.

The reason is that VS Code Remote WSL has an extra moving part. When VS Code opens a WSL folder, it does not just open a Linux shell. It installs and starts a small VS Code Server inside the WSL distro. That server must match the exact VS Code client build on Windows.

The flow looks like this:

If step 4 fails with 404 Not Found, WSL can still be healthy. Bash, Ubuntu, files, and Linux commands can all work. The broken part is the matching VS Code Server package that Remote WSL needs.

This is why testing only with wsl is not enough. wsl proves the distro starts. It does not prove the VS Code Server for the current client build is installed.

Root cause

The log contains the root cause:

ERROR: Failed to download
https://update.code.visualstudio.com/commit:fcff1a779c023e586c6d44a18c04a04166b59f37/server-linux-x64/insider

The URL is built from the local VS Code client:

commit:<commit-id>
platform: server-linux-x64
quality: insider

For a Remote WSL connection, the client and server versions must line up. If the Windows client is an Insiders build, the server download URL uses the insider channel and the server is installed under:

~/.vscode-server-insiders

For stable VS Code, the quality is usually stable and the server folder is:

~/.vscode-server

The 404 Not Found means the update service did not return a tarball for that exact commit and channel. In practice, I see a few common causes:

• VS Code Insiders updated to a build before the matching Linux server tarball was available.
• The WSL extension and VS Code client are out of sync after an update.
• A failed previous install left a broken folder under ~/.vscode-server-insiders/bin.
• The machine is using VS Code Insiders unintentionally instead of stable VS Code.
• A proxy, cache, security gateway, or mirror is returning a stale 404 for the server URL.

Because the failed URL ends in /insider, the first thing I check is whether I am using VS Code Insiders on purpose. If I only need the normal editor, switching back to stable is often the quickest fix.

The specific failure here is more direct: the Insiders client requested this exact commit, and that commit was not found on the VS Code update server:

fcff1a779c023e586c6d44a18c04a04166b59f37

If the server package for the current client commit does not exist, deleting the WSL server cache can retry the download, but it cannot make that missing commit appear. The real fix is to use a VS Code client build whose matching server commit exists.

Fix 1: Update VS Code and the WSL extension

Start on the Windows side.

Open VS Code, then run:

Help > Check for Updates

Then update extensions:

Extensions > WSL > Update

Or use the Command Palette:

Extensions: Show Outdated Extensions

After updates finish, close every VS Code window. Do not leave a WSL-connected window open in the background.

Then shut down WSL from PowerShell:

wsl --shutdown

Open VS Code again and try the WSL connection.

If the problem was a client-extension mismatch, this may be enough.

Fix 2: Remove the broken WSL server install

If the same error returns, delete the broken server install inside WSL so VS Code can reinstall it cleanly.

For VS Code Insiders, run this inside WSL:

rm -rf ~/.vscode-server-insiders/bin

For stable VS Code, use:

rm -rf ~/.vscode-server/bin

If you want a narrower cleanup, remove only the failing commit folder. The log tells you the commit ID:

rm -rf ~/.vscode-server-insiders/bin/<commit-id>

Then shut down WSL from Windows:

wsl --shutdown

Reconnect from VS Code.

This forces Remote WSL to repeat the server install. If the server package exists now, the connection should recover.

Fix 3: Install a previous matching commit manually

If the current Insiders commit is missing from the update server, you can work around it by using the previous VS Code Insiders commit and installing the matching server package in WSL.

Do not skip this rule: the VS Code Server commit in WSL must match the VS Code client commit on Windows. Installing an older server while still running the newer Windows client usually does not fix the issue. The newer client will keep asking for its own missing commit.

The workflow is:

1. Find a previous VS Code Insiders commit.
2. Run the Windows VS Code Insiders client for that same previous commit.
3. Download the matching server-linux-x64/insider tarball.
4. Extract it into ~/.vscode-server-insiders/bin/<previous-commit>.
5. Reconnect to WSL with that previous client build.

First, confirm the broken current commit from the log:

fcff1a779c023e586c6d44a18c04a04166b59f37

Then check whether WSL already has an older Insiders server folder from a previous working connection:

ls -lt ~/.vscode-server-insiders/bin

You may see folders like this:

drwxr-xr-x 12 sea sea 4096 Jun 24 20:10 <previous-commit>
drwxr-xr-x  2 sea sea 4096 Jun 25 03:29 fcff1a779c023e586c6d44a18c04a04166b59f37

The older folder name is the previous commit. If that older commit matched the VS Code Insiders build you were using before the update, it is the best candidate.

If you still have the previous VS Code Insiders installer or portable ZIP on Windows, open that older client and check its commit:

code-insiders --version

The first line is the version. One of the following lines is the commit. Use that commit as <previous-commit>.

Now install the matching previous server package inside WSL:

previous_commit="<previous-commit>"
server_dir="$HOME/.vscode-server-insiders/bin/$previous_commit"
server_url="https://update.code.visualstudio.com/commit:$previous_commit/server-linux-x64/insider"
tarball="/tmp/vscode-server-insiders-$previous_commit.tar.gz"

rm -rf "$server_dir"
mkdir -p "$server_dir"

wget -O "$tarball" "$server_url"
tar -xzf "$tarball" -C "$server_dir" --strip-components=1
rm -f "$tarball"

test -x "$server_dir/server.sh" && echo "VS Code Server installed: $server_dir"

If wget returns 404 Not Found for the previous commit too, that commit is not available either. Pick another previous commit or use stable VS Code.

After extracting the server, shut down WSL from PowerShell:

wsl --shutdown

Then open the previous VS Code Insiders client build and connect to WSL again.

If VS Code immediately tries to download fcff1a779c023e586c6d44a18c04a04166b59f37 again, you are still running the broken newer client. Close it and open the previous client build instead.

Fix 4: Use stable VS Code instead of Insiders

If the failing URL ends in /insider, the Windows client is using the Insiders channel. Insiders builds are useful for testing new features, but they can occasionally hit this kind of timing issue.

Check what command you are launching:

code --version
code-insiders --version

If code-insiders is the one failing, install or open stable VS Code and use the stable WSL extension path instead.

From WSL, open the current folder with stable VS Code:

code .

Open with Insiders only when you actually want Insiders:

code-insiders .

Stable VS Code uses:

~/.vscode-server

Insiders uses:

~/.vscode-server-insiders

Keeping those separate helps troubleshooting. If only Insiders fails with 404 and stable works, WSL is not the problem.

Fix 5: Check proxy and download access

In this case, the log shows a real HTTP response:

HTTP request sent, awaiting response...
404 Not Found

That is different from DNS failure, TLS failure, or a timeout. Still, if you work behind a corporate proxy or security gateway, check whether the download URL is being rewritten or cached.

From WSL, test basic network access:

wget -S --spider https://update.code.visualstudio.com/

Also check whether proxy variables are set:

env | grep -i proxy

If your environment requires a proxy, configure it for WSL tools such as wget and curl. If a proxy cache is returning a stale 404 for a new Insiders build, stable VS Code is usually the faster workaround.

Fix 6: Start clean from Windows

If the WSL server folder cleanup does not help, do a clean restart of the moving parts:

1. Close all VS Code windows.
2. In Task Manager, end leftover Code.exe or Code - Insiders.exe processes.
3. In PowerShell, run wsl --shutdown.
4. Open Windows VS Code directly from the Start menu.
5. Update VS Code and the WSL extension.
6. Use the Command Palette command WSL: Connect to WSL.

If you normally start VS Code from inside WSL with code ., test both directions:

code .
code-insiders .

The command that fails tells you which channel and server folder to clean.

What not to delete first

Do not start by deleting the whole WSL distro, reinstalling Ubuntu, or recreating your project. The log already shows that WSL starts and that VS Code reached the download step.

The safer cleanup targets are:

~/.vscode-server-insiders/bin
~/.vscode-server/bin

Those folders are VS Code Remote server installs. VS Code can recreate them.

I also avoid deleting the extension folders first:

~/.vscode-server-insiders/extensions
~/.vscode-server/extensions

Deleting extensions is sometimes useful, but it is not the first fix for a server tarball 404. Start with the bin folder because that is where the failed server version is installed.

Quick repair commands

For VS Code Insiders:

wsl --shutdown
wsl

Then inside WSL:

rm -rf ~/.vscode-server-insiders/bin
exit

Back in PowerShell:

wsl --shutdown

Then reopen VS Code Insiders and connect to WSL again.

For stable VS Code:

wsl --shutdown
wsl

Then inside WSL:

rm -rf ~/.vscode-server/bin
exit

Back in PowerShell:

wsl --shutdown

Then reopen stable VS Code and connect to WSL again.

How to tell it is fixed

A healthy reconnect should recreate the server folder:

ls ~/.vscode-server-insiders/bin

or, for stable:

ls ~/.vscode-server/bin

You should see a folder named after the current VS Code commit. The WSL log should move past the download step and start the server instead of ending at 404 Not Found.

From the VS Code Command Palette, you can also check:

WSL: Show Log

The important sign is that the log no longer shows a failed download for the current commit.

Bottom line

When VS Code Remote WSL fails after an update with a URL like this:

https://update.code.visualstudio.com/commit:<commit-id>/server-linux-x64/insider

and the response is 404 Not Found, the WSL distro is usually not broken. The VS Code client is trying to install a matching remote server inside WSL, and that exact server package is missing or the local server cache is stale.

Clean the WSL server bin folder, update VS Code and the WSL extension, restart WSL, and reconnect. If the failing channel is Insiders and the same commit still returns 404, use stable VS Code until a newer Insiders build is available.