Error_extension_host_timeout

Support Bug Reports
, ,
1

Describe the Bug

The agent execution provider did not respond in time. This may indicate the extension host is not running or is unresponsive.

Steps to Reproduce

I simply used auto and asked it to mirror the setup of assets/images and image sizes, then it gave me this error.
And now it happens on all new chats.

Expected Behavior

I expect the chats to continue.

Operating System

Windows 10/11

Version Information

Version: 3.6.31 (user setup)
VS Code Extension API: 1.105.1
Commit: 81fcf2931d7687b4ff3f3017858d0c6dee7e2a60
Date: 2026-05-31T17:46:29.630Z
Layout: editor
Build Type: Stable
Release Track: Default
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?

Auto

For AI issues: add Request ID with privacy disabled

Request ID: f6be073a-67df-4346-ba5c-4b6f32f01836
{“error”:“ERROR_EXTENSION_HOST_TIMEOUT”,“details”:{“title”:“Agent Execution Timed Out”,“detail”:“The agent execution provider did not respond in time. This may indicate the extension host is not running or is unresponsive.”,“isRetryable”:false,“shouldShowImmediateError”:true,“additionalInfo”:{},“buttons”:[{“label”:“Reload Window”,“reloadWindow”:{}}],“planChoices”:}}
Agent Execution Timed Out [deadline_exceeded]
ConnectError: [deadline_exceeded] Agent Execution Timed Out
at ULw (vscode-file://vscode-app/c:/Users/USER/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:44341:28583)
at VKd.waitForProviderRegistration (vscode-file://vscode-app/c:/Users/USER/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:44341:33347)
at async _bf._waitForPushRequestContextProviderRegistration (vscode-file://vscode-app/c:/Users/USER/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:47691:4084)
at async _bf.streamFromAgentBackend (vscode-file://vscode-app/c:/Users/USER/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:47691:7354)
at async _bf.getAgentStreamResponse (vscode-file://vscode-app/c:/Users/USER/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:47691:19276)
at async Zut.submitChatMaybeAbortCurrent (vscode-file://vscode-app/c:/Users/USER/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:36407:17835)
at async Object.$s [as onSubmit] (vscode-file://vscode-app/c:/Users/USER/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:46696:3887)
at async vscode-file://vscode-app/c:/Users/USER/AppData/Local/Programs/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:45757:103088

Additional Information

I have tried deleting \globalStorage\state.vscdb
I have tried cursor --disable-extensions in SSH

Does this stop you from using Cursor

Yes - Cursor is unusable

6

This is a known issue our team is actively investigating. ERROR_EXTENSION_HOST_TIMEOUT happens entirely on the client side: when a chat starts, Cursor’s extension host has about 30 seconds to register the agent execution provider, and when it doesn’t register in time you get this error. Because the request never actually reaches us, it tends to repeat on every new chat once the extension host is in a bad state.

A few things to try, roughly in order:

  1. Fully quit and relaunch Cursor - quit the app completely, not just “Reload Window.” Once the extension host gets stuck it usually won’t recover on its own, but a clean restart often clears it.

  2. Add Cursor to your antivirus / Windows Defender exclusions. On Windows, the most common cause we’ve seen is security software scanning Cursor’s files during startup and pushing extension host initialization past the timeout. The exact processes and paths to exclude are here: Endpoint Security. Restart and test afterward.

  3. Check the Extension Host log - Ctrl+Shift+P → Output → choose Extension Host from the dropdown. If it’s empty or stops partway, the host isn’t finishing startup (which points to #2). If it shows normal output, that’s useful to know too.

  4. Make sure your workspace folder is trusted - an untrusted workspace can silently block the agent from activating.

One thing that would help me narrow this down: you mentioned trying --disable-extensions over SSH - does the timeout also happen when you open a local Windows folder, or only over Remote-SSH? Over SSH the extension host runs on the remote machine, so the fix would be different.

There’s an active thread tracking this same 3.6.31 Windows error if you’d like to follow along: Agent execution provider did not respond in time.

8

I normally run it through SSH, not local, but last time SSH wasn’t working, local was still working.

How would i go on trying the extension disable on SSH if not the way i tried?

9

Thanks, that’s the detail that matters. Since a local folder works and only Remote-SSH fails, the extension host that’s timing out is the one running on your remote machine, not your local Windows one. That also means the antivirus exclusions I mentioned earlier probably aren’t the cause in your case.

For disabling extensions over SSH, skip the CLI flag and do it from inside the connected window instead: with your SSH window open, run Ctrl+Shift+P → “Developer: Reload with Extensions Disabled”. That reloads the current window with your third-party extensions turned off on both the local and remote sides, while keeping Cursor’s built-in agent pieces running. Start a new chat and see if the timeout still happens. If it goes away, a remote extension was slowing the remote host’s startup past the timeout. (A normal restart re-enables everything.)

If it still times out with extensions disabled, the remote server itself is likely stuck. Two things that help:

  1. Force a clean remote server. On the remote host, rename the server folder so Cursor reinstalls a fresh one on reconnect: mv ~/.cursor-server ~/.cursor-server.bak, then reconnect from Cursor. Your remote-installed extensions will re-download on first reconnect.
  2. Check the remote machine’s load - if it’s low on CPU/RAM or busy right when you connect, the remote extension host can take long enough to start that it blows past the timeout.

If neither helps, open the remote Extension Host log right after a failed chat (Ctrl+Shift+P → Output → pick “Extension Host” from the dropdown) and let me know whether it shows startup output or stops partway. That’ll tell us if the remote host is failing to finish starting.