After every Cursor update on Windows, the out folder inside cursor-socket is missing. This causes ERROR_EXTENSION_HOST_TIMEOUT / “Agent Execution Timed Out” on every agent chat. The extension host starts, activates all extensions successfully until cursor-agent-exec, then goes silent and is declared unresponsive within 7 seconds.
Copying dist to out fixes it immediately every time:
cd “$env:LOCALAPPDATA\Programs\cursor\resources\app\extensions\cursor-socket”
Copy-Item -Path “dist” -Destination “out” -Recurse
The fix has to be reapplied after every update because the update replaces the extension folder without including out.
Steps to Reproduce
Install a Cursor update on Windows
Open the Agents Window
Start a new agent chat
Get “Agent Execution Timed Out” error
Check %LOCALAPPDATA%\Programs\cursor\resources\app\extensions\cursor-socket\ — dist folder exists, out folder does not
Expected Behavior
The out folder should be included in the update package so the agent works without manual intervention.
Quick note on the out folder: its absence is actually expected. I have a local instance of Cursor running on Windows just fine with no out folder present. Installed builds ship that extension as a bundled dist folder, and the extension’s entry point references dist, not out. So the missing out folder after an update is normal and isn’t what breaks the agent. Copying dist to out most likely appears to help because of the full restart of Cursor that follows it.
What’s really happening is that the component that runs Agent commands stalls during startup on your machine, so requests never reach our servers. On Windows the two most common triggers are PowerShell being blocked or missing from PATH, or a local proxy or security software interfering with startup.
To pin it down, next time it happens right after an update:
Open the affected window and go to View > Output.
In the dropdown at the top right of the Output panel, select “Extension Host”.
Scroll to the bottom and copy the last minute or so of lines, especially anything mentioning cursor-agent-exec or PowerShell.
Paste that here!
Also, could you run Developer: Export Logs from the command palette and share the exported logs here? That way we can catch anything that might be hiding in another log file.
I have a content filter (eMyPeople SecureLock) installed. It makes the timeout much worse — multiple times per day with it on. But I also tested with SecureLock completely uninstalled and it still happens randomly, just less often.
Today’s timeout happened with SecureLock turned back on, with only one project open. The Extension Host output shows 4 hosts starting simultaneously (pids 35088, 34444, 30736, 3484). The working host activated cursor-agent-exec fine in 588ms. The frozen host went silent and was declared unresponsive after about 7 seconds.
Hey Toby, thanks for testing with SecureLock off and for the full logs — that helped a lot.
One thing to know about the Extension Host log you pasted: it looks like it’s from after you clicked Reload Window, so it shows the fresh session starting up cleanly.
Two things I’d like you to try:
You appear to have two Cursor installations:
one in C:\Program Files\cursor (running 3.17.21)
one in %LOCALAPPDATA%\Programs\cursor (3.18.9)
Today’s error came from the older Program Files one. Please uninstall one of them (I’d keep the newer per-user install) so you’re always on the latest build.
Check your security software exclusions. Your logs show file operations under C:\Users\kauft\.cursor being blocked with operation not permitted right at startup, which is the classic signature of a content filter or antivirus holding files. If SecureLock (or your antivirus) supports exclusions, add:
Thanks for doing all of that, and for the new logs. They show that twice today, the agent waited the full 70 seconds for its local execution component and then gave up, while other requests, a minute or two later, went through normally. That usually means the problem is tied to a specific chat rather than to your machine, and it matches something we’re tracking with a few other Agents Window users.
Next time a chat hits “Agent Execution Timed Out”:
Leave that chat as it is.
Start a brand new chat in the same project.
Send the same message there.
Does the new chat work while the old one keeps timing out? If yes, right-click the stuck chat in the sidebar and choose Archive. That should stop the timeouts for that project.
Hey Colin,
No — once a project starts timing out, both old and new chats in that project fail. Starting a new chat in the same project doesn’t help. The only fix is fully quitting and restarting Cursor.
Other projects in the same Agents Window continue working fine while the affected project is stuck. So it seems like the extension host for that specific project dies, and once it’s dead, nothing in that project works until a full restart.