File-read backend unavailable

[Hezaerd]

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Agents are unable to read files. During thinking, composer 2.5 told me that “Execution backend unavailable.”

Steps to Reproduce

Ask anything to agent that include reading files from codebase.

Screenshots / Screen Recordings

Operating System

Windows 10/11

Version Information

Version: 3.6.33 (system setup)
VS Code Extension API: 1.105.1
Commit: 453f0b5a181a2308f4194369774059e533143520
Date: 2026-06-01T01:43:45.348Z
Layout: editor
Build Type: Stable
Release Track: Nightly
Electron: 39.8.1
Chromium: 142.0.7444.265
Node.js: 22.22.1
V8: 14.2.231.22-electron.0
xterm.js: 6.1.0-beta.220
OS: Windows_NT x64 10.0.26200

For AI issues: which model did you use?

Tested with composer-2.5 and gpt-5.5

Does this stop you from using Cursor

Yes - Cursor is unusable

[Clement_Gonin (Clément Gonin)]

I have the same problem… My agents aren’t able to read files in a project anymore…
It says that the “Execution backend” is unavailable.

I tried to update and upgrade my WSL Linux distro, rebooted several times, I’m out of options…

After investigating by asking the agent what errors it gets, it says that it is related to Cursor servers.
Here’s a part of the answer :

What failed (exact messages)

What you tried	Error (verbatim)
Read file	Execution backend unavailable
Shell / terminal	Command failed to spawn: Execution backend unavailable
Grep / Glob	Execution backend unavailable

So this is a Cursor agent infrastructure issue: the service that runs tools (read files, spawn shells, search the workspace) was down or unreachable for that session.

But the strange thing is that it only happens in one specific project, I tried to ask for file reads in another project and it worked just fine…

[Elton_Nicolau]

same here, some times it works by reseting the IDE, mas sometimes don’t

[Hezaerd]

Even after switching off nightly + manually reinstalling 3.6.31, agents are unable to navigate through the project.

Agent answer on what is broken:

What the errors mean

Every tool call is returning:

Execution backend unavailable

That includes Read, Grep, Glob, and even a simple pwd. When that happens, agents can’t inspect the repo at all, so they sit there retrying or waiting until they time out.

[mohitjain (Mohit)]

This is a known issue where the extension host becomes unresponsive, which blocks all agent tool calls. Our team is actively working on it.

Since you’ve already tried switching from Nightly to Stable and reinstalling, here are some more targeted steps:

1. Check for a leftover out folder in cursor-socket

An older workaround created an out folder that now causes problems on newer versions. Open PowerShell and run:

dir "$env:LOCALAPPDATA\Programs\cursor\resources\app\extensions\cursor-socket"

If you see an out folder alongside dist, delete it:

cd "$env:LOCALAPPDATA\Programs\cursor\resources\app\extensions\cursor-socket"
Remove-Item "out" -Recurse -Force

Then fully quit and restart Cursor.

2. Start without extensions

Run cursor --disable-extensions from the command line. If the agent works, a heavy extension is interfering with the extension host startup. You can re-enable extensions one by one to find the culprit.

3. Clear workspace state for the affected project

This can help if the issue is specific to one project. Close Cursor, then delete the workspace storage for the affected project from %APPDATA%\Cursor\User\workspaceStorage\. Each subfolder corresponds to a project — you can check the workspace.json inside each to find the right one.

Important: Back up the folder before deleting, as this removes chat history for that project.

4. If none of the above help

Please send your Extension Host logs so we can diagnose further:

• Press Ctrl+Shift+P > “Developer: Open Logs Folder”

• From the newest session, grab exthost.log and everything in the window1 folder

• Share them here or email to [email protected]

@Clement_Gonin - since your issue is project-specific (one project broken, another works), step 3 above is most likely to help in your case.
@Elton_Nicolau - if resetting the IDE sometimes fixes it for you, that’s consistent with a stale extension host session. Steps 1 and 2 should make the fix more reliable than repeated resets.

[Hezaerd]

So I’ve tried every solutions you’ve suggested and none of them worked. In order here is the results:

1. No leftover out folder.

PS C:\Users\Admin> dir "C:\Program Files\cursor\resources\app\extensions\cursor-socket"

Répertoire : C:\Program Files\cursor\resources\app\extensions\cursor-socket

Mode                 LastWriteTime         Length Name



d-----        01/06/2026     13:09                dist
-a----        31/05/2026     18:21            182 extension.webpack.config.js
-a----        31/05/2026     18:21            477 package.json

2. Start without extensions
   Nothing changed, agents are still unable to use tools.

3. Clear workspace state
   Properly wiped the project folder, and still without extensions nothing changed.

4. Here is the exthost.log file and the whole window1 zipped folder

window1.zip (19,0 Ko)

exthost.log (6,7 Ko)

[alexmandrik (Alex Andras Mandrik)]

I have the same problem. For me, the `cursor-agent-worker` extension shows a “Reload Window” button, but even after I press it and the window reloads, the button stays there and the agent still can’t use the tools. Pretty annoying. I just started using Cursor yesterday and subscribed to Pro today.

[Scott_Adams]

A root cause for the “only one project is broken, others work fine” variant — a stale \\wsl.localhost (UNC) workspace identity

Posting in case it helps others with the project-specific flavor of this (one WSL project throws “Execution backend unavailable” on every tool call — Read/Grep/Glob/shell — while other WSL projects in the same Cursor + same WSL work normally).

