In Cursor 2.4.37 on Windows, Agent chat works normally for local Windows projects, but when I open/connect to a WSL project, Agent chat becomes unusable and continuously shows “Waiting for Extension Host” (never resolves). Reloading Window didn’t solve the problem, either.
I tried installing an older Cursor version, and the WSL Agent chat issue does not happen there, so this appears to be a regression in 2.4.37.
However, I cannot stay on the older version because Cursor auto-updates back to 2.4.37 after I close and reopen Cursor (or even after Windows restart). This happens even when I set:
update.mode to none or manual (no effect)
So I currently have:
A regression in 2.4.37 affecting WSL extension host / Agent chat
An inability to rollback because the app forces an automatic update regardless of update settings
Steps to Reproduce
Issue A: WSL project stuck on “Waiting for Extension Host”
Install Cursor 2.4.37 on Windows 10/11
Open a local Windows project → Agent chat works normally
Open/connect to a WSL project (Remote/WSL workspace)
Try to send a message to Agent
Observe it stays on “Waiting for Extension Host” indefinitely and cannot chat
This is a known “Agent Execution Timed Out” error. The team is aware and looking into it. What’s interesting about your case is that it only happens in WSL, while it works locally. Can you try a few things:
Fully close Cursor, delete this file (make a backup first) C:\Users\[username]\AppData\Roaming\Cursor\User\globalStorage\state.vscdb, then restart Cursor
Make sure Git is installed inside WSL (git --version in the WSL terminal)
Try enabling Early Access (Cursor Settings > Beta > Early Access). Sometimes it’s already fixed in a newer build
About auto-updates:
Yeah, that’s pretty annoying. The update.mode setting sadly doesn’t always work correctly on Windows to prevent auto-updates. I’ll pass this feedback to the team since it really blocks rolling back.
A couple questions: which WSL distro are you using (Ubuntu, Debian, etc.) and what’s your WSL version (wsl --version in PowerShell)?
Fully closed Cursor, deleted (after backup) C:\Users\[username]\AppData\Roaming\Cursor\User\globalStorage\state.vscdb
then restarted Cursor.
Confirmed Git is installed inside WSL: git --version → 2.43.0
Enabled Early Access (Cursor Settings → Beta → Early Access).
Result
After doing the above, the Agent chat UI no longer loads properly. The chat panel stays stuck on “Loading chat” and the conversation window never appears.
I can see from the screenshot that the chat is stuck on “Loading chat”. Deleting state.vscdb didn’t seem to help, and it might’ve made things worse. Let’s try to recover and collect more diagnostics:
If you saved a backup of state.vscdb, restore it and restart Cursor. Let’s see if it at least goes back to the earlier symptom (“Waiting for Extension Host” instead of “Loading chat”).
After that, open your WSL project and collect logs:
Go to Help > Toggle Developer Tools > Console, then copy the errors (the red lines).
In the Output panel View > Output, select “Remote Extension Host (WSL)” and copy everything there.
Also try Ctrl+Shift+P > Developer: Restart Extension Host, then wait for it to restart. This sometimes helps in WSL.
Send the logs and we’ll take a look at what’s happening on the Extension Host side.
After this happens, I can’t get back into the chat UI unless I uninstall Cursor and reinstall. Reinstalling is the only way I can see the chat window again.
2) Developer Tools Console errors (red lines)
From Help → Toggle Developer Tools → Console, I see these errors:
ERR Error received from starting extension host (kind: Remote)
ERR The remote extension host took longer than 60s to send its ready message.
ERR [Extension Host] (node:41516) Warning: Setting the NODE_TLS_REJECT_UNAUTHORIZED environment variable to '0' makes TLS connections and HTTPS requests insecure by disabling certificate verification.
(There are repeated stack traces pointing to workbench.desktop.main.js.)
The details are as follows:
ERR Error received from starting extension host (kind: Remote)
error @ workbench.desktop.main.js:58
error @ workbench.desktop.main.js:58
error @ workbench.desktop.main.js:36008
(anonymous) @ workbench.desktop.main.js:34002
workbench.desktop.main.js:58
ERR The remote extension host took longer than 60s to send its ready message.
error @ workbench.desktop.main.js:58
error @ workbench.desktop.main.js:58
error @ workbench.desktop.main.js:36008
(anonymous) @ workbench.desktop.main.js:34002
ERR [Extension Host] (node:41516) Warning: Setting the NODE_TLS_REJECT_UNAUTHORIZED environment variable to ‘0’ makes TLS connections and HTTPS requests insecure by disabling certificate verification.
(Use Cursor --trace-warnings ... to show where the warning was created)
error @ workbench.desktop.main.js:58
error @ workbench.desktop.main.js:58
error @ workbench.desktop.main.js:36008
BFf @ workbench.desktop.main.js:11408
$logExtensionHostMessage @ workbench.desktop.main.js:11408
_doInvokeHandler @ workbench.desktop.main.js:33998
_invokeHandler @ workbench.desktop.main.js:33998
_receiveRequest @ workbench.desktop.main.js:33998
_receiveOneMessage @ workbench.desktop.main.js:33998
(anonymous) @ workbench.desktop.main.js:33998
_deliver @ workbench.desktop.main.js:49
fire @ workbench.desktop.main.js:49
fire @ workbench.desktop.main.js:11425
(anonymous) @ workbench.desktop.main.js:36059
workbench.desktop.main.js:11408
[Extension Host] (node:41516) Warning: Setting the NODE_TLS_REJECT_UNAUTHORIZED environment variable to ‘0’ makes TLS connections and HTTPS requests insecure by disabling certificate verification.
(Use Cursor --trace-warnings ... to show where the warning was created)
DFf @ workbench.desktop.main.js:11408
$logExtensionHostMessage @ workbench.desktop.main.js:11408
_doInvokeHandler @ workbench.desktop.main.js:33998
_invokeHandler @ workbench.desktop.main.js:33998
_receiveRequest @ workbench.desktop.main.js:33998
_receiveOneMessage @ workbench.desktop.main.js:33998
(anonymous) @ workbench.desktop.main.js:33998
_deliver @ workbench.desktop.main.js:49
fire @ workbench.desktop.main.js:49
fire @ workbench.desktop.main.js:11425
(anonymous) @ workbench.desktop.main.js:36059
In View → Output, I cannot find an entry named “Remote Extension Host (WSL)” in the Output dropdown, so I’m unable to copy logs from that channel. There is even no option named “Remote Extension Host”.
4) Developer: Restart Extension Host
When I run Ctrl+Shift+P → Developer: Restart Extension Host, it fails and shows:
Hi team, I found something strange. The “Waiting for Extension Host” issue is not only happening with WSL. I also see the same message when connecting to other remote servers via SSH.
However, the behavior is different:
Remote-SSH: after connecting, it shows “Waiting for Extension Host” for a short time, but it recovers quickly and I can then chat with the Agent normally.
WSL: it gets stuck on “Waiting for Extension Host” and never recovers, so Agent chat remains unusable.
So it seems like the extension host startup/ready handshake works eventually for SSH remotes, but consistently times out / fails for WSL in my setup.
I found a major clue that seems directly related to the WSL “Waiting for Extension Host / Loading chat” problem:
When my Cursor UI language is set to Chinese (Simplified), connecting to a WSL project consistently gets stuck and I cannot chat with the Agent.
However, as soon as I switch the UI language back to English, the same WSL project works normally and I can chat with the Agent without issues.
So the WSL remote/extension host hang appears to be strongly correlated with having Chinese (Simplified) enabled as the display language. It would be great if you could investigate whether the Chinese language pack / localization path is affecting the WSL extension host startup or Agent initialization in 2.4.37.
I tried the steps you suggested. Here are the results:
Reinstalled Cursor server inside WSL
I deleted the server directory in WSL and let Cursor reinstall it:
rm -rf ~/.cursor-server
Reconnected to the WSL project from Cursor → it reinstalled successfully.
Checked NODE_TLS_REJECT_UNAUTHORIZED in WSL
Running echo $NODE_TLS_REJECT_UNAUTHORIZED prints nothing (empty output), so it does not appear to be set to 0 in my WSL environment.
Key finding: the issue depends on the display language
If I set Configure Display Language to English, I can connect to the same WSL project and chat with the Agent normally.
If I set the display language to Chinese (Simplified), the WSL Agent chat fails again (stuck / cannot chat).
So at this point, the WSL extension host / Agent chat issue seems strongly correlated with using Chinese (Simplified) as the UI language (language pack / localization path), while English works reliably.
That’s a great diagnostic find. The link to the Chinese (Simplified) display language explains why the issue only reproduces in WSL and not for all users.
For now, switching to English is a working workaround. I’ve passed this to the team as a localization-related bug tied to the WSL extension host.
