Cursor 2.4.27 – WSL stops working after Python provider "fix"

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

After updating Cursor to 2.4.27, I reloaded the app and got a prompt to fix a Python provider conflict (Pylance). After clicking “Uninstall & Restart”, Cursor restarted and since then WSL no longer works - all attempts to attach to WSL fail or freeze. The issue started immediately after the Python provider fix in 2.4.27.

Steps to Reproduce

  • Update Cursor to version 2.4.27
  • Reload Cursor after the update
  • Get a prompt about a Python provider conflict (Pylance)
  • Click “Uninstall & Restart”
  • Cursor restarts
  • From this point on, opening or attaching to a WSL project causes Cursor to freeze or - fail to connect to the remote extension host
  • Restarting Windows and WSL does not resolve the issue

Expected Behavior

Cursor restarts and then consistently fails to attach to WSL. Opening a WSL project causes Cursor to freeze or become unresponsive.

Operating System

Windows 10/11

Version Information

Version: 2.4.27 (user setup)
VSCode Version: 1.105.1
Commit: 4f2b772756b8f609e1354b3063de282ccbe7a690
Date: 2026-01-31T21:24:58.143Z
Build Type: Stable
Release Track: Default
Electron: 39.2.7
Chromium: 142.0.7444.235
Node.js: 22.21.1
V8: 14.2.231.21-electron.0
OS: Windows_NT x64 10.0.19045

Additional Information

This is really annoying to not being able to trust cursor’s suggestions. I was naive enough to let it do what it wanted.

Does this stop you from using Cursor

Yes - Cursor is unusable

Hey, thanks for the report.

To figure out what exactly is breaking, can you collect the WSL logs?

  1. Try connecting to WSL (let it hang)
  2. Ctrl+Shift+P → “Remote: Show Logs”
  3. Paste the contents here (or if it’s a lot, use pastebin or a gist)

Also, as a workaround, try this:

  • Delete the ~/.cursor-server folder inside WSL (rm -rf ~/.cursor-server)
  • Restart Cursor and try connecting again

Let me know how it goes.

Thanks for the reply. In the meantime, I investigated the issue further and found that only one specific WSL project has problems loading. It eventually loads after about 10 minutes, but once it does, Cursor behaves as if the project contains two Git repositories. The Source Control view shows everything duplicated.

All checks confirm that there is only one Git repository in the project (only a single .git directory).

I also ran: du -sh * | sort -h
and got:
4.0K README.md
24K contracts
28K research
88K docs
7.4G core

The core directory is very large and contains two Python virtual environments (both included in .gitignore). My suspicion is that Cursor freezes while scanning this directory and only recovers after several minutes, leaving the workspace in a broken state with duplicated Git providers.

Is there a known way to fix or reset the duplicated Git repositories in Source Control without resetting the entire workspace?

Update / My Solution:
I checked the settings in Cursor and found that git.autoRepositoryDetection was set to openEditors.
After changing it to false and reloading the window, everything went back to normal:

  • only one Git repo appears in Source Control
  • WSL loads quickly again

I also closed Cursor completely and reopened it - the issue did not return.

It seems that Cursor’s auto repository detection was, at some point, misdetecting my single repository as two, which caused both the duplicate Git entries and the slow WSL startup.

1 Like