Retrying the same tool calls repeatedly over ~50+ minutes
Window reload / restart suggested but issue recurs
Request:
Please advise whether there is a known incident with the agent execution backend (file I/O + command spawning service), and whether WSL2 is a contributing factor.
Steps to Reproduce
Behavior:
The failures are intermittent and fluctuating. Over the course of one session, tools would fail for several minutes, briefly recover (e.g. Read succeeded once or twice), then fail again.
At one point the subsystems failed independently: Read worked while Shell (Command failed to spawn) still failed — suggesting separate execution subsystems are degrading separately, not a single global outage.
No code change or workspace action on my side triggers it; success/failure seems tied purely to backend availability.
Errors persist across retries spaced minutes apart.
Expected Behavior
Impact:
Cannot reliably read files, search the codebase, or run shell commands, which blocks the agent from completing tasks.
Read-only sandbox — fails in Agent mode too; logs show sandbox preflight succeeded
Corrupt local install — server logs are clean: cursor-agent-exec activated, ripgrep valid, zsh detected. Only error is an unrelated 3rd-party extension (bung87.rails: missing module compact-prefix-tree/cjs)
Where I think we are:
The string “Execution backend unavailable” never appears in the WSL server logs, and the local server looks healthy. The failure is on every tool path that needs to spawn a process or write (Shell, Glob, edits), while index-served Reads work. → Strong evidence this is upstream in Cursor’s agent execution service, not the local WSL server. Survives reboot/reinstall-of-state, affects only this account, nothing on status page.
=> anyone else seeing “Execution backend unavailable” for spawn/write tool calls while the WSL remote server logs are clean? Is this a known agent-service-side issue?
Hi @Clem_B Thanks for the forum post and I apologize for the instability you are facing. This is a known class of issue regarding Windows + WSL2. the agent’s tools (Read, Grep, Glob, Shell) all run through the WSL2 extension host, so when that host crashes or briefly stops responding, they all report “Execution backend unavailable” until it reconnects. That’s why it flickers in and out, and why one tool can work while another fails. Native Windows workspaces aren’t affected.
Steps that usually recover it, in order:
Fully quit and reopen Cursor
Make sure Cursor is fully updated.
Run wsl --shutdown in PowerShell, then reopen from the WSL shell with cursor ..
If it persists, delete ~/.cursor-server inside WSL and reopen (Cursor reinstalls it).
If you open your project as a multi-root .code-workspace, try a single folder instead, as that’s a separate WSL issue we’re tracking.
Thanks @kevinn , really appreciate the quick response. I’ve now worked through your whole list and unfortunately it still isn’t recovering, so I think this might be more than the usual flicker.
What I’ve done from your steps:
I fully quit and reopened Cursor (not just a reload)
confirmed I’m on the latest version with client and server on the same commit
ran wsl --shutdown in PowerShell and reopened with cursor .
and finally deleted ~/.cursor-server for a clean reinstall.
I’m also opening the project as a single folder, not a multi-root .code-workspace
After all of that, a fresh chat still fails the same way.
One thing that might help you narrow it down: the failure looks workspace-specific.
=> echo ok runs perfectly in an empty WSL folder, but fails inside my project.
That led me to find an 11 GB database dump sitting at the root of the repo, which had bloated the workspace to 12 GB. I moved it out, which brought the workspace down to 586 MB, and added a .cursorignore for node_modules, tmp, log, and *.dump. That was clearly worth fixing — but it didn’t resolve the spawn failures. Even on the slimmed-down 586 MB workspace, with a full wsl --shutdown and a clean server reinstall, the extension host still wedges.
So an empty folder works, but this 586 MB project consistently breaks the host’s ability to spawn processes or write files (reads from the index still work). Given that, is there a specific log I can capture at the exact moment a tool call fails to show why the host stops responding on this workspace? I’m thinking the Extension Host output channel, but if there’s a more useful log or a verbose/trace flag you’d like me to enable, I’m happy to turn it on and share everything.
I’m still debugging
for each test below, I open the workspace/folder fresh and ask a new chat to run echo ok — that’s my pass/fail check for whether the execution backend is working.
Opened with extensions disabled (cursor --disable-extensions) → still fails (rules out extensions, incl. Git).
Searched for sockets/named pipes in the workspace → none found.
Opened just the app/ subfolder → works.
Counted files per top-level dir → tmp 10,233, node_modules 9,308, .git 3,944, app 741.
Added .vscode/settings.json with files.watcherExclude + search.exclude for the heavy dirs, reopened → still fails.
Full quit + wsl --shutdown + reopen (genuinely fresh host) → still fails.
Opened tmp/, node_modules/, and .git/ individually → all three work.
Net result: only opening the repo root fails; every subfolder works. Not extensions, not the file watcher, not any single heavy dir. Points to a root-level-only config ?
The biggest one: I copied the whole project to a different path and opened that. The copy works flawlessly — the agent runs echo ok, edits files, everything. The original path keeps failing. Identical content; the only difference is the workspace path. So this now looks path-specific, not project-content-specific.
Other things ruled out since then:
Set Run mode to “Run everything (Unsandboxed)” → still fails, so it’s not the sandbox.
Parked node_modules + tmp + .git (repo down to ~2k files) → still fails, so it’s not file count.
Moved .cursor/ aside (rules/skills/MCP) → still fails.
Cleared the Windows-side %APPDATA%\Cursor\User\workspaceStorage folders for this repo — including hash 4d18a2d2…, which is the exact one that showed a vscode.lock contention in my server logs → still fails.
So: same content at a different path works, but the original path can’t spawn a single command — even unsandboxed, even after wiping the WSL server and the Windows workspace storage.
Is there some other per-path state/cache (globalStorage, history, a WSL-side workspace cache) that pins to the original path, or can this be escalated? Happy to send a full diagnostic bundle.
I am experiencing the same issue. I was using Cursor for SDD when the error ‘Command failed to spawn: Execution backend unavailable’ appeared. Now I am completely blocked, and restarting the entire system didn’t fix it.
Similar to the comment above, I am also running WSL2.
This has been happening intermittently since mid-June. I would sometimes be able to resolve it by restarting WSL, or my entire PC.
With the latest update, Cursor is now completely bricked in this setup. Nothing I do fixes it (Grok and Cursor auto would suggest removing some folders, caches, etc.). I tried a clean reinstall – which worked for the remainder of my work day, but then broke again after system restart.
FYI I just fixed the issue by installing System version 3.3 through the downloads page. Same exact setup except version of Cursor and yet everything works fine now Interesting
Working
Opened with extensions disabled (
Searched for sockets/named pipes in the workspace → none found.
Counted files per top-level dir → 
Interesting