Planning next moves / Taking longer than expected

Support Bug Reports
1

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

See it reported elsewhere, don’t know what to do.

Also submitting this “An error occurred: Sorry, new users can only put 2 links in a post.” ???

Switched from auto > any specific model. Forked the chat and did the same thing.

Agent + Ping never get a check

Cursor Network Diagnostic Results

(I would paste but getting flagged for spam)

Steps to Reproduce

Prompt the agent

Expected Behavior

Literally anything

Operating System

MacOS

Version Information

Version: 3.8.11 (Universal)
VS Code Extension API: 1.105.1
Commit: e56ad3440df06d22ca7501e65fd518e905486ef0
Date: 2026-06-18T01:40:18.333Z
Layout: glass
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Darwin arm64 25.3.0

For AI issues: which model did you use?

Auto / Sonnet / Opus

Does this stop you from using Cursor

Yes - Cursor is unusable

3

DNS: Success
Logs:
[2026-06-22T01:16:59.397Z] Host: api2. (dot) cursor. (dot) sh
[2026-06-22T01:16:59.397Z] Servers: 192.168.1.1
[2026-06-22T01:16:59.397Z] Resolved to 54.243.190.140 in 5ms
[2026-06-22T01:16:59.443Z] Resolved to 54.243.190.140 in 39ms
[2026-06-22T01:16:59.447Z] Resolved to 54.243.190.140 in 3ms
[2026-06-22T01:16:59.450Z] Resolved to 54.243.190.140 in 3ms
[2026-06-22T01:16:59.457Z] Host: api2.cursor.sh
[2026-06-22T01:16:59.457Z] Servers: system
[2026-06-22T01:16:59.457Z] Resolved to 54.243.190.140, 98.88.51.138, 50.19.84.132, 32.195.94.120, 18.211.76.31, 3.211.252.55, 52.71.161.101, 34.226.76.92 in 3ms
[2026-06-22T01:16:59.458Z] Resolved to 54.243.190.140, 98.88.51.138, 50.19.84.132, 32.195.94.120, 18.211.76.31, 3.211.252.55, 52.71.161.101, 34.226.76.92 in 0ms
[2026-06-22T01:16:59.458Z] Resolved to 54.243.190.140, 98.88.51.138, 50.19.84.132, 32.195.94.120, 18.211.76.31, 3.211.252.55, 52.71.161.101, 34.226.76.92 in 0ms
[2026-06-22T01:16:59.459Z] Resolved to 54.243.190.140, 98.88.51.138, 50.19.84.132, 32.195.94.120, 18.211.76.31, 3.211.252.55, 52.71.161.101, 34.226.76.92 in 0ms
[2026-06-22T01:16:59.459Z] Result: true

HTTP/2: Success
Logs:
[2026-06-22T01:16:59.383Z] Start
[2026-06-22T01:16:59.426Z] Host: api2.cursor.sh
[2026-06-22T01:16:59.426Z] Protocol: h2
[2026-06-22T01:16:59.426Z] Result: true in 43ms

SSL: Success
Logs:
[2026-06-22T01:16:59.383Z] Start
[2026-06-22T01:16:59.580Z] URL: https://api (dot) .cursor. (dot) sh/
[2026-06-22T01:16:59.580Z] Status: 200
[2026-06-22T01:16:59.580Z] IP: 54.243.190.140
[2026-06-22T01:16:59.580Z] Issuer: C=US; O=Amazon; CN=Amazon RSA 2048 M01
[2026-06-22T01:16:59.580Z] Name: api2.cursor.sh
[2026-06-22T01:16:59.580Z] AltName: DNS:api2.cursor. (dot) sh, DNS:prod.authentication.cursor. (dot) sh, DNS:*.api2.cursor. (dot) sh
[2026-06-22T01:16:59.580Z] DNS Time: 22ms
[2026-06-22T01:16:59.580Z] Connect Time: 133ms
[2026-06-22T01:16:59.580Z] TLS Time: 19ms
[2026-06-22T01:16:59.580Z] Result: true in 197ms

API: Success
Logs:
[2026-06-22T01:16:59.383Z] Start
[2026-06-22T01:16:59.565Z] Result: true

Ping: Running
Logs:
[2026-06-22T01:16:59.384Z] Sending ping 1
[2026-06-22T01:16:59.563Z] Response: ‘ping’ in 179ms
[2026-06-22T01:16:59.563Z] Sending ping 2
[2026-06-22T01:16:59.589Z] Response: ‘ping’ in 26ms
[2026-06-22T01:16:59.589Z] Sending ping 3
[2026-06-22T01:16:59.621Z] Response: ‘ping’ in 32ms
[2026-06-22T01:16:59.621Z] Sending ping 4
[2026-06-22T01:16:59.652Z] Response: ‘ping’ in 31ms
[2026-06-22T01:16:59.652Z] Sending ping 5

