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

[Rudolf_Horvath]

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

[Rudolf_Horvath]

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.

[mohitjain (Mohit)]

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.

[Rudolf_Horvath]

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.

[mohitjain (Mohit)]

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.

[Rudolf_Horvath]

Updated, restarted, the same:

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:

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

[mohitjain (Mohit)]

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.

[Rudolf_Horvath]

The wsl --status returns flawlessly:

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”.

[Rudolf_Horvath]

Now it works, we can close the thread.

[Rudolf_Horvath]

I am able now to select WSL based targets, but it still does not work well.

I am able to see former threads/sessions, but any new message just indefinitely hangs. During this I am able to use all sessions within the original editor window.

[mohitjain (Mohit)]

Good news is that the workspace picker is working now (that was the original issue). The hanging on new messages is a separate problem.

To help track this down, create a new thread with the following thread so we can track it seperately:

1. What version are you on now? (Help > About in the Editor Window)

2. Request ID from the hanging message: in the Agents Window, click the three dots at the top of the conversation > Copy Request ID

3. Developer Console errors: while a message is stuck, open Help > Toggle Developer Tools in the Agents Window, check the Console tab for red errors

Also worth trying: update to the latest version if you’re not already on it. There have been several fixes for agent execution stability in the Agents Window since 3.1.x.

[Rudolf_Horvath]

Hi,
The version of Cursor:
Version: 3.3.16 (user setup)
VSCode Version: 1.105.1
Commit: 7f0f522221d0ba220e4edb766bb3c47c08c14ab0
Date: 2026-05-06T20:40:56.501Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200

Request ID:
Request ID: 45d99a6a-b057-4685-9746-b430a27a56ca
{“error”:“ERROR_EXTENSION_HOST_TIMEOUT”,“details”:{“title”:“Agent Execution Timed Out”,“detail”:“The agent execution provider did not respond in time. This may indicate the extension host is not running or is unresponsive.”,“isRetryable”:false,“shouldShowImmediateError”:true,“additionalInfo”:{},“buttons”:[{“label”:“Reload Window”,“reloadWindow”:{}}],“planChoices”:}}
The agent execution provider did not respond in time. This may indicate the extension host is not running or is unresponsive.
Agent Execution Timed Out [deadline_exceeded]
ConnectError: [deadline_exceeded] Agent Execution Timed Out
at oHv (vscode-file://vscode-app/c:/Users/horvrud/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:38624:25077)
at Pmh.waitForProviderRegistration (vscode-file://vscode-app/c:/Users/horvrud/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:38624:29583)
at async jCh._waitForPushRequestContextProviderRegistration (vscode-file://vscode-app/c:/Users/horvrud/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:41628:4049)
at async jCh.streamFromAgentBackend (vscode-file://vscode-app/c:/Users/horvrud/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:41628:7635)
at async jCh.getAgentStreamResponse (vscode-file://vscode-app/c:/Users/horvrud/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:41628:19379)
at async Qbt.submitChatMaybeAbortCurrent (vscode-file://vscode-app/c:/Users/horvrud/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:29342:17002)

I have another issue opened, maybe they are related to each other:

WSL startup still requires "Reinstall Cursor Server" — daily friction for multiple devs

Thanks for the detailed follow-up. The warm-vs-cold WSL comparison is useful, and this does sound distinct from a missing home mount or resource exhaustion issue. Could you share the Remote - WSL output from one failed cold start and one successful warm start? Run wsl --shutdown Start Cursor directly, without opening a WSL shell first When the “Reinstall Cursor Server” prompt appears, open View > Output and select Remote - WSL Copy the output from that failed attempt Repeat after…

I was not able to open Developer tools, I have only these options under help:

[mohitjain (Mohit)]

Thanks for the details. The error confirms the issue — the WSL extension host isn’t starting fast enough for the Agents Window to connect. This is a known issue our team is actively working on (it affects Windows + WSL setups specifically in the Agents Window).

A few things:

Developer Tools: The Agents Window has a simplified Help menu, which is why “Toggle Developer Tools” is missing. Try the keyboard shortcut Ctrl+Shift+I instead — that should open the console even in the Agents Window.

Workaround: Before using the Agents Window, open your WSL workspace in the Editor Window first and confirm the connection is stable (run a quick agent message there). Then switch to the Agents Window. This gives the WSL extension host time to fully start and register before the Agents Window tries to use it.

You’re right that this is likely related to your Reinstall Cursor Server thread. Both stem from WSL connection instability on cold starts. Warming the WSL distro before launching Cursor helps both.

I’ve flagged this with our engineering team. If Ctrl+Shift+I works, any red errors in the Console tab from a failed attempt would be useful to share here.

[Rudolf_Horvath]

With today’s version it worked:

Version: 3.4.20 (user setup)
VSCode Version: 1.105.1
Commit: 0cf8b06883f54e26bb4f0fb8647c9500ccb43310
Date: 2026-05-15T02:26:10.351Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
OS: Windows_NT x64 10.0.26200

Just FYI, I faced problems now on the “local” powershell based agent, which struggled a lot to execute get-date, here is the requestID for that: 910d01ae-0bb4-4862-9bed-c36b6b374ea4
That is not a focus problem for me, so won’t open a new thread for it now.

I am glad to have the WSL integration working now, thank you for your help in it!