After deleting ~/.cursor/projects/xxxxx and restarting cursor, the problem disappears
This is still happening for me at least once a day. Restarting Cursor and my WSL terminal is my current workaround.
Hi,
I’m a new Cursor user and wanted to share my experience in case it helps others hitting “Execution backend unavailable” — agents could not read files, run shell commands, or use any tools. Every tool call returned that error.
Despite this rough start, I’m still very satisfied with Cursor overall. This bug cost me a bit of research time, but once I got things working again, Cursor actually helped me understand what had happened and draft this report. So: frustrating regression, but the product (and the community thread here) still left me with a positive impression.
Environment
- OS: Windows 11 (
Windows_NT x64 10.0.26200) - WSL: Linux backend (project opened in WSL)
- Broken version: Cursor 3.7.42 (Stable)
- Working version: Cursor 3.5.38 (Stable, system setup)
- VS Code base: 1.105.1
- Commit:
009bb5a3600dd98fe1c1f25798f767f686e14750 - Date: 2026-05-26
- Electron: 39.8.1 / Chromium: 142.0.7444.265 / Node: 22.22.1
Symptoms
- Agent tools completely unavailable:
Read,Shell,Grep, etc. all failed with “Execution backend unavailable” - Same behavior as described in this thread and in the manual-mode workaround
What did not fix it
- Reloading / restarting Cursor
wsl --shutdownand reconnecting to the WSL workspace
The issue persisted across restarts, so it looked like a regression in the newer build rather than a transient WSL connection glitch.
What did fix it
Downgrading from 3.7.42 to 3.5.38 restored full tool execution immediately. (Thanks @Aiko_sato )
To avoid being auto-upgraded back to the broken version, I disabled updates in settings.json:
{
"update.enableWindowsBackgroundUpdates": false,
"update.mode": "none"
}
After downgrade + these settings, agents can read files and run commands in WSL again without issue.
Repro checklist for the Cursor team
If useful for debugging, here’s a minimal repro path:
- Platform: Windows 11 + WSL2 (workspace opened from Linux path, e.g.
/home/<user>/<project>) - Install: Cursor 3.7.42 (Stable, system setup)
- Open any project folder inside WSL
- Start an Agent chat and ask it to run any tool (e.g. read a file, run
pwd, orls) - Expected: tool executes and returns output
- Actual: every tool fails with
Execution backend unavailable - Retry after Cursor reload → still broken
- Retry after
wsl --shutdown, reopen Cursor, reconnect to WSL workspace → still broken - Downgrade to Cursor 3.5.38 (same project, same WSL setup)
- Retry the same agent tool request → works
- Optional: set
"update.mode": "none"and"update.enableWindowsBackgroundUpdates": falseto stay on 3.5.38 until a fix ships
Request to the Cursor team
This looks like a regression between 3.5.38 and 3.7.42 on Windows + WSL. An official fix would be very welcome so new users don’t have to hunt for workarounds or pin an older release.
Happy to provide logs, screenshots, or run extra repro steps if needed.
I found a workaround by connecting to WSL through SSH
This is even happening when I am just on Windows 11 and not using WSL2.
So far it has cost me 2 days worth of $$ because I have a system built around cusor to do much of my work
This is the case for me as well. It works after restarting Cursor AI
Again, for 2 days the backend is unavaible, I mean really ?
same problem.
Updating to Cursor 3.5.38 didn’t fix it.
Strangely, ToolCall works in the Agent Window, but fails in the Editor Window.
Since I’m not used to the Agent Window, I’m working in both the Editor Window and Agent Window, which is very inconvenient.
Still happening in the latest. Reverted to 3.5.* as suggested and things are working again. Cursor · Download
Still happening randomly. What fixed it for me, at least for now, is killing the cursor app from wsl directly with pkill -f cursor, then opening it from wsl with cursor .
I’m having this issue as well. Cursor version below. Windows 11 and WSL2 with Ubuntu.
What’s notable is that I am only having the issue in one workspace. A neighboring workspace works just fine. By “neighboring” I mean:
- ~/dev/A
- ~/dev/B
And folder B has this issue but A doesn’t.
I think folder B may have been initially created in Windows (by another dev).
Yeah I’m having the same problem right now -_- on 3.9.16
Can you do something with that?
Same issue here since this morning. Cursor is completely unusable. Extremely frustrating. Lost 1 full day of work 
I’ll create a detailed report that will hopefully be useful to you guys to tackle this very nasty issue that makes Cursor completely uselss…
and I am also asking cursor-agent for a report. will revert as soon as I have it
If it helps:
Report from Cursor itself:
Persistent "Execution backend unavailable" on Win11 + WSL2 after full reboot
Cursor Agent chat works but ALL workspace tools fail with "Execution backend unavailable"
(Read, Grep, Glob, Shell, MCP, file edits). WebSearch/WebFetch still work.
Environment: Windows 11, WSL2 (kernel 5.15.167.4-microsoft-standard-WSL2), bash,
multi-root workspace (~16 repos). Persists after full PC restart + Cursor restart.
Errors:
Shell: "Command failed to spawn: Execution backend unavailable"
Read/Glob/Grep: "Execution backend unavailable"
MCP: "extension host may have disconnected or stopped responding"
Already tried: full reboot, Cursor restart, multiple retries over several minutes.
Please advise on known incidents, which logs to capture, and whether multi-root WSL
workspaces are a known trigger. Related forum threads: 162239, 164004, 162994, 164106.
My system:
Version: 3.9.16 (user setup)
VS Code Extension API: 1.105.1
Commit: 042b3c1a4c53f2c3808067f519fbfc67b72cad80
Date: 2026-06-27T06:41:01.941Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Windows_NT x64 10.0.26200
@kevinn here is a full report generated by cursor-agent on the “execution backend unavailable” issue of Cursor desktop. Hopefully it will help you address that issue faster.
CURSOR-WSL-EXECUTION-BACKEND-REPORT.txt (16.3 KB)
PS: you shoud enable *.md file upload on the forum, I had to rename it .txt instead of .md to be able to upload it.
PS2:
tried re-installing cursor-server (by removing ~/.cursor-server) but…
…still not working. Looking forward to a solution, it seems that there is nothing I can do locally to get Cursor back to a working state 
PS3:
the request ID of the above chat 
is f93bea3d-cfd1-4745-8577-cfe468d7e7fd
PS4: The ONLY workaround that works is to connect using SSH:
Version 3.10.20 and version 3.10.11 work fine. All the earlier versions until 3.5.38 have some issue with WSL.
Confirmed! The issue has been solved for me as well.