Chat: Success
Logs:
[2026-06-22T01:16:59.384Z] Starting stream
[2026-06-22T01:16:59.443Z] Response: ‘foo’ in 58ms
[2026-06-22T01:17:00.456Z] Response: ‘foo’ in 1013ms
[2026-06-22T01:17:01.446Z] Response: ‘foo’ in 990ms
[2026-06-22T01:17:02.446Z] Response: ‘foo’ in 1000ms
[2026-06-22T01:17:03.507Z] Response: ‘foo’ in 1060ms
[2026-06-22T01:17:04.441Z] Result: true

Agent: Running
Logs:
[2026-06-22T01:16:59.385Z] Starting stream
[2026-06-22T01:16:59.385Z] Pushing first message

Marketplace: Success
Logs:
[2026-06-22T01:16:59.380Z] Host: marketplace.cursorapi. (dot) com
[2026-06-22T01:16:59.446Z] Response in 66ms
[2026-06-22T01:16:59.446Z] Response: 200
[2026-06-22T01:16:59.446Z] Response Type: cors
[2026-06-22T01:16:59.446Z] Server: null
[2026-06-22T01:16:59.446Z] Result: OK in 66ms

Authentication: Success
Logs:
[2026-06-22T01:16:59.381Z] Host: prod.authentication.cursor.sh
[2026-06-22T01:16:59.540Z] Response: 200 in 159ms

Authentication UI: Success
Logs:
[2026-06-22T01:16:59.383Z] DNS lookup: authenticator.cursor.sh
[2026-06-22T01:16:59.407Z] Resolved authenticator.cursor.sh to 172.64.152.23 in 20ms

Cursor Tab: Success
Logs:
[2026-06-22T01:16:59.383Z] DNS lookup: api3.cursor.sh
[2026-06-22T01:16:59.406Z] Resolved api3.cursor.sh to 104.18.18.125 in 20ms

Agent Endpoint: Success
Logs:
[2026-06-22T01:16:59.383Z] DNS lookup: agent.api5.cursor. (dot) sh
[2026-06-22T01:16:59.604Z] Resolved agent.api5.cursor. (dot) sh to 44.197.141.31 in 218ms

Codebase Indexing: Success
Logs:
[2026-06-22T01:16:59.383Z] DNS lookup: repo42.cursor. (dot) sh
[2026-06-22T01:16:59.442Z] Resolved repo42.cursor. (dot) sh to 52.7.224.202 in 47ms

Downloads: Success
Logs:
[2026-06-22T01:16:59.382Z] Host: downloads.cursor. (dot) com
[2026-06-22T01:16:59.540Z] Response: 403 in 158ms

CDN: Success
Logs:
[2026-06-22T01:16:59.383Z] Host: cursor-cdn. (dot) com
[2026-06-22T01:16:59.557Z] Response: 404 in 174ms

5

hi @jpg, something you can try right now would be to lower the http version to either 1.1 or 1.0, I know in the logs it was shown that no issue where found with the http2.0, but since you saw some taking longer thing.. switching could actually help, you can do it in the settings > Network > http version

8

Hey, based on your diagnostics it’s pretty clear: Chat = success, but Agent gets stuck on Starting stream → Pushing first message with no replies. Agent uses bidirectional HTTP/2 streaming, and when normal streaming Chat works but Agent hangs, it’s almost always a proxy, VPN, or security tool on the network path that buffers or breaks full-duplex connections. That’s why switching models and forking the chat didn’t help. This is a transport-level issue, not a model issue.

What to try:

  1. Settings → Network → enable Disable HTTP/2 (this switches to HTTP/1.1). After that, fully quit and reopen Cursor, not Reload Window, but actually quit and start it again.
  2. Temporarily disable anything that touches the network like VPN, Little Snitch, Zscaler, corporate MDM, or antivirus, then test again. This is the classic reason chat works but agent hangs.

Tom_Coustols above is also right about lowering the HTTP version, it’s the same thing.

More details for this case are in this thread: My chats are just hanging with "Planning next moves" and "Taking longer than expected..."

About new users can only put 2 links, that’s a forum limit on link count for new accounts and not related to the bug. It’ll go away as your trust level increases.

Let me know if disabling HTTP/2 helped.

9

Thanks both, but lowering the HTTP did not resolve.

Also followed further instructions on the linked thread, disabled third-party Plugins, Skills, and other configs… still “Taking longer than expected…”

I’m stuck against a deadline, where’s 1:1 support?

10

Request ID: 50c61abe-97e1-45df-9817-cea8677a170a
{“error”:“ERROR_TIMEOUT”,“details”:{“title”:“Request timed out.”,“detail”:“Timeout waiting for next item.”,“additionalInfo”:{},“buttons”:,“planChoices”:},“isExpected”:true}
Timeout waiting for next item.
[deadline_exceeded] Error
RetriableError: [deadline_exceeded] Error
at zCE (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.glass.main.js:11938:27797)
at cNh (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.glass.main.js:11938:26526)
at g5S (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.glass.main.js:11939:11430)
at Object.classify (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.glass.main.js:11939:15949)
at KCE (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.glass.main.js:11939:5709)
at async iWg.runWithSharedTurnRunner (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.glass.main.js:11939:15300)
at async gue.runAgentLoop (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.glass.main.js:21292:3043)
at async eLv.streamFromAgentBackend (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.glass.main.js:24470:13921)
at async eLv.getAgentStreamResponse (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.glass.main.js:24470:22774)
at async Fpt.submitChatMaybeAbortCurrent (vscode-file://vscode-app/Applications/Cursor.app/Contents/Resources/app/out/vs/workbench/workbench.glass.main.js:12056:1967)

Cursor agent says:

This is a Cursor agent request timeout error. Here’s what each part means:

What happened: The Cursor backend was streaming a response to you, but the connection timed out before the next chunk of data arrived. Specifically:

  • ERROR_TIMEOUT / deadline_exceeded — the server exceeded a time limit waiting to send the next piece of the response stream
  • "Timeout waiting for next item" — the streaming pipeline stalled mid-response; Cursor was waiting for the next token/chunk but it never came in time
  • RetriableError — Cursor classifies this as retryable, meaning it’s transient (not a permanent failure)

Why it happens:

  • The AI model took too long to generate the next token (common with large contexts or complex tasks)
  • A temporary backend/network hiccup between Cursor’s servers and the model provider
  • High server load on Cursor’s infrastructure

What to do:

  1. Just retry — since it’s marked RetriableError, simply resend the message. It usually works on the next attempt.
  2. If it keeps happening, try reducing context size (close irrelevant files, shorten your prompt).
  3. Check status.cursor.com if retries consistently fail — it may be a broader outage.

It’s not a bug in your code or project — it’s purely a server-side timeout on Cursor’s end.

11

I keep having to fork the conversation to prevent hanging; each fork can only handle one prompt; attachments seem to cause it to hang no matter what.

image
image1340×1312 176 KB

12

Thanks for sending the Request ID and the video. I can see in the screenshot that you’re in the Agents Window, and you’re forking “Project context inquiry” in a loop to work around the hangs. That’s really disruptive, especially close to a deadline.

Since HTTP/2 (and downgrading the HTTP version), and also disabling Plugins/Skills didn’t help, it means the cause is probably not in the transport layer like we first thought. For your Request ID 50c61abe-97e1-45df-9817-cea8677a170a, the error is deadline_exceeded / “Timeout waiting for next item”. The stream is not getting the next chunk from the backend in time. It’s marked as retriable.

The most important clue is what you said about attachments. Let’s isolate the trigger:

  1. Open a completely new chat (not a fork), pick a specific model (for example Sonnet), and send a short prompt with no attachments at all, like “say hello”. Does it complete?
  2. If yes, in the next clean chat add one image with the same short prompt. Does it hang?

If it’s stable without attachments but hangs with an attachment, that narrows it down a lot, and I can pass it to the engineers with your Request ID and clear steps. Please also send a couple more Request IDs from the requests that hung specifically when there was an attachment (Chat menu in the top right > Copy Request ID).

About 1:1 support: there isn’t a dedicated personal channel on Pro. The forum and [email protected] are the support path, and I’m helping you here. Let me know the test results above and we’ll go from there.

13

New chat said “hello” back and could see the image attached.

Attaching request IDs

60648d82-63f0-448c-81eb-7255a54a01e9

45377483-4a03-442a-8b36-9661d6cf9181

b3a583da-1b3a-4cb4-a1a6-2b57b215b07e

40a1395d-3c9b-4e88-948e-019536bd233a

7e0e28e3-2244-4906-9cc1-474419024f55

abe5f06a-bc3c-4662-b4fd-20f8513c17c5

14

Thanks for the test and the Request ID. The fact that a clean new chat with an image plus “say hello” worked fine is a useful signal. It means the attachment itself isn’t breaking in a fresh thread. So the trigger is likely not the image, but the state or size of a specific thread (long and forked chats).

For Request ID 50c61abe-..., the error was deadline_exceeded / “Timeout waiting for next item”. The stream didn’t receive the next chunk in time and failed. It’s marked as retriable, so it’s transient and not tied to the model or the content.

What you can do right now so you don’t keep hitting the deadline:

  1. Don’t fork the problematic chat, start a new one. A fork carries over all the thread state, and if it’s stuck, the new turn can hang again. Your fresh chat working matches this.
  2. Move context via paste. Open a new chat and paste a short summary from the old one: what’s done, what’s left, key decisions. This gives the agent what it needs without the stuck fork state and without extra volume. If you really need the old thread, there’s @Past Chats, but it pulls the full history back in, so for avoiding hangs a short pasted summary is usually more stable.
  3. Keep context small. Use a specific model (like Sonnet), attach fewer files and images at once, and keep the prompt shorter. Bigger context increases the chance of hitting a deadline.

To pin down the root cause, one quick test: open a fresh chat, pick a specific model, attach the same image that used to hang, but give it a real task instead of “say hello”. Does it hang or not? Also, can you confirm if the hangs only happen in long and forked threads, or do you see them in fresh chats too?