Agent tools fail on WSL workspace opened via \\wsl.localhost\ — path resolves to C:\home\..., Glob times out, Shell intermittent (Cursor 3.9.16)

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Environment

  • Cursor version: 3.9.16 (042b3c1a4c53f2c3808067f519fbfc67b72cad80, x64)
  • OS: Windows 11 (build 26200) + WSL2 Ubuntu-24.04
  • Project path (as opened in Cursor): \wsl.localhost\Ubuntu-24.04\home\cyril\dev\portif
  • Launch method: Opening WSL repo from Ubuntu (cursor .) — issue persists in latest Cursor
  • Repo is valid in WSL: /home/cyril/dev/portif exists, README.md readable via wsl CLI

Summary

After upgrading to Cursor 3.x, the AI agent cannot reliably read/search/execute in my WSL Ubuntu repo. Some file tools work via UNC path, but others resolve Linux paths to invalid Windows paths (C:\home\cyril\...), Glob searches time out, and Shell commands return empty/no response. This makes the agent effectively unable to work on WSL projects.

Steps to reproduce

  1. On Windows 11, use WSL2 with Ubuntu-24.04
  2. Open project at \\wsl.localhost\Ubuntu-24.04\home\cyril\dev\portif (or reopen from recent projects)
  3. Start an Agent chat and ask it to explore the repo (list files, read Makefile, run shell commands)
  4. Observe inconsistent/broken tool behavior

Expected behavior

  • All agent tools (Read, Grep, Glob, Shell) operate on the WSL filesystem
  • Linux paths like /home/cyril/dev/portif resolve correctly inside WSL
  • Status bar shows WSL: Ubuntu-24.04 when in remote-WSL mode
  • Agent can index and read .cursor/rules, source files, etc.

Actual behavior (observed in a live agent session)

Tool Result
Read via \\wsl.localhost\...\README.md Works
Grep in workspace Works
Glob on /home/cyril/dev/portif Fails — resolves to C:\home\cyril\dev\portif (does not exist)
Glob * via UNC path Times out after 25s
Shell with working_directory: /home/cyril/dev/portif Intermittent — often empty output / no exit status
Shell via wsl -d Ubuntu-24.04 -e bash -c "..." Works when it runs

Suspected root cause

Workspace registered as file://wsl.localhost/... (UNC) instead of proper remote URI vscode-remote://wsl+ubuntu/.... This matches known WSL issues in Cursor 3.x / Agents Window where:

  • Duplicate workspace storage entries conflict
  • ms-vscode-remote.remote-wsl conflicts with anysphere.remote-wsl
  • Extension host fails to start within 60s → “Agent Execution Timed Out”

Workarounds attempted / recommended

  • Open via cd ~/dev/portif && cursor . from WSL terminal
  • Confirm bottom-left shows WSL: Ubuntu-24.04
  • Uninstall ms-vscode-remote.remote-wsl, keep only anysphere.remote-wsl
  • wsl --shutdown, delete ~/.cursor-server, clean stale workspaceStorage entries with file://wsl.localhost/...
  • Use Editor Window (cursor --classic) instead of Agents Window

Impact

Severe — WSL-based development is my primary workflow. Agent is unusable for repo exploration, testing, and multi-file edits. Considering canceling subscription if unresolved.

Request ID

[Please paste from this chat: “…” menu → Copy Request ID]

Logs

[Please attach via Help → Developer: Export Logs → Main, Window, Extension Host]

Steps to Reproduce

dd

Expected Behavior

dd

Operating System

Windows 10/11

Version Information

ddddddddddd

Does this stop you from using Cursor

Yes - Cursor is unusable

5

Hey, thanks for the detailed report. Your diagnosis is basically correct. Linux paths resolving to C:\home\cyril\... and Glob timing out is a classic sign that the project is opened as a local Windows workspace on top of \\wsl.localhost\ (9P network share), not as a real Remote WSL session. In that state, the agent tools run on the Windows host, not inside WSL, which is why everything looks inconsistent.

The key is to make sure the window is actually remote. Check the bottom-left status bar. It should say WSL: Ubuntu-24.04. If it doesn’t, you’re in a UNC workspace and you’ll need to fix it:

  • Open the project only from a WSL terminal: cd ~/dev/portif && cursor .
    Don’t open it via \\wsl.localhost\Ubuntu-24.04\... from Explorer or from Recents. That creates a local Windows workspace.
  • Remove old Recents entries like file://wsl.localhost/.... They reopen in the same broken state.
  • Keep only anysphere.remote-wsl. Uninstall or disable ms-vscode-remote.remote-wsl (it doesn’t work in Cursor anyway). If the Extensions UI is stuck in a remote window, uninstall via CLI: cursor --uninstall-extension ms-vscode-remote.remote-wsl.
  • If the server is stuck, run wsl --shutdown, then reopen.
  • If Remote won’t install via the Agents Window, use the classic Editor Window for WSL work for now.

Can you confirm what the status bar shows when the issue reproduces? That will immediately tell us if the window is truly remote. This is a known class of WSL issues in Cursor 3. It’s being tracked, but I can’t give an exact ETA for a fix. For now, the best workaround is using a proper Remote WSL connect as described above. Let me know how it goes.

6

The status bar showed Ubuntu.
In between, the forum showed me some connected bugs so I tried to shutdown wsl and delete the cursor server directory. The final solution after all that was to run cursor --classic from WSL.
So it seems to work again. Thanks.