How to Fix VS Code Not Working Inside WSL Ubuntu (Complete WSL2 Guide)New Lesson

By /

Back to: WSL2 for Developers: Complete Beginner to Productivity Setup (inprogress)

One of the best features of WSL2 is the ability to open Linux projects directly inside Windows VS Code using:

code .

However, after customizing WSL configurations, this command may suddenly stop working and produce errors like:

-bash: /mnt/vscode/bin/code: No such file or directory

This guide explains why that happens and how to fix it properly.

Understanding the Problem

A common customized WSL setup may look like this.

Windows .wslconfig

Located at:

C:\Users\<Username>\.wslconfig

Example:

[wsl2]
memory=14GB
processors=8
swap=4GB
localhostForwarding=true

Ubuntu /etc/wsl.conf

[boot]
systemd=true

[user]
default=user_name

[automount]
enabled=false

[interop]
appendWindowsPath=false

The issue usually comes from these two settings:

enabled=false
appendWindowsPath=false

Why code . Stops Working

WSL normally accesses Windows VS Code from:

/mnt/c/Users/<Username>/AppData/Local/Programs/Microsoft VS Code/bin

But the following settings break that behavior.

appendWindowsPath=false

This prevents WSL from automatically importing Windows executables into Linux’s $PATH.

As a result:

code .

cannot find VS Code automatically.

automount=false

This disables automatic mounting of Windows drives like:

/mnt/c

Without /mnt/c, WSL cannot access the Windows installation directory at all.

Common Symptoms

Typical errors include:

-bash: /mnt/vscode/bin/code: No such file or directory

Running:

which code

may return nothing.

But:

type -a code

may reveal an old broken alias such as:

code is aliased to `/mnt/vscode/bin/code'

This stale alias is often left behind from older VS Code or WSL integrations.

Step 1 — Verify VS Code Exists

First, confirm that Windows VS Code is installed correctly.

Run:

ls "/mnt/c/Users/<WindowsUsername>/AppData/Local/Programs/Microsoft VS Code/bin"

Expected output:

code
code.cmd
code-tunnel.exe

If these files exist, VS Code itself is fine.

Step 2 — Locate the Broken Alias

Check how code is currently defined:

type -a code

If output shows something like:

code is aliased to `/mnt/vscode/bin/code'

then a broken alias exists.

Find where it is defined:

grep -R "alias code=" ~/.bashrc ~/.profile ~/.bash_aliases ~/.bash_login /etc/bash.bashrc /etc/profile.d 2>/dev/null

Open the file that contains the alias:

nano ~/.bashrc

Remove or comment out the line:

alias code='/mnt/vscode/bin/code'

Save the file afterward.

Step 3 — Add VS Code to PATH Manually

Since Windows path injection is disabled, VS Code must be added manually.

Run:

export PATH="$PATH:/mnt/c/Users/<WindowsUsername>/AppData/Local/Programs/Microsoft VS Code/bin"

Now verify:

which code

Expected result:

/mnt/c/Users/<WindowsUsername>/AppData/Local/Programs/Microsoft VS Code/bin/code

Then test:

code .

VS Code should now launch correctly from WSL.

Step 4 — Make the Fix Permanent

To preserve the PATH after restarting WSL, append it to .bashrc:

echo 'export PATH="$PATH:/mnt/c/Users/<WindowsUsername>/AppData/Local/Programs/Microsoft VS Code/bin"' >> ~/.bashrc

Reload the shell:

source ~/.bashrc

Or restart Bash completely:

exec bash

Optional: Restore Default WSL Integration

For most developers, enabling these settings provides the smoothest experience:

[automount]
enabled=true

[interop]
appendWindowsPath=true

After modifying the configuration, restart WSL from PowerShell:

wsl --shutdown

This restores automatic Windows ↔ Linux integration.

Recommended WSL Configuration for Development

For general software development, the following setup is usually ideal:

[automount]
enabled=true

[interop]
appendWindowsPath=true

Benefits include:

  • code . support
  • Clipboard integration
  • Easier Git workflows
  • Browser launching from Linux
  • Better Docker Desktop compatibility
  • Improved interoperability between Windows and WSL

Final Thoughts

This issue is usually not caused by a broken VS Code installation.

The real causes are typically:

  • Disabled Windows path injection
  • Disabled drive automounting
  • A stale code alias pointing to an invalid location

Once the old alias is removed and VS Code is correctly added to the Linux PATH, the integration works normally again.

Scroll to Top