[URGENT] Severe I/O Bottleneck in WSL2: `anysphere.remote-wsl` executes Windows binaries (`/mnt/c/...`) for native Linux projects causing massive 9P protocol thrashing

Support Bug Reports
, , , ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

There is a severe architectural flaw in how the anysphere.remote-wsl extension handles backend processes compared to the official Microsoft VS Code WSL extension.

Even when a project is strictly located within the native Linux filesystem (/home/user/code/...), Cursor fails to spawn native Linux binaries for its core background services. Instead, it relies on WSL Interop to execute Node, Codex, and File-Service binaries located on the Windows host (/mnt/c/Users/user/AppData/Local/Programs/cursor/...).

This triggers thousands of cross-OS file system calls via the slow 9P network bridge. The immediate result is continuous 100% SSD disk usage on the Windows host, extreme system stuttering, and Windows repeatedly throwing the warning: “E/A-intensive operation like git on Windows drives causes poor performance.”

Steps to Reproduce

  1. Open a purely native Linux project (e.g., ~/code/myproject) in Cursor via the WSL connection.
  2. Ensure the project is isolated from Windows (no symlinks to C:\, global Git configs and NPM caches all set to Linux paths).
  3. Wait for the file-serv (Codebase Indexer) and codex to start running in the background.
  4. Run the following command in the WSL terminal to monitor cross-OS file access:
    lsof 2>/dev/null | grep /mnt/c/

Expected Behavior

Running code . correctly starts a native Linux server (~/.vscode-server). Running lsof 2>/dev/null | grep /mnt/c/ returns empty. The extension operates entirely within the native Linux ext4 filesystem with zero Windows SSD thrashing.

Operating System

Windows 10/11

Version Information

  • OS: Windows 11 with WSL2 (Ubuntu)
  • Hardware: 32GB RAM (SSD usage spiking to 100%)
  • Cursor Version: Latest
  • Extension: @id:anysphere.remote-wsl

Additional Information

Actual Behavior:
Running cursor . (or connecting via the Windows GUI) spawns dozens of Node processes, codex, and file-serv that anchor to the Windows directory.

Here is the exact lsof output proving that Cursor is dragging the Linux workspace across the mnt/c bridge:

lsof 2>/dev/null | grep /mnt/c/

node      282      user     cwd       DIR       0,67       4096 2533274790642370 /mnt/c/Users/user/AppData/Local/Programs/cursor
node      282  319 node     user     cwd       DIR       0,67       4096 2533274790642370 /mnt/c/Users/user/AppData/Local/Programs/cursor
node      496      user     cwd       DIR       0,67       4096 2533274790642370 /mnt/c/Users/user/AppData/Local/Programs/cursor
codex     2505422  user     cwd       DIR       0,67       4096 2533274790642370 /mnt/c/Users/user/AppData/Local/Programs/cursor
codex     2505422 2505441 tokio-run user     cwd       DIR       0,67       4096 2533274790642370 /mnt/c/Users/user/AppData/Local/Programs/cursor
codex     2505422 2505524 sqlx-sqli user     cwd       DIR       0,67       4096 2533274790642370 /mnt/c/Users/user/AppData/Local/Programs/cursor
node      2505195 2505412 file-serv user     cwd       DIR       0,67       4096 2533274790642370 /mnt/c/Users/user/AppData/Local/Programs/cursor
# ... (dozens of similar processes omitted for brevity)

Impact:
This essentially breaks the development experience for WSL users with larger codebases. The constant indexing and AI-context reading across the 9P protocol makes the entire host OS unresponsive.

Request:
Please modify the anysphere.remote-wsl extension to strictly deploy and utilize native Linux binaries (~/.cursor-server/) for node, file-serv, and codex when connected to a WSL instance, matching the architectural standard set by Microsoft’s VS Code extension.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

7

The lsof output makes this clear — node, codex, and file-serv all have their CWD anchored to the Windows Cursor installation path even though your project is on the native Linux filesystem. Our code analysis confirms the propagation mechanism: the extension host is spawned without an explicit CWD override, so whatever directory the remote-wsl extension uses to start cursor-server cascades to every child process. That puts all relative path resolution on the 9P bridge.

We’ve filed this with our client infrastructure team.

There’s no clean workaround for the CWD inheritance, but to reduce the I/O volume while a fix is in progress:

  1. Disable codebase indexing temporarily - Cursor Settings > Features > Codebase Indexing > toggle off. This stops file-serv, which is one of the heaviest cross-filesystem processes. Trade-off: you lose codebase-aware context for AI features.

  2. Add a .cursorindexingignore in your project root listing any large directories you don’t need indexed. Won’t fix the CWD issue but reduces total file operations.

I’ll follow up here when there’s progress.

8

Thanks for the mitigation strategies, I am already doing sth like this. But of course, I am using Cursor to have codebase-aware context - so looking forward to a proper fix!