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

Support Bug Reports
,
48

@Yaroslav_Zhuk nice find! This is a legit workaround. Third-party plugins and skills can cause conflicts that slow down or hang the agent.

For everyone else in this thread still hitting this issue, try this:

  1. Cursor Settings > Rules, Skills, Subagents
  2. Turn off “Include third-party Plugins, Skills, and other configs”
  3. Restart Cursor

This is in addition to the other workarounds already mentioned: disabling HTTP/2, switching from Auto to a specific model, and cleaning up state.vscdb if it’s oversized.

@Chauhan_Sahil @Casey_Salmon @Alex_Shavkuta worth trying this if the previous fixes didn’t fully resolve it for you.

49

I had been struggling with this issue for past day or so, and tied it to the same set of issues with the latest drops of 3.0 and Opus 4.7. Since this thread/ bug report is from yesterday, it does seem related. I am midway through an agent operation when I changed the setting to try this workaround, so I may not see the effect till the next operation. But even if it does help to turn this setting off (something that I personally do not need), this setting is not new whereas the problem started showing up or got significantly worse only recently. Hope we can have a speedy resolution to this.

50

Unfortunately, this setting change did not improve performance in my case, or not significantly. (I also do not have any network issue). The only difference is that I do not see the message ‘Taking longer than expected’. By the way, the performance has become so sluggish since yesterday that it sometimes looks like the agent response is showing up one letter at a time …

On a side note, I have to use Auto so I do not run out of tokens, but that also means I have no control (and no way of knowing) which model is being used.

51

same, hand or reconnect or unable to reach model provider

52

Since around 10:30 PM GMT+2 yesterday (17 April), I haven’t been able to use cursor anymore. I’m getting the same errors mentioned in this thread.

Provider error: We’re having trouble connecting to the model provider. This might be temporary - please try again in a moment.

Internal error: An unexpected error occurred on our servers. Please try again, or contact support if the issue persists.

I’m using linux mint 22.2 and the latest cursor Cursor-0.50.5-x86_64.AppImage

Version: 3.1.15
VSCode Version: 1.105.1
Commit: 3a67af7b780e0bfc8d32aefa96b8ff1cb8817f80
Date: 2026-04-15T01:46:06.515Z
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
OS: Linux x64 6.8.0-107-generic

The Cursor Network Diagnostic results are all ‘success’. I can provide these when necessary.

One of the last errors:

