Agents Window (still) fails on WSL

Support Bug Reports
, , ,
1

image
image418×146 2.66 KB
3.3.30

It’s so disappointing Windows+WSL is clearly not a priority. I would love to use this new setup.

2

Hi there!

We detected that this may be a bug report, so we’ve moved your post to the Bug Reports category.

To help us investigate and fix this faster, could you edit your original post to include the details from the template below?

Bug Report Template - Click to expand

Where does the bug appear (feature/product)?

  • Cursor IDE
  • Cursor CLI
  • Background Agent (GitHub, Slack, Web, Linear)
  • BugBot
  • Somewhere else…

Describe the Bug
A clear and concise description of what the bug is.

Steps to Reproduce
How can you reproduce this bug? We have a much better chance at fixing issues if we can reproduce them!

  1. …
  2. …
  3. …

Expected Behavior
What is meant to happen here that isn’t working correctly?

Screenshots / Screen Recordings
If applicable, attach images or videos (.jpg, .png, .gif, .mp4, .mov)

Operating System

  • Windows 10/11
  • MacOS
  • Linux

Version Information

  • For Cursor IDE: Menu → About Cursor → Copy
  • For Cursor CLI: Run agent about in your terminal
IDE:
Version: 2.xx.x
VSCode Version: 1.105.1
Commit: ......

CLI:
CLI Version 2026.01.17-d239e66

For AI issues: which model did you use?
Model name (e.g., Sonnet 4, Tab…)

For AI issues: add Request ID with privacy disabled
Request ID: f9a7046a-279b-47e5-ab48-6e8dc12daba1
For Background Agent issues, also post the ID: bc-…

Additional Information
Add any other context about the problem here.

Does this stop you from using Cursor?

  • Yes - Cursor is unusable
  • Sometimes - I can sometimes use Cursor
  • No - Cursor works, but with this issue

The more details you provide, the easier it is for us to reproduce and fix the issue. Thanks!

7

Hey, I saw the screenshot. You’re getting wsl.exe terminated with exit code: 1 when you open the Agents Window on a WSL workspace.

This is a known gap in Cursor 3’s WSL support for the Agents Window. The root workspace doesn’t pick up anysphere.remote-wsl, so it breaks. The issue is tracked, but there’s no exact ETA for a fix yet.

Related threads with the same symptom:

Until there’s a fix, the workaround is to open the WSL project directly via Remote-WSL, not through the Agents Window. That works as expected.

9

Thanks @deanrie

Although, I’m unsure if I understand the workaround “open the WSL project directly via Remote-WSL”

Within the Agents WIndow? It loads ALL my projects (as expected) and just shouts at me the exit code 1 error repeatedly.

The regular edit window works fine FYI.

10

Hey, just to clarify. The workaround right now is basically to not open WSL projects in the Agents Window until it’s fixed, and instead use them the old way via the regular Cursor edit window with Remote-WSL connected, which is the regular edit window that works for you.

So at the moment, the Agents Window isn’t really usable for WSL workspaces because of this buggy allowlist issue in the root workspace. Sorry for the hassle. The temporary solution is to not use the Agents Window for WSL, which I know is exactly why you reached out. We don’t have an ETA for a fix yet, but if anything changes, we’ll update the thread.

11

having the same issue. Interestingly Composer 2.5 works in Agents Window in WSL, but when external models such as Opus is used it gets stuck.

12

I was having problems with the editor window as well in a workspace. I had to open the directory up in WSL bash again with cursor . as I realized the problem was with the existing workspace. I was able to use agents in the home directory in the editor window with cursor ~. The home directory agent window is also able to have the agents use the terminal. But I can’t do the same even with my reopened workspace.

I can’t seem to get the agents to do anything in WSL, editor or agent window. In my current work session. I was previously able to use both.

In the agent window:

I was getting the WSL extension popups in the agent window as usual. Deleting ~/.cursor-server and using cursor . at home worked to fix the connection.

terminal.external.linuxExecI set this from xterm to bash. Now I can launch a terminal in the agent window.

13

@Bakhtiyor_Akhatov, this is the same known WSL bug in Agents Window. The root workspace doesn’t pick up anysphere.remote-wsl, so anything that doesn’t go through the local model fails when it tries to load the WSL extension. We’re tracking the issue, but I can’t share an ETA for a fix yet.

@poroburu thanks for writing out the steps, it’s a helpful workaround. For anyone finding this thread later, quick summary:

  • Delete ~/.cursor-server and reopen the project via cursor . from your WSL home
  • If the terminal in Agents Window won’t start, change terminal.external.linuxExec from xterm to bash

If that doesn’t help, the fallback is still the same: open WSL projects via a normal window with Remote-WSL, not via Agents Window.

I’ll post here once there’s an update on the fix.

15

Another strange behaviour I noticed is that I still get problems having agents running WSL commands in editor window. For example, asking to run pwd. On a laptop that did not update Cursor, the WSL remote element in the bottom left has ubuntu lowercased.

image

But on an updated Cursor, this would not run the same WSL commands. I need to delete the ~/cursor-server/ and specifically reopen the directory with ~/workspace/cursor/…/<directory>. And then it works, but that same element says WSL: Ubuntu with an uppercase.