WSL workspace context lost when switching to Agents Window (still present in 3.1)

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

When I have Cursor open in a WSL project (connected via the WSL extension), clicking “Switch to Agents Window” opens the Agents Window rooted at my Windows home directory (C:\Users<username>) instead of the WSL project workspace.

The agent then has no access to the project files, cannot run WSL commands (all wsl invocations return empty output).

Steps to Reproduce

Open Cursor connected to a WSL project

Confirm the editor window is correctly rooted in the WSL workspace

Click “Switch to Agents Window”

Observe: the Agents Window workspace root is C:\Users<username> — the WSL context is lost entirely

Expected Behavior

The Agents Window should inherit the WSL workspace root (e.g. \wsl.localhost//home//project) so the agent can access project files, run commands in the correct shell, and respect .cursor/rules from the project.

Actual behavior

Workspace root silently changes to the Windows home directory

Agent shell runs PowerShell on Windows instead of the WSL shell

WSL commands return empty output

No indication to the user that the workspace context was dropped

Operating System

Windows 10/11

Version Information

OS: Windows 11 (build 26200)

WSL details=== Default Distro OS Info ===PRETTY_NAME=“Ubuntu 22.04.5 LTS”VERSION=“22.04.5 LTS (Jammy Jellyfish)”

=== Kernel ===PS C:\Users\horvrud> wsl – bash -c “uname -a”Linux *** 6.6.87.2-microsoft-standard-WSL2 #1 SMP PREEMPT_DYNAMIC Thu Jun 5 18:30:46 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux

=== WSL Version ===WSL version: 2.6.3.0Kernel version: 6.6.87.2-1WSLg version: 1.0.71MSRDC version: 1.2.6353Direct3D version: 1.611.1-81528511DXCore version: 10.0.26100.1-240331-1435.ge-releaseWindows version: 10.0.26200.8037

Cursor details:Version: 3.1.10 (user setup)VSCode Version: 1.105.1Commit: dacbe9b31599a253763e4910eb6ab38704653320Date: 2026-04-13T11:39:16.806ZLayout: editorBuild Type: StableRelease Track: DefaultElectron: 39.8.1Chromium: 142.0.7444.265Node.js: 22.22.1V8: 14.2.231.22-electron.0OS: Windows_NT x64 10.0.26200

Additional Information

Seemingly relevant thread, but closed: Unable to access WSL paths in the new agent window - #8 by Chris_Combe

Does this stop you from using Cursor

No - Cursor works, but with this issue

6

When I disabled the sandbox mode and selected “Run Everything (Unsandboxed)”, I think for a moment my WSL workspace appeared, but then I clicked away and now can not make it back.
Strange, but may be useful insight…

This way I was able to enable the agent to use wsl (called from powershell I guess) and read files within WSL, but I expect this to be very fragile instead of a direct access.

8

Hi @Rudolf_Horvath

This was a known limitation – the Agents Window (Glass) didn’t carry over the WSL workspace context when you switched from the Editor Window. The good news is that WSL support in the Agents Window has been implemented and should now be available on your version (3.1.10). Another user in this related thread confirmed it’s working on the same version.

Could you try fully quitting Cursor (not just closing the window) and relaunching it? Then open your WSL project in the Editor Window and switch to the Agents Window again. If it still defaults to the Windows home directory after a fresh start, let me know and we’ll dig in further.

9

I did a full laptop restart and it still fails to use the WSL context when switching.
You can see the original WSL based window at the frame edge behind the new window.

image
image1300×842 42.4 KB

10

Thanks for testing with a full restart. Looking at your screenshot, the workspace picker doesn’t show a “Connect WSL” option, which tells me your version (3.1.10) may be missing the final pieces of the WSL support rollout — those improvements were shipping right around when your build was created.

Could you update to the latest version? Go to Help > Check for Updates (or download from cursor.com). Another user in this thread confirmed WSL working in the Agents Window on 3.1.15, including a “Connect WSL” option in the workspace picker.

After updating, try opening your WSL workspace directly from the Agents Window workspace picker rather than using “Switch to Agents Window” from the Editor. Let me know if that resolves it or if it still defaults to your Windows home directory.

11

Updated, restarted, the same:

image
image1373×793 80.1 KB

Maybe some other WSL specific problems limited to my setup cause this, as I stated my former issue is still not resolved: WSL startup requires reinstall of cursor server - Support / Bug Reports - Cursor - Community Forum

This is what welcomes me on each start:

image
image822×788 36.5 KB

I click cancel, “reinstall server” and then I have a working setup.
The user home is bind mounted during startup, which is a non-standard wsl setup, which may cause this. However I make sure it is in place when I start Cursor, so maybe some trickery in the cursor setup does not follow bind mounting :person_shrugging:

12

Thanks for updating and testing again, Rudolf.

The fact that “Connect WSL” still doesn’t appear in the workspace picker on 3.1.17 is unexpected. Other users confirmed it working on 3.1.15, so something specific to your environment is preventing it from being detected.

I think this is connected to the WSL server reinstall issue you mentioned. The Agents Window checks whether WSL is available on your system before showing the “Connect WSL” option. If your WSL environment isn’t responding as expected due to the bind-mounted home directory setup, that check may be silently failing.

Could you try these two things to help us narrow it down?

  1. Open PowerShell on your Windows host and run wsl --status. Does it complete successfully, or does it error out? This is the same check Cursor runs internally to decide whether to show the WSL option.

  2. In the Agents Window, try Open Folder and manually navigate to your WSL path (e.g., \\wsl.localhost\<your-distro>\home\<user>\project). This bypasses the detection step and might let you connect directly.

The bind-mounted home directory is likely the common factor between the server reinstall issue and the missing WSL option in the Agents Window. Understanding exactly where the detection fails will help us figure out next steps.

13

The wsl --status returns flawlessly:

image
image482×144 4.3 KB

I am able to open the windows mounted WSL path, but that is very suboptimal, as is far slower for file operations, and the agent would require to prefix all WSL command with wsl -e “command”, this is very suboptimal from an “agent experience”.

14

Now it works, we can close the thread.