In my case none of the usual fixes worked: Reload Window, full quit + relaunch, wsl --shutdown, rm -rf ~/.cursor-server (server reinstall), and cursor --disable-extensions all failed. That ruled out stale Linux server state and third-party extensions.

The actual cause: the affected folder had two Windows-side workspace-storage identities, not one:

• …\workspaceStorage\<hashA> → vscode-remote://wsl+ubuntu/home/<me>/repos/<proj> correct Remote-WSL identity
• …\workspaceStorage\<hashB> → file://wsl.localhost/Ubuntu/home/<me>/repos/<proj> a UNC / local-Windows identity over the \\wsl.localhost 9P share

The file://wsl.localhost/… identity opens the folder as a local Windows window with no Linux exec backend, which reproduces “Execution backend unavailable” on every tool call. It gets created if you ever open the folder from Windows File Explorer or a “recent folders” entry that resolved to \\wsl.localhost\… instead of opening it as Remote-WSL. The good project never had that second identity, which is why it kept working.

Fix:

1. Fully quit Cursor.
2. In %APPDATA%\Cursor\User\workspaceStorage\, open each subfolder’s workspace.json and find the one whose folder is file://wsl.localhost/… for the broken project. Delete that stale subfolder. (Back it up first — it contains that workspace’s chat history.)
3. Reopen the project only as Remote-WSL: from a WSL shell run cd /path/to/project && cursor .. Never reopen it via \\wsl.localhost\… or a Windows Explorer path.
4. Confirm the bottom-left status reads “WSL: Ubuntu”.

After deleting the stale UNC directory, the exec backend reconnected immediately and all tool calls (shell, file search, reads) worked again.

This is a more targeted version of the earlier “clear workspaceStorage” advice — the key is specifically the duplicate file://wsl.localhost identity, plus always reopening via cursor . from inside WSL so the bad identity isn’t recreated.

Note: this only addresses the project-specific variant. If every WSL project fails (or it regressed after a specific version like 3.7.27), that’s the broader extension-host issue tracked in the main thread, and this won’t help.

[Elton_Nicolau]

I found a workaround by connecting to WSL through SSH, not by wsl default connection

[mohitjain (Mohit)]

Thanks for the logs, they actually pinpoint what’s happening.

Your WSL connection itself is fine: Cursor connects to your Debian WSL server and detects the kernel. The problem is one layer up. The agent’s execution session never finishes attaching, so it times out after 30s, retries, and every tool call (Read/Grep/Glob/shell) falls back to “Execution backend unavailable.” This is the known extension-host issue our team is actively working on.

What’s specific to your case: the logs show the WSL workspace being set up twice - one connection resolves correctly, and a second one fails to resolve at all. That duplicate is what leaves the agent unable to lock onto a session. It matches what @Scott_Adams described above (a stale/duplicate WSL workspace identity). Since you already wiped the workspace state, the likely remaining cause is a leftover duplicate identity for that folder plus how the project gets reopened.

Two things to try, in order:

1. Quickest unblock - open the project over SSH instead of the default WSL integration. This is the workaround @Elton_Nicolau found: run an SSH server inside your WSL distro and connect to it with Remote-SSH (as a localhost Linux host) rather than the built-in WSL connection. It bypasses the WSL resolver path that’s failing for you.

2. Targeted fix - remove the duplicate WSL workspace identity.

Important: back up the folder first. Deleting workspace storage removes that workspace’s chat history.

• Fully quit Cursor.
• Open %APPDATA%\Cursor\User\workspaceStorage\ and check each subfolder’s workspace.json. For your project you may find two entries: one with a folder like vscode-remote://wsl+debian/... (the correct one) and one like file://wsl.localhost/... or a bare wsl path (the broken one).
• Delete only the broken file://wsl.localhost/... subfolder.
• Reopen the project only by running cursor . from inside a WSL shell - not from Windows Explorer or a \\wsl.localhost\... path, which is what recreates the bad identity.
• Confirm the bottom-left status bar reads WSL: Debian.

If neither helps, it’s likely the broader extension-host issue rather than the duplicate-identity variant, which we’re tracking centrally. Let us know how it goes.

[SACHIN_YADAV]

I was facing this issue from last few days but after clearing complete AppData\Roaming\Cursor\User\workspaceStorage now all tools and terminal commands are working.

[mohitjain (Mohit)]

Glad you’re unblocked!

One important caveat for anyone trying this: clearing workspaceStorage also wipes your agent and chat history for those projects, so please back up that folder before deleting anything.

If you’d rather keep your history, the more targeted fix is to reopen the project as Remote-WSL by running cursor . from inside your WSL shell (not from Windows Explorer or a \\wsl.localhost\... path) — that avoids the duplicate workspace identity that tends to trigger this. @Elton_Nicolau’s approach of connecting to WSL over SSH also works well as an alternative.

This is still a known issue our team is actively working on. If none of these get you going on the latest version, reply here and we’ll dig in further.

[Colin]

Hey all!

We’ve made a number of improvements over the past few months to how agent tools attach to WSL sessions, including the failures behind the “Execution backend unavailable” errors reported here.

Could you give it another try on the latest version? Quick check:

1. Update Cursor to the latest version
2. Open your WSL project
3. Ask the agent to read a file or run a simple command

If it’s resolved, no need to reply; if you still hit it, please open a new thread with updated details so we can take a fresh look.

cc @Clement_Gonin @Elton_Nicolau @alexmandrik @SACHIN_YADAV @Scott_Adams @Hezaerd