For AI issues: add Request ID with privacy disabled
Request ID: 8f81217b-ba47-4ff6-9df0-e1ce41bc0cae
An unexpected error occurred.
[unavailable] PING timed out
RetriableError: [unavailable] PING timed out
at n6_ (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.glass.main.js:7759:118517)
at Gaa (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.glass.main.js:7759:117015)
at w6_ (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.glass.main.js:7760:12878)
at Object.classify (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.glass.main.js:7760:17452)
at g6_ (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.glass.main.js:7760:5856)
at async ola.run (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.glass.main.js:7760:16804)
at async Vme.runAgentLoop (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.glass.main.js:7901:34550)
at async Rwl.streamFromAgentBackend (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.glass.main.js:18799:14755)
at async Rwl.getAgentStreamResponse (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.glass.main.js:18799:32098)
at async EUe._submitChatMaybeAbortCurrent (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.glass.main.js:7868:2569)
Request ID: 3212648e-3f84-447e-83bb-ae5ee10533dc
The connection failed 10 times. Please check your network connection and try again.
Connection failed repeatedly
RetriableError: Connection failed repeatedly
at w6_ (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.glass.main.js:7760:14063)
at Object.classify (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.glass.main.js:7760:17452)
at g6_ (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.glass.main.js:7760:5856)
at async ola.run (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.glass.main.js:7760:16804)
at async Vme.runAgentLoop (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.glass.main.js:7901:34550)
at async Rwl.streamFromAgentBackend (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.glass.main.js:18799:14755)
at async Rwl.getAgentStreamResponse (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.glass.main.js:18799:32098)
at async EUe._submitChatMaybeAbortCurrent (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.glass.main.js:7868:2569)
at async EUe.submitChatMaybeAbortCurrent (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.glass.main.js:7859:72957)
Additional Information
I switched to HTTP 1.1 like it was said in other issues. There is no problem with connection if you can believe the diagnostic runs
Hey, thanks for the detailed report with the Request ID and stack trace. That really helps.
Quick summary: [unavailable] PING timed out and the reconnection loop mean the long-lived streaming connection to our servers is getting dropped somewhere along the network path, not because of your setup or account. Your account looks healthy, requests worked in the morning, so this is intermittent and tied to the route to the servers.
A few important notes:
HTTP/1.1: you did the right thing, but double-check how you applied it. After switching HTTP Compatibility Mode, you need a full quit and relaunch, not Reload Window. Otherwise some connections stay on the old transport. Please do a full restart and test again.
Diagnostics pass: this is expected and doesn’t contradict the issue. Diagnostics run short requests, and those survive. What’s failing is the agent’s long streaming connections, so diagnostics can be green while chat still keeps disconnecting.
If you’re behind a proxy, VPN, or firewall, make sure your allowlist includes *.cursor.sh, *.cursor.com, *.cursorapi.com, *.cursor-cdn.com, and that your network path can keep long-lived streaming connections stable. A quick way to isolate your provider is to run a couple requests on a mobile hotspot. If it’s stable there, the issue is with your main network path.
If the loop still happens after a full restart on HTTP/1.1, please send the Network Diagnostics output using the Copy diagnostics button on the same Network settings page, and I’ll take a look at where it’s dropping.
Thanks, that’s exactly what we needed to check. Diagnostics are now clean on both your main network and mobile data, latency looks normal, and both Chat and Agent streams are succeeding. So the path to the servers looks healthy right now.
About the loop, PING timed out shows up when a long-lived streaming connection gets cut somewhere along the network path. This can be intermittent. Short requests, including diagnostics, can succeed while a long Agent stream occasionally drops. Since it’s working on both networks now, it was likely a transient routing issue. If the loop comes back, send the Request ID with Privacy Mode turned off at the moment it drops, and I’ll check where it’s getting dropped.
On the second point, GPT-5.6 Sol being slow and Auto switching to GPT 5.4 Mini Medium is expected behavior in Auto mode. Auto picks an available model and under load it may switch to a faster one so you’re not stuck waiting. If you want a specific model consistently, pick it manually in the model picker, but then you won’t get automatic fallback to a faster model, and under load responses may be slower.
If the HTTP/1.1 loop still happens after a full quit and relaunch, let me know and we’ll dig in further.
Thanks for coming back with details. From the screenshots, I can see both the main model GPT-5.6 Sol Medium and the to-do items on GPT-5.4 Mini Medium / Composer 2.5 Fast, including two tasks that say “Stopped with error”.
Two things:
Model. You’re right, it’s not about Auto. Even when you pick a specific model, the parent agent can still pull a different model when it spawns subagents, based on what’s enabled in Settings > Models. That’s why GPT-5.4 Mini Medium and Composer 2.5 Fast show up in the to-do list. This is a known issue we’re tracking, and there’s no exact timeline yet.
Partial workaround: go to Settings > Models and disable the models you don’t want subagents to use, like GPT-5.4 Mini, Composer 2.5, etc. Disabled models disappear from the list subagents can use in the IDE. One catch: new models are enabled by default, so after updates you should recheck the list. Also, for some subagent types there are preset defaults, and this won’t always override them, so it’s only a partial fix.
Loop. If it still repeats after a full quit + relaunch on HTTP/1.1, I need a fresh Request ID captured right when the disconnect happens, with Privacy Mode turned off. Right now diagnostics look clean on both networks, so we can only catch the failure from a specific live stream drop. With that ID, I can check where the connection breaks. Also, those two “Stopped with error” tasks are probably the same thing, the subagent stream drops when the connection drops.
[composer] Error in AI response: undefined RetriableError: Connection failed repeatedly
at BIg (workbench.desktop.main.js:7190:14063)
at Object.classify (workbench.desktop.main.js:7190:17450)
at MIg (workbench.desktop.main.js:7190:5856)
at async QBs.run (workbench.desktop.main.js:7190:16802)
at async Goe.runAgentLoop (workbench.desktop.main.js:7329:34561)
at async Gpo.streamFromAgentBackend (workbench.desktop.main.js:15007:14762)
at async Gpo.getAgentStreamResponse (workbench.desktop.main.js:15007:32107)
at async BTe._submitChatMaybeAbortCurrent (workbench.desktop.main.js:7296:2568)
at async BTe.submitChatMaybeAbortCurrent (workbench.desktop.main.js:7287:72977)
at async Lc (workbench.desktop.main.js:14101:90285)Caused by: ConnectError: [aborted] aborted
at p9i.$endAiConnectTransportReportError (workbench.desktop.main.js:11828:506863)
at ik._doInvokeHandler (workbench.desktop.main.js:14911:59119)
at ik._invokeHandler (workbench.desktop.main.js:14911:58861)
at ik._receiveRequest (workbench.desktop.main.js:14911:55624)
at ik._dispatchOneMessage (workbench.desktop.main.js:14911:52299)
at ik._receiveOneMessage (workbench.desktop.main.js:14911:51831)
at ik._onIncomingMessage (workbench.desktop.main.js:14911:50836)
at cJt.value (workbench.desktop.main.js:14911:41935)
at de._deliver (workbench.desktop.main.js:55:2962)
at de.fire (workbench.desktop.main.js:55:3283)
at u3t.fire (workbench.desktop.main.js:11801:10751)
at MessagePort.<anonymous> (workbench.desktop.main.js:16908:26414)
[composer] Error in AI response RetriableError: Connection failed repeatedly
at BIg (workbench.desktop.main.js:7190:14063)
at Object.classify (workbench.desktop.main.js:7190:17450)
at MIg (workbench.desktop.main.js:7190:5856)
at async QBs.run (workbench.desktop.main.js:7190:16802)
at async Goe.runAgentLoop (workbench.desktop.main.js:7329:34561)
at async Gpo.streamFromAgentBackend (workbench.desktop.main.js:15007:14762)
at async Gpo.getAgentStreamResponse (workbench.desktop.main.js:15007:32107)
at async BTe._submitChatMaybeAbortCurrent (workbench.desktop.main.js:7296:2568)
at async BTe.submitChatMaybeAbortCurrent (workbench.desktop.main.js:7287:72977)
at async Lc (workbench.desktop.main.js:14101:90285)Caused by: ConnectError: [aborted] aborted
at p9i.$endAiConnectTransportReportError (workbench.desktop.main.js:11828:506863)
at ik._doInvokeHandler (workbench.desktop.main.js:14911:59119)
at ik._invokeHandler (workbench.desktop.main.js:14911:58861)
at ik._receiveRequest (workbench.desktop.main.js:14911:55624)
at ik._dispatchOneMessage (workbench.desktop.main.js:14911:52299)
at ik._receiveOneMessage (workbench.desktop.main.js:14911:51831)
at ik._onIncomingMessage (workbench.desktop.main.js:14911:50836)
at cJt.value (workbench.desktop.main.js:14911:41935)
at de._deliver (workbench.desktop.main.js:55:2962)
at de.fire (workbench.desktop.main.js:55:3283)
at u3t.fire (workbench.desktop.main.js:11801:10751)
at MessagePort.<anonymous> (workbench.desktop.main.js:16908:26414) Object
error @ workbench.desktop.main.js:14918
Request ID: e892fa17-cbbe-4d04-ab7b-5cd095f30d2c
Connection failed repeatedly
RetriableError: Connection failed repeatedly
at sRg (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:7210:14063)
at Object.classify (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:7210:17450)
at XDg (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:7210:5856)
at async m4s.run (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:7210:16802)
at async Yoe.runAgentLoop (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:7349:34561)
at async mmo.streamFromAgentBackend (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:15027:14762)
at async mmo.getAgentStreamResponse (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:15027:32107)
at async zTe._submitChatMaybeAbortCurrent (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:7316:2568)
at async zTe.submitChatMaybeAbortCurrent (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:7307:73029)
at async Object.Lc [as onSubmit] (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:14121:90285)
at async Rt (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:12016:114740)
at async vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:12016:116252
Thanks for the fresh Request IDs, that’s exactly what we need to catch the disconnect.
What the diagnostics show: the connection drops right in the middle of a long-lived stream. The client retries 10 times to reconnect (transportErrorRetries: 10, attempt: 10), then gives up, which is why you see Connection failed repeatedly and [aborted] aborted. Even on HTTP/1.1, this usually means something on the network path to our servers is cutting off long streaming connections. Short requests (including Network Diagnostics) still succeed, so diagnostics can look green while the Agent keeps disconnecting.
To narrow down where it’s breaking, a few questions:
When the loop happens, does it fail on all networks or only your main one? Earlier your mobile hotspot was stable (your previous post). Please test again on mobile data right when the main network is looping. If mobile is stable, the issue is likely your main network path or ISP.
Is there any VPN, proxy, or corporate firewall between you and the internet? If yes, please make sure the allowlist includes *.cursor.sh, *.cursor.com, *.cursorapi.com, *.cursor-cdn.com, and that it isn’t cutting off long streaming connections.
What region and ISP are you connecting from? Longer RTT paths tend to make streams more unstable, and this helps with debugging.
This shouldn’t be happening, and it’s not something in your settings or account. It’s a network path issue we’re tracking, but we don’t have an exact ETA yet. Once you have answers, especially the mobile test result while the loop is active, send them over and I’ll pass it along.
some workspaces are working well. but other are showing this issue. and i was waiting for response even now on three different networks: work, mobile data and home. and for almost all my workspaces i am using the same skills and mcp
Hey, thanks for the details and especially for the DNS log. It clears up a lot.
In the screenshot, api2direct.cursor.sh resolves via AAAA (IPv6) to fd00::eb83:1380:4409:c7f7. That’s a private, non-routable local IPv6 address (ULA range). So your DNS is returning an address for one of our endpoints that can’t be reached from the internet.
That’s most likely what’s causing the loop. The agent’s long-lived stream tries to connect over IPv6 to that non-routable address, hangs, and after a while you get PING timed out → 10 retries → Connection failed repeatedly / [aborted]. Short requests (including Network Diagnostics) fall back to IPv4 and succeed, so diagnostics looks green while the agent still drops. This also explains why it happens on all three networks. The rule is at the device or DNS level, not tied to a specific network.
From the log it looks like you have a local DNS filter enabled, probably AdGuard Home or a router with filtering. Can you check:
Whether there’s any rewrite, block, or custom record for *.cursor.sh or specifically api2direct.cursor.sh that maps the domain to a local address. If yes, remove it and add these to your allowlist: *.cursor.sh, *.cursor.com, *.cursorapi.com, *.cursor-cdn.com.
For a quick test, temporarily switch your machine to a public DNS like 1.1.1.1 or 8.8.8.8, bypassing the local filter, and test again.
As an alternative test, disable IPv6 to force IPv4 and see if the loop stops.
If the loop still happens after clean DNS or IPv4-only, send a fresh Request ID right when it disconnects with Privacy Mode turned off, and I’ll check where it’s failing.
About sometimes it starts working when you open the agents window, that also fits this. Some connections end up taking the working path. So it makes sense to sort out DNS first.
relative long time i didn’t had any issues but now:
c5e16bfb-89eb-4158-83b0-ae976b2ac8ed
6b17f5ee-d5be-471e-9a0a-29631d9f3b16
Request ID: 6b17f5ee-d5be-471e-9a0a-29631d9f3b16
{"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":true,"additionalInfo":{"providerStatusCode":"503"},"buttons":[],"planChoices":[]},"isExpected":true}
[resource_exhausted] Error
RetriableError: [resource_exhausted] Error
at nkf (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:8031:131678)
at lqs (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:8031:130104)
at Ekf (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:8032:13645)
at Object.classify (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:8032:17843)
at _kf (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:8032:5924)
at async Sqs.run (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:8032:17165)
at async vce.runAgentLoop (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:8132:34413)
at async rRo.streamFromAgentBackend (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:17489:17224)
at async rRo.getAgentStreamResponse (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:17489:36143)
at async YIe._submitChatMaybeAbortCurrent (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:8110:4529)
at async YIe.submitChatMaybeAbortCurrent (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:8105:67958)
at async Object.hi [as onSubmit] (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:14170:93636)
at async At (vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:12067:130056)
at async vscode-file://vscode-app/usr/share/cursor/resources/app/out/vs/workbench/workbench.desktop.main.js:12067:131722
