Recent Cursor update breaks WSL remote — “File system provider … not available” / “VS Code Server for WSL closed unexpectedly”

Here’s the updated bug report, now including every step we’ve tried so far:


Bug Report: Cursor → WSL Ubuntu fails to reconnect (“VS Code Server for WSL closed unexpectedly”)

Cursor Version: 0.50.4 (user setup)
VS Code Version: 1.96.2 (Commit 8ea935e…)
Electron/Chromium/Node: 34.3.4 / 132.0.6834.210 / 20.18.3
OS: Windows 10 Pro (10.0.19045) on “QUICKSILVER” (Intel i9-12900K, 128 GB RAM)
Default WSL Distro: Ubuntu (WSL 2)

:lady_beetle: Description

After updating Cursor, opening a new WSL:Ubuntu window shows the Ubuntu filesystem in the tree, but any attempt to open a project folder immediately fails with:

File system provider for vscode-remote://wsl+ubuntu/home/dreamforge is not available.
VS Code Server for WSL closed unexpectedly. Check WSL terminal for more details.

:test_tube: Steps We’ve Tried

  1. Confirmed WSL health

    • wsl --shutdownwsl --list --verbose shows “Ubuntu (Running, WSL 2)”.
  2. Ensured Node & npm installed in WSL

    sudo apt update && sudo apt install -y nodejs npm
    node --version    # 18.19.1
    npm --version     # 9.2.0
    
  3. Installed Claude Code CLI into user‐local prefix

    mkdir -p ~/.npm-global
    npm config set prefix "$HOME/.npm-global"
    echo 'export PATH="$HOME/.npm-global/bin:$PATH"' >> ~/.bashrc
    source ~/.bashrc
    
    • Verified which claude/home/dreamforge/.npm-global/bin/claude
    • claude --version → 0.2.94 (then auto-upgraded to 0.2.100)
    • claude eval "2 + 2" → returned “4”
  4. Removed stale global installs

    sudo npm uninstall -g @anthropic-ai/claude-code
    sudo rm -rf /usr/local/bin/claude /usr/local/lib/node_modules/@anthropic-ai/claude-code
    
  5. Launched project from WSL

    • Copied/moved repo off /mnt/c/… onto Linux FS:

      mv "/mnt/c/Users/PC owner/DreamForge V4" ~/DreamForgeV4
      code ~/DreamForgeV4
      
    • Cleared broken server files: rm -rf ~/.vscode-server ~/.cursor-server

    • Re-ran code . (and code --remote wsl+Ubuntu .) to force fresh download.

  6. Installed Microsoft’s Remote-WSL extension

    • Ensured ms-vscode-remote.remote-wsl was present and up to date.
  7. Set Ubuntu as default WSL distro

    wsl --set-default Ubuntu
    
  8. Removed any Docker-Desktop WSL integration

    code --uninstall-extension ms-vscode-remote.remote-wsl:docker-desktop
    
  9. Restarted everything repeatedly

    • Closed & re-opened Cursor, Windows Terminal → Ubuntu shell, reloaded VS Code windows, clicked “Reconnect Now,” “Reload Window.”
  10. Verified environment variables

    • echo $PATH confirmed ~/.npm-global/bin appears first.

:plus: Additional Steps We Just Tried

  1. Deleted ~/.cursor-server

    • Let Cursor recreate its server install from scratch.
  2. Reinstalled WSL extension in Cursor

    • Uninstalled & re-added the built-in WSL extension via Cursor’s Extensions view.
  3. Performed a clean Cursor reinstall

    • Uninstalled Cursor, removed %APPDATA%\Cursor, %LOCALAPPDATA%\Cursor, %USERPROFILE%\.cursor, then re-installed.
  4. Unregistered & reinstalled Ubuntu

    wsl --unregister Ubuntu
    wsl --install -d Ubuntu
    
  5. Checked Alpine dependencies error

    • Noted libstdc++ missing errors when server attempted Alpine install, but our distro is Ubuntu.

:counterclockwise_arrows_button: Reproduction

  1. Open Cursor → click Remote WSL: Ubuntu (or open folder under \\wsl$\Ubuntu\home\dreamforge…).
  2. The window loads but immediately shows “File system provider … is not available” and refuses to mount files.

:camera: Screenshots & Logs

(Attached in the ticket)

  • The “Attempting to reconnect…” dialog
  • The Alpine dependency error for libstdc++
  • Full $PATH dump
  • wsl --list --verbose output
  • System Info (Windows 10 Pro, 19045, 128 GB RAM)

:prohibited: Impact

Cursor is unusable for WSL-based projects, blocking all editing/testing workflows inside Ubuntu.


If there’s any other diagnostic you’d like us to capture—logs, config files, or a Screen­Cast—just let us know. Thanks for looking into this!

Hi! Could you try switching to the Anysphere Remote WSL extension? You can find it by searching for @id:anysphere.remote-wsl (attaching a screenshot). Please share whether this works for you!

I will try this. What make sit different?

We’ve been getting a # of reports about connection issues with the VSCode Remote extensions, so we rebuilt them from the ground up. The functionality itself should be the same as before, but the connection (and reconnection) logic is improved and more robust.