My chats are just hanging with "Planning next moves" and "Taking longer than expected..."

Support Bug Reports
,
26
  • i dont see how to disable http/2 i only have http/1. http/1.1 http/2
27

@Casey_Salmon your diagnostics look clean, so it’s not a network issue.

In Settings, where you see the HTTP/1, HTTP/1.1, HTTP/2 options, select HTTP/1.1 and fully restart Cursor. The main workaround is to switch from Auto to a specific model like Claude 4.6 Sonnet or GPT-5. Auto uses routing that sometimes gets stuck.

Also, please send:

  • Cursor version Help > About
  • OS
  • Request ID from the stuck chat right top corner menu > Copy Request ID

The every 3 to 4 hours pattern is interesting. With the Request ID, we can check what’s happening on the server side.

28

so lets pretend im broke and can only afford auto :smiley: do i just switch the model then switch back or do i need to run a basic command then switch back?

29

No, you don’t need to switch models back and forth. If it freezes, just open a new chat with Cmd+N or Ctrl+N and try again. That often helps, especially if the issue is looping like yours.

For HTTP, in that list (HTTP/1, HTTP/1.1, HTTP/2) pick HTTP/1.1 and fully restart Cursor. That’s the workaround instead of Disable HTTP/2.

I still need the info from the last message too: your Cursor version (Help > About), your OS, and the Request ID from the frozen chat (menu in the top-right of the chat > Copy Request ID). Without the Request ID, we can’t check what’s happening on the server.

30

ok yes i have done this, ive had up to 4 agents trying, when it hits the “taking longer than expected” spot it effects all agents, even older ones that were running smooth, its a full on halt to the agents. Mine just started doing it again FYI so the 3-4 hours thing i was incorrect about.

31

20 minutes, deadlocked, no agents working

32

and it just started moving at a turtles pace and now its duplicating markdowns and jacking up what i had… this needs to get fixed or it will break some repos - for whats its worth, all of the agents that halted, resumed at the same time no new agent creation needed to run what was pending…

33

yall… this is still going on, this is not on our end….

34

Hi, are there any updates according the issue? Im still getting a timed out error when running agents on a worktree.

Im running Opus 4.6 High(not in Auto mode)

This is my systems info:
Version: 3.2.0-pre.11.patch.0
VSCode Version: 1.105.1
Commit: 162121a60ddf638794d208fc9fb045a0dd019840
Date: 2026-04-11T05:50:37.024Z
Layout: glass
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
OS: Darwin arm64 25.3.0
This is my Request IDRequest ID: 78ba8ad8-9b77-4b03-93cd-2f6b46464f5f

This is the error
{“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”:}}
The agent execution provider did not respond in time. This may indicate the extension host is not running or is unresponsive.
Agent Execution Timed Out [deadline_exceeded]
ConnectError: [deadline_exceeded] Agent Execution Timed Out
at vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:38250:27228
at async tdS.createExecInstance (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:38250:23698)
at async O4_ (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:28645:632085)
at async DF.execute (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:28866:7896)
at async pgd.execute (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:38250:1792)
at async bzS.execute (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:41245:4969)
at async sxd.buildComposerRequestContext (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:41255:4190)
at async sxd.streamFromAgentBackend (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:41255:6959)
at async sxd.getAgentStreamResponse (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:41255:17838)
at async M3e.submitChatMaybeAbortCurrent (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:28983:16809)
at async JiC.submitMessage (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:44633:83361)
at async twC.submitMessage (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:45654:12554)

35

I can see the issue still reproduces in worktree mode. Thanks for the Request ID and the detailed stack trace.

The ERROR_EXTENSION_HOST_TIMEOUT or deadline_exceeded error in worktree is a known issue. The team is aware. There’s no ETA yet, but your report helps us prioritize it.

A few things to check:

  1. You’re using Opus 4.6 High thinking with a 1M context window. Try temporarily reducing the context window, or switch to standard thinking. A large context in worktree can cause the extension host to time out.
  2. Make sure your worktree doesn’t contain too many files outside .gitignore. Codebase indexing in a worktree can overload the extension host.
  3. You’re on nightly 3.2.0-pre.11. If possible, try stable to rule out a nightly-only regression.

I’ve logged the Request ID. Let me know if any of this helps.

1 Like
36

I can see the issue is still happening. The fact that all agents freeze and then resume at the same time points to a server routing issue, not something local.

But to check server logs, I need a Request ID. Without it, we literally can’t find your requests on the server. Next time an agent freezes:

  1. Click the menu in the top-right of the chat > Copy Request ID
  2. Send it here along with your Cursor version via Help > About and your OS

Also confirm this: did you switch HTTP version to HTTP/1.1 and fully restart Cursor, not Reload Window, but Quit + Open?