Where does the bug appear (feature/product)?
Cursor IDE
Describe the Bug
Cursor’s main process (Cursor.exe) periodically spawns wsl.exe --list --running --quiet as a direct child process — independent of any extension, workspace, or user action — roughly every 20–40 seconds. On a machine where WSL is not installed, this probe fails and appears to trigger Windows’ WSL bootstrap flow, which surfaces as a wsl.exe --update --confirm --prompt-before-exit process and a visible “Install/Update WSL” popup. This happens repeatedly, disrupting the user during normal use, and specifically correlates with Agent Mode’s shell tool calls (“Waited for shell” / “Read terminal” steps).
Evidence (Process Monitor capture, 3-minute window, idle-ish session)
[16:57:49.231] wsl.exe PID=6380 PPID=2536 Cmd=C:\WINDOWS\system32\wsl.exe --update --confirm --prompt-before-exit
Parent PID 2536 already exited (too fast to capture)
[16:58:40.748] wsl.exe PID=24264 PPID=24844 Cmd=wsl.exe --list --running --quiet
Parent: PID=24844 Name=Cursor.exe Cmd=“C:\Users<user>\AppData\Local\Programs\cursor\Cursor.exe”
Grandparent: PID=18100 Name=explorer.exe Cmd=C:\WINDOWS\Explorer.EXE
[16:59:01.640] wsl.exe PID=32772 PPID=24844 Cmd=wsl.exe --list --running --quiet
Parent: PID=24844 Name=Cursor.exe (same Cursor.exe process as above)
[17:00:39.092] wsl.exe PID=30584 PPID=24844 Cmd=wsl.exe --list --running --quiet
Parent: PID=24844 Name=Cursor.exe (same Cursor.exe process as above)
Captured via a PowerShell WMI poll (Get-CimInstance Win32_Process every 150ms) watching for wsl.exe spawns and recording the immediate parent/grandparent chain.
Steps already taken to rule out other causes
Confirmed the bundled anysphere.remote-wsl extension was installed and activating unconditionally on every startup (onStartupFinished in exthost.log).
Uninstalled anysphere.remote-wsl entirely — confirmed removed from extensions.json and no longer appears in exthost logs.
Re-captured the process tree after uninstalling — wsl.exe --list --running --quiet still spawns directly from Cursor.exe, with no extension host or extension process anywhere in the parent chain.
Confirmed remaining bundled extensions (anysphere.remote-ssh, anysphere.remote-containers) are not activating in this workspace (no .devcontainer/, not present in current session’s exthost.log) and contain no WSL-related activation logic that would explain this.
Confirmed terminal.integrated.useWslProfiles: false is set and does not suppress the behavior — this setting appears to only affect the terminal-profile picker, not this internal probe.
Steps to Reproduce
On a Windows 11 machine, confirm WSL is not installed:
wsl --status
→ “The Windows Subsystem for Linux is not installed”
Install Cursor 3.19.x (fresh or existing install) with default settings.
In Cursor’s settings.json, confirm (or explicitly set):
“terminal.integrated.useWslProfiles”: false,
“terminal.integrated.defaultProfile.windows”: “PowerShell”
(Optional — shown not to matter) Uninstall the bundled anysphere.remote-wsl extension entirely and restart Cursor.
Open any workspace and leave Cursor idle, or use Agent Mode to run a few shell commands (triggering “Waited for shell” / “Read terminal”).
Watch the Windows process list (Task Manager → Details, or Get-CimInstance Win32_Process | Where Name -match ‘wsl’) for 2–3 minutes.
Observed (Actual) Result
Cursor.exe itself spawns wsl.exe --list --running --quiet as a direct child process every ~20–40 seconds, with no extension in the parent chain (confirmed via captured process tree: Cursor.exe → wsl.exe).
Because WSL isn’t installed, this probe triggers Windows’ WSL bootstrap path, which shortly after spawns wsl.exe --update --confirm --prompt-before-exit and surfaces a visible “Install/Update WSL” popup.
This recurs indefinitely on an interval, and is not stopped by useWslProfiles: false, uninstalling remote-wsl, or restarting Cursor.
Expected Behavior
Expected Result
On a machine where WSL is not installed, Cursor should not shell out to wsl.exe at all (or should do so at most once, caching a negative result) — it should check WSL’s installation state (e.g., presence of the Microsoft-Windows-Subsystem-Linux optional feature, or %SystemRoot%\System32\lxss) before invoking wsl.exe --list …
Setting terminal.integrated.useWslProfiles: false should fully suppress any WSL-related shell probing, not just hide WSL entries from the terminal profile picker.
No wsl.exe process, and no “Install/Update WSL” popup, should ever appear on a machine with WSL absent and this setting disabled.
Operating System
Windows 10/11
Version Information
Environment
Cursor version: 3.19.13 (also reported on 3.19.7)
OS: Windows 11 (build 10.0.26200)
WSL status: not installed (wsl --status → “The Windows Subsystem for Linux is not installed”)
Relevant settings (already set, no effect):
terminal.integrated.useWslProfiles: false
terminal.integrated.defaultProfile.windows: “PowerShell”
For AI issues: which model did you use?
Sonnet 5
For AI issues: add Request ID with privacy disabled
Please gate this WSL-presence poll behind an actual “is WSL installed” check (e.g., check for %SystemRoot%\System32\lxss or the Microsoft-Windows-Subsystem-Linux optional feature state) before shelling out to wsl.exe, and/or fully respect terminal.integrated.useWslProfiles: false to skip it entirely.
Does this stop you from using Cursor
No - Cursor works, but with this issue