I’m seeing the same Execution backend unavailable error in a WSL remote workspace.
Setup: Windows 11, WSL2 Ubuntu, folder opened via Remote-WSL.
What fails: Agent tools (Shell, Read, Grep, Glob) — almost always Execution backend unavailable. Sometimes one file reads, then the next attempt fails again.
What still works: Files show fine in the sidebar; WSL remote connection looks OK in logs; MCP starts normally.
Tried: Reload Window, full Cursor restart, wsl --shutdown — no lasting fix.
Versions: Reproduced on Cursor 3.6 and 3.7.
Agent is basically unusable in WSL right now — can’t read/edit files or run commands. Planning to try the Agent Window workaround and/or downgrade if needed.
I’m having the same issue. Reverting to 3.5.38 works just fine for me, except, despite updating these values:
“update.enableWindowsBackgroundUpdates”: false,
“update.mode”: “none”
It still updates on me for some reason. I had it on 3.5.38 on Friday, and on Monday, it was back to latest. So I had to downgrade again today. Are there other settings I’m missing when it comes to updates that are pushed automatically? These were the ones in the VSCode Settings file.
I normally run --disable-extensions through SSH, not local, but last time, SSH wasn’t working, local was still working.
How would i go about trying the extension disable on SSH if not the way i tried?
I also keep getting this now.
Request ID: 965a6c0d-f2b1-40bb-9bb2-10018bca6ea1
{“error”:“ERROR_EXTENSION_HOST_TIMEOUT”,“details”:{“title”:“Workspace Disconnected”,“detail”:“Cursor lost connection to the workspace while starting tool execution. Reload the window and try again.”,“isRetryable”:false,“shouldShowImmediateError”:true,“additionalInfo”:{},“buttons”:,“planChoices”:}}
Workspace Disconnected Cursor lost connection to the workspace while starting tool execution. Reload the window and try again.
D7t: Workspace Disconnected Cursor lost connection to the workspace while starting tool execution. Reload the window and try again.
at s_1 (vscode-file://vscode-app/c:/Users/USER/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:35723:27492)
at Nsg (vscode-file://vscode-app/c:/Users/USER/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:35723:26306)
at f_1 (vscode-file://vscode-app/c:/Users/USER/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:35724:7469)
at $sg.run (vscode-file://vscode-app/c:/Users/USER/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:35724:12370)
at async qle.runAgentLoop (vscode-file://vscode-app/c:/Users/USER/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:48124:2927)
at async GJg.streamFromAgentBackend (vscode-file://vscode-app/c:/Users/USER/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:48195:12809)
at async GJg.getAgentStreamResponse (vscode-file://vscode-app/c:/Users/USER/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:48195:21069)
at async sut.submitChatMaybeAbortCurrent (vscode-file://vscode-app/c:/Users/USER/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:35854:1995)
at async no (vscode-file://vscode-app/c:/Users/USER/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:47078:33305)
hi, you can downgrade from a github repo. i do not know if it’s allowed to share links, but you can find from the internet. doent matter if you use wsl, just normal windows setup
I’m also using WSL 2. Downgrading to 3.5.38 works. You can get it from the cursor repo( linked in the version number in my comment) and just install it directly. No need to un-install your current version as this will go right over the top of it. I use the PATH option to launch cursor from my current directory from the bash shell with ``cursor .`` and it launches the correct version I downgraded to when doing so, but every few days, it upgrades itself without asking, so I just keep the install in my downloads in case I need it again.
The workaround I’ve been resorting to is to switch to the Cursor CLI once this issue pops up. The agent CLI app doesn’t seem to be affected by this issue. The bug also disappears after a system restart (almost always), and sometimes after a WSL restart. The unpredictability of this means that I’ve been using the cursor agent CLI quite a bit for the last week or so, even though I feel the CLI is so much inferior for a plan-revise-build work-loop.
Same issue here — Windows 11 + WSL2 + Cursor.
After auto-updating to the latest version, the execution backend became unavailable.
Downgrading to 3.5.38 resolved the issue.
Please consider fixing this so the backend stays stable across version upgrades.