Request ID: 80d7d5fc-9e75-4456-83a0-1e1b419ee666
{“error”:“ERROR_PROVIDER_ERROR”,“details”:{“title”:“Provider Error”,“detail”:“We’re having trouble connecting to the model provider. This might be temporary - please try again in a moment.”,“isRetryable”:false,“additionalInfo”:{},“buttons”:,“planChoices”:},“isExpected”:true}
Provider Error We’re having trouble connecting to the model provider. This might be temporary - please try again in a moment.
NLi: Provider Error We’re having trouble connecting to the model provider. This might be temporary - please try again in a moment.
at Bz_ (vscode-file://vscode-app/tmp/.mount_CursorpjFIhc/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:28907:24552)
at Nz_ (vscode-file://vscode-app/tmp/.mount_CursorpjFIhc/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:28907:23543)
at Wz_ (vscode-file://vscode-app/tmp/.mount_CursorpjFIhc/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:28908:6487)
at h6u.run (vscode-file://vscode-app/tmp/.mount_CursorpjFIhc/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:28908:11285)
at async vDn.runAgentLoop (vscode-file://vscode-app/tmp/.mount_CursorpjFIhc/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:41216:11960)
at async zkd.streamFromAgentBackend (vscode-file://vscode-app/tmp/.mount_CursorpjFIhc/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:41286:12151)
at async zkd.getAgentStreamResponse (vscode-file://vscode-app/tmp/.mount_CursorpjFIhc/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:41286:18486)
at async B3e.submitChatMaybeAbortCurrent (vscode-file://vscode-app/tmp/.mount_CursorpjFIhc/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:29014:16809)
at async WYa.acceptPlan (vscode-file://vscode-app/tmp/.mount_CursorpjFIhc/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:29054:28972)
at async Ce (vscode-file://vscode-app/tmp/.mount_CursorpjFIhc/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:41790:3005)

I usually use auto mode, but when I tried to select different models explicitly, it didn’t work either. I also tried

Turn off “Include third-party Plugins, Skills, and other configs”

and I emptied my ~/.cursor directory, but that didn’t help either.

https://status.cursor.com/ doesn’t list any incidents.

I’m now running out of options. Do you have any suggestions about how I can use Cursor again?

53

Same behavior for me no matter what model I use.
Seemed to be working fine yesterday, even with the https2 option
The only thing different today, I purchased Pro

Version: 3.1.15
VSCode Version: 1.105.1
Commit: 3a67af7b780e0bfc8d32aefa96b8ff1cb8817f80
Date: 2026-04-15T01:46:06.515Z
Layout: editor
Build Type: Stable
Release Track: Default
Electron: 39.5.2
Chromium: 142.0.7444.265
Node.js: 22.22.0
V8: 14.2.231.22-electron.0
OS: Linux x64 6.17.1-arch1-1-surface

54

Hi,

I tried running cursor without the extensions and it didn’t help.
I have 756 files outside of the .gitignore.

I have also tried to run on a smaller project(7 files and it still didn’t work, note that without worktree it worked)

This is the request logs from the small repo

Request ID: 79649ea3-0ae8-421c-8385-b585268e1ea6
{"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 zlb (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:38281:25776)
    at ufd.waitForProviderRegistration (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:38281:28797)
    at async zkd._waitForPushRequestContextProviderRegistration (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:41286:4043)
    at async zkd.streamFromAgentBackend (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:41286:7541)
    at async zkd.getAgentStreamResponse (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:41286:18486)
    at async B3e.submitChatMaybeAbortCurrent (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:29014:16809)
55

Hey @sravasti @Dev7 @lars_lingner @charrix

What you’re describing Provider Error, trouble connecting to the model provider is not the same issue this thread started with. It’s a different kind of error. The request reaches our server, but we don’t get a response from the model provider. The old workarounds HTTP/1.1, disabling third-party skills, state.vscdb won’t affect this.

To debug this, I need a Request ID from a recent failed request. For everything else, please send:

  1. Request ID from the failed chat: menu in the top right of the chat > Copy Request ID
  2. The exact error text Provider Error / Network Error / ERROR_EXTENSION_HOST_TIMEOUT are different
  3. Cursor version Help > About and your OS
  4. Which model was selected when it failed

@sravasti about Auto: if requests still fail, try switching to a specific model Claude 4.6 Sonnet or GPT-5. Sometimes Auto routing hits a problematic provider, while a specific model goes through a different path. Auto doesn’t save tokens in the way you described.

@charrix if this started right after upgrading to Pro, check Cursor Settings to make sure Pro is active. If it didn’t start right away, log out and log back in.

We’re tracking an issue on our side, but I can’t share an ETA yet. Request IDs will help us see what’s happening on the backend for your cases.

56

Hey @Alex_Shavkuta, great isolation work, thanks. The fact that it still times out in worktree mode even with a repo of 7 files with no extensions in the worktree, but works fine without worktree, is a clean enough repro that we can keep digging on our side.

From the stack trace, it looks like the extension host doesn’t register the push request context provider in worktree mode in time. That’s clearly a bug on our side, not a config issue.

I’ll post an update in the thread as soon as I have one.

For now, the only working workaround is to run the agent without worktree mode, since normal mode works for you. If working on multiple features in parallel is critical, you can use separate clones of the repo in different folders and open them in separate Cursor windows. It’s less convenient, but it avoids this bug.

57

Confirmed Pro is active. Tried logging out and logging back in.
Here’s a few request IDs for a simple testing scenario

Using exsting C# Hello, World.

Prompt the user for two numbers. Then add two numbers and display the result.

ChatGPT-5.4
Retry ChatGPT-5.4 - Plan
Reconnecting…
Request ID: ced6501d-663c-43af-8074-0d8b26f92fd3
[unknown] Network disconnected

New Agent
ChatGPT-5.4 - Plan
Reconnecting…
User Cancelled: Taking more than 5 minutes

Logout - Relogin

Auto - Plan
Reconnecting…
Request ID: 01aef3ed-2cd0-4608-944d-1743ec266398
[unknown] Network disconnected

New Agent
Codex 5.3 - Plan
Reconnecting…
Request ID: f8e98b82-8db2-4512-a4af-decd85d45748
[unknown] Network disconnected

58

+1. Happening with me too.

Tried everything.

Switching networks (Wifi, Mobile Data, Corporate VPN). Nightly builds. Even tried my own openai and anthropic API keys. Changing models. Nothing is working.

The only time it works is when I create new chat thread. I have multiple models (opus 4.7 and gpt 5.4), images and few mcps usage in the chat thread where cursor is stuck in reconnecting state now.

As a workaround right now I am exporting my transcript and feeding into a new chat thread as text to continue.

59

Happening here too, on Cursor 3.1.17, request ID 9c1f7472-407e-4738-916d-02e12fb8866b, every time I try to use Opus 4.7.

60

Just started happening to me as well, request ID 256a9684-7172-4750-a978-455f6a262d1e

61

Hey, quick update on the latest reports.

@blueshift @Oussama_MATAR @APS09: what you’re describing getting stuck on Opus 4.7 and only a new chat helps is tracked on our side.

No ETA for a fix yet. Workarounds that already help @APS09:

  • Start a new chat with Cmd+N or Ctrl+N instead of continuing a long thread, especially if it has images and MCP calls.
  • Switch to Claude 4.6 Sonnet or GPT-5 for background work while Opus 4.7 is still broken.

@Oussama_MATAR: if you have a minute, please share your Cursor version Help > About, your OS, and which model you used. One Request ID isn’t enough to spot a pattern.

@charrix: your case looks a bit different, Network disconnected across multiple models in a row. A couple questions:

  1. Are you using worktree mode or normal mode?
  2. Does Ask mode work, not Agent?
  3. Please share results from Cursor Settings > Network > Run Diagnostics. If everything is success, it’s likely not a network issue and we’ll dig further.

This thread got very long and mixed a few different bugs. If your symptoms don’t match the Opus 4.7 pattern, please open a separate topic with Request ID, OS, version, and the exact error text, it’ll help us troubleshoot faster.

62

Nothing is working. Read the entire thread, performed all workaround - HTTP/1.1, restart, switching to Sonnet 4.6, New chat, nothing works. I get a constant “reconnecting” message. Here are the logs

Request ID: dd98b56f-2208-4ac0-96c2-80ef2e97929b
[unknown] Network disconnected
mIe: [unknown] Network disconnected
at mg_ (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:29432:24345)
at dg_ (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:29432:23144)
at wg_ (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:29433:6490)
at nCh.run (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:29433:11307)
at async lQi.runAgentLoop (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:41749:12418)
at async mim.streamFromAgentBackend (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:41817:12344)
at async mim.getAgentStreamResponse (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:41817:19567)
at async hCt.submitChatMaybeAbortCurrent (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:29548:16906)
at async Xa (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:40804:4244)

63

Hey @pratik85-pixel, “Network disconnected” is a different error type than what this thread started with. To dig in, I’ll need a bit more info:

  • Cursor version and OS: Help > About
  • Are you using worktree mode or the normal mode?
  • Which model was selected for Request ID dd98b56f-2208-4ac0-96c2-80ef2e97929b?
  • Cursor Settings > Network > Run Diagnostics: please paste the full output
  • After switching to HTTP/1.1, did you do a full Quit and reopen, or only Reload Window? This matters because Reload Window doesn’t apply that setting.

This thread has grown and now mixes a few different bugs: HTTP/2 proxy, worktree timeout, Opus 4.7 hang, and Provider Error. If your symptoms don’t match one of those, it’s better to open a new topic with the info above so we can sort it out faster.

64

THe problem got resolved by installing warp by cloudflare. Thanks.
i will still answer your questions

  1. Version: 3.2.16
    VSCode Version: 1.105.1
    Commit: 3e548838cf824b70851dd3ef27d0c6aae371b3f0
    Date: 2026-04-28T21:07:47.682Z
    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
    OS: Darwin arm64 25.1.0
  2. normal mode but different fork from the main chat
  3. Sonnet 4.6
  4. SInce now its working, diagnostic is all ok
  5. Yes, i did full quit and reopen
65

Hey, glad it worked. Thanks for coming back to confirm and answer the questions.

Warp by Cloudflare helped because it routes traffic through Cloudflare (1.1.1.1 + WireGuard), bypassing an intermediate proxy or buffering layer that was breaking streaming between Cursor and our servers. Our diagnostics showed success right after enabling Warp, which confirms the bottleneck was on the network path, not in Cursor and not on our side.

For anyone else reading this thread with [unknown] Network disconnected or constant Reconnecting that doesn’t get fixed by forcing HTTP/1.1, switching models, or starting a new chat, try changing the network path. Warp by Cloudflare, any VPN, or a mobile hotspot. If it works on another network, the issue is an intermediate proxy, CGNAT, or ISP DPI, not the client.

This thread now has a few different bugs under one title (HTTP/2 proxy, worktree timeout, Opus 4.7 hang, Provider Error, Network disconnected). If your symptom isn’t Network disconnected, please start a separate topic with the Request ID, version, OS, and the exact error text so we can debug it faster.

66

@deanrie
Is there any updates about the issue i had? i still cant run in worktrees.

This is cursor info

Version: 3.2.21
VSCode Version: 1.105.1
Commit: 806df57ed3b6f1ee0175140d38039a38574ec720
Date: 2026-05-03T01:46:14.413Z
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
OS: Darwin arm64 25.3.0

These are the logs from the error i had today

Request ID: 90cd0df4-c088-437a-87b1-cab217d83bfb
{"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 E_y (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:38816:21732)
    at VVh.waitForProviderRegistration (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:38816:24753)
    at async nrm._waitForPushRequestContextProviderRegistration (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:41817:4045)
    at async nrm.streamFromAgentBackend (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:41817:7626)
    at async nrm.getAgentStreamResponse (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:41817:19567)
    at async vCt.submitChatMaybeAbortCurrent (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.desktop.main.js:29548:16906)
67

Hey @Alex_Shavkuta. Honest update: there’s no fix yet, but we’re tracking this on our side as high priority and the investigation is active. I can’t share an ETA.

Thanks for the new Request ID, I’ll add it to our tracker. The fact that it reproduces across multiple client versions (3.1.14 → 3.2.21) with the same _waitForPushRequestContextProviderRegistration stack in worktree mode is a useful signal for the team.

For now, the workaround stays the same: run the agent without worktree mode. If parallel work on features is critical, you can keep multiple clones of the repo in different folders and open them in separate Cursor windows. It’s less convenient, but it avoids the bug.

I’ll post here once I have an update on the fix.

P.S. For everyone else in the thread: this thread has grown and is now mixing a few different bugs under one title (HTTP/2 proxy, worktree timeout, Opus 4.7 hang, Provider Error, Network disconnected). If your symptom isn’t the worktree timeout, please open a separate topic with your Request ID, version, OS, and the exact error text so we can resolve it faster.