WSL Agent execution backend breaks when remoteAuthority casing differs (`wsl+Ubuntu` vs `wsl+ubuntu`)

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

The main bug appears to be a remoteAuthority casing mismatch for WSL workspaces. The same WSL workspace had a bad window/session where logs used one casing, wsl+Ubuntu, while the workspace metadata / recovered session used another, wsl+ubuntu. In the bad window, Cursor Agent chat still worked and agent-exec provider registration completed, but every tool call that needed the execution backend failed with “execution backend unavailable” after a session-acquisition timeout.

This looked like the controlled execution route was registered under one remoteAuthority string but tool execution was being routed or looked up under the other. The result was a permanently broken Agent execution backend for that window, even though the WSL extension host was running. The exact same workspace recovered only after opening it in a brand-new Cursor window, which established the lowercase wsl+ubuntu route and tools started working again.

Steps to Reproduce

I do not have a clean way to force Cursor into the mismatched state, but this is the observed reproduction/recovery pattern:

  1. Open a WSL2 workspace in Cursor.
  2. Start a new Agent.
  3. Ask it to run a minimal Shell tool call such as date.
  4. The Agent emits the Shell tool call, but it hangs for about 70 seconds and then reports execution backend unavailable / session acquisition timed out.
  5. Logs from the bad window show the workspace/session using wsl+Ubuntu casing.
  6. The workspace metadata and the later working window use wsl+ubuntu casing.

Recovery that fixed the same workspace without deleting its project history/canvas:

  1. In the failing workspace window, choose File → Close Window.
  2. From another working Cursor window, press Ctrl+Shift+N to open a new window.
  3. In that new window, press Ctrl+Shift+R and reopen the same WSL folder from Recents.
  4. Start a new Agent and run date.
  5. The Shell tool works. Logs now show normal execution-provider activity for the same workspace.

Expected Behavior

Cursor should treat WSL remoteAuthority values case-insensitively or canonicalize them before registering/looking up the agent execution provider. A workspace opened as wsl+Ubuntu and wsl+ubuntu should not create separate or incompatible execution routes. If a route is stale or bound to the wrong remoteAuthority casing, Cursor should invalidate/rebind it instead of leaving Agents in a state where chat works but all tools time out.

Operating System

Windows 10/11

Version Information

Cursor IDE stable. Logs show client_version=3.9.8 and VSCode Version=1.105.1. Cursor server commit in WSL: 4aa8ff1b7877ed7bd01bcba308698f71a6735380. Environment: Windows + WSL2 Ubuntu, Linux 6.6.114.1-microsoft-standard-WSL2.

For AI issues: which model did you use?

GPT-5.5 in Agent mode

For AI issues: add Request ID with privacy disabled

Failed request ID: 03e6e259-a88d-4c3f-8376-a97e2bbc141d

Additional Information

Key evidence, sanitized:

  • The same WSL workspace failed in one Cursor window and worked in a newly opened window.
  • The workspace ID / project artifacts were not permanently corrupted: preserving the workspace and reopening it through a fresh window fixed tool execution.
  • Resetting workspace storage and reinstalling the Cursor server did not fix the bad window/session route.
  • In failing traces, agentExec.waitForProviderRegistration completed quickly, but StreamExecutorResource.execute ran for about 70000ms and renderer logs showed repeated [agent-exec] Session acquisition timed out.
  • The WSL extension host logs for the failed tool call did not show the expected Shell stream / permission evaluation entries.
  • In the recovered window, the same command produced normal WSL extension host logs, including Shell stream: approval gate reached and shell permission evaluation.
  • The suspicious difference was remoteAuthority casing: failing route used wsl+Ubuntu while the working route used wsl+ubuntu. This strongly suggests execution provider registration / lookup is keyed by a non-canonical remoteAuthority string.

Related reports I found before filing:

I can share raw Main/Window/Extension Host logs privately with Cursor staff. I am not attaching them publicly because they include local paths and workspace metadata.

Does this stop you from using Cursor

Sometimes - I can sometimes use Cursor

6

Hey @sbdd!

Thanks for sharing this. This seems like a fairly credible report (and great job investigating). If this is the root cause, the timing also lines up with when we saw an uptick of execution backend issues. I’ve shared it with the team!

9

Thanks again for the report! We’ve merged a fix that should come out in the next minor release.