WSL startup still requires "Reinstall Cursor Server" — daily friction for multiple devs

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

This is a follow-up to a previously closed thread: WSL startup requires reinstall of cursor server. The issue is still present on the latest Cursor versions and is now affecting multiple teammates on a daily basis, hindering normal development workflow.

On a fresh start of Cursor against WSL, the IDE frequently fails to connect to the Cursor server inside the distro, and pops up a dialog whose only viable option is “Reinstall Cursor Server”. After clicking it, the connection succeeds. Without that click, the IDE does not boot into the workspace.

This is not a one-off — it occurs on multiple developer machines in our team, every day, often several times per day. It adds friction to every morning startup and to any wsl --shutdown / reboot cycle.

New insight since the previous thread

There is a clear correlation with whether a shell is already attached to the WSL distro from another, independent window (e.g. a Windows Terminal tab running wsl or bash in the same distro) before Cursor is launched:

  • If no independent shell is open in the distro when Cursor starts → the “Reinstall Cursor Server” prompt appears very often.
  • If an independent shell is already open and active in the distro when Cursor starts → the prompt appears noticeably less often, sometimes not at all.

This suggests a race condition or readiness check during cursor-server startup that depends on the distro already being “warm” / having a live session, rather than Cursor being the first thing to spin it up.

From the previous thread, CPU/memory load inside WSL is not the cause — htop shows the distro idle when the failure occurs (gif was shared in the original thread).

Steps to Reproduce

  1. WSL bind mount setup, see details below
  2. wsl --shutdown on the Windows host.
  3. Make sure no terminal/shell is attached to the WSL distro.
  4. Launch Cursor (it auto-reopens the last WSL workspace).
  5. Observe the “Reinstall Cursor Server” dialog on connection failure.
  6. For comparison: repeat the same steps, but before step 3 open a Windows Terminal tab into the same WSL distro and leave it idle. The failure rate drops significantly.

Bind-mount setup (relevant to home/data persistence)

The user’s data directory is bind-mounted into the WSL distro at boot, before Cursor is launched. The mount is verified in place by the time Cursor starts; Cursor is only launched after this script exits successfully.

Command executed from the Windows bash profile on session start:

wsl --cd / --distribution dev-machine-data --user root -- sh /data-mount.sh
sudo mount -a

/data-mount.sh (run as root inside the distro):

set -euo pipefail   # bash 'strict mode'

if ! grep -q "/mnt/wsl/dev-machine-data" /proc/mounts ; then
    echo "Mount dev-machine-data. ($0)"
    mkdir -p /data /mnt/wsl/dev-machine-data
    mount --bind /data /mnt/wsl/dev-machine-data
fi

So by the time Cursor opens the workspace, /mnt/wsl/dev-machine-data is already a valid bind mount of /data, and the user’s home (which lives under it) is fully accessible. The “Reinstall Cursor Server” prompt is therefore not caused by a missing/unmounted home directory at Cursor startup.

Additional Information

  • Data persists across reboots; the bind mount is idempotent (re-run safe).
  • Same WSL distro / same bind-mount layout works without this prompt in stock VS Code Remote-WSL.
  • Previous thread for full history, .wslconfig / wsl.conf contents, and ps aux | grep cursor output: WSL startup requires reinstall of cursor server

Expected Behavior

Cursor should connect to the WSL distro reliably on first launch without manual intervention, regardless of whether an independent shell is already attached to the distro.

Impact

Multiple teammates (20+) affected daily (for some this discourages switch from alternative IDEs). Each occurrence costs 10–30 seconds plus context switch, and the “Reinstall Cursor Server” wording is alarming for less experienced users who are not sure whether they are about to lose extensions or state.

Operating System

Windows 10/11

Version Information

Version: 3.3.16 (user setup)
VSCode Version: 1.105.1
Commit: 7f0f522221d0ba220e4edb766bb3c47c08c14ab0
Date: 2026-05-06T20:40:56.501Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200

$ wsl --version
WSL version: 2.7.3.0
Kernel version: 6.6.114.1-1
WSLg version: 1.0.73
MSRDC version: 1.2.6676
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.26100.1-240331-1435.ge-release
Windows version: 10.0.26200.8246

Networking mode: NAT (default), per the recommendation in the previous thread.

Does this stop you from using Cursor

No - Cursor works, but with this issue

4

Possibly related, same cluster:

7

Thanks for the detailed follow-up. The warm-vs-cold WSL comparison is useful, and this does sound distinct from a missing home mount or resource exhaustion issue.

Could you share the Remote - WSL output from one failed cold start and one successful warm start?

  1. Run wsl --shutdown

  2. Start Cursor directly, without opening a WSL shell first

  3. When the “Reinstall Cursor Server” prompt appears, open View > Output and select Remote - WSL

  4. Copy the output from that failed attempt

  5. Repeat after wsl --shutdown, but first open an idle Windows Terminal shell in the same distro, then launch Cursor and copy the Remote - WSL output again

Those two logs should show whether the failure is happening during WSL distro startup, server bootstrap, or the later socket/handshake connection. For now, keeping an idle WSL shell open before launching Cursor is a reasonable workaround, but I agree Cursor should handle the first cold launch reliably.