Agent Execution Does Not Reflect Real-Time Updates in IDE

Describe the Bug

During agent execution in Cursor, there are cases where file modifications or other operations are not reflected in the IDE in real time.

This includes actions such as thinking steps, file edits, and other intermediate processes.

All updates only become visible after the task has been completed, rather than being displayed progressively during execution.

Steps to Reproduce

I don’t know

Operating System

Windows 10/11

Version Information

Version: 3.0.13 (user setup)
VSCode Version: 1.105.1
Commit: 48a15759f53cd5fc9b5c20936ad7d79847d914b0
Date: 2026-04-07T03:05:17.114Z
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: Windows_NT x64 10.0.26200

Does this stop you from using Cursor

No - Cursor works, but with this issue

Hi Yuhan!

Thanks for the report. To help investigate, I have a few questions:

  1. Could you share a Request ID from a session where this happened? You can find it by clicking the three dots at the top right of the chat and selecting “Copy Request ID.” How to find your Request ID

  2. When you say “all updates only become visible after the task has been completed,” does that include the chat panel itself (thinking text, tool calls, file edit previews)? Or is it more that the editor/terminal don’t reflect changes until the agent finishes?

  3. Does this happen every time you run the agent, or only with certain types of tasks (e.g., tasks involving many file edits, terminal commands, etc.)?

  4. Which model are you using when this happens?

  5. Could you try switching to the Agents Window layout (Cmd+Shift+P or Ctrl+Shift+P, then search “Agents Window”) and see if the issue persists?

That last point may also serve as a workaround while we investigate further.

  1. 1b22d2ee-cdb2-46e7-8e2b-84a9e3e7e4ee
  2. I’m using the chat panel in my IDE. I expect it to display the process when I’m thinking, making decisions, writing documents, or doing other things, but it doesn’t show anything until the next action, and it shows that the thinking took longer than expected.
  3. This problem occurs intermittently, but currently it appears to happen about 80% of the time, involving multiple factors such as thought processes, document editing, enabling subagents, and running agent terminals.
  4. This issue seems less likely to occur with any model, including Codex 5.3 High and Opus 4.6 High Thinking, but when assigning shorter tasks to the model (such as the Composer 2 Fast model).
  5. This problem can occur even when using the agent window; it often gets stuck on the “Planning the next move” screen, but in reality, many operations are changing (such as modifying files or running the subagent).

Thanks for the detailed answers. This is very helpful.

Based on your description, this is the “Taking longer than expected” streaming stall that we’ve been tracking. The “Planning the next move” screen you’re seeing is the same state — it switches to “Taking longer than expected” after about 15 seconds. The fact that operations are actually proceeding in the background (file edits, subagents) while the UI appears stuck confirms this.

Regarding the Request ID you shared (1b22d2ee-cdb2-46e7-8e2b-84a9e3e7e4ee): I wasn’t able to find it in our backend logs, which suggests the streaming connection may be stalling before the request fully reaches our servers.

A couple of things to try:

  1. Disable HTTP/2 — this has helped other users with similar streaming issues. Add this to your settings.json (Ctrl+Shift+P > Preferences: Open User Settings (JSON)):

"cursor.general.disableHttp2": true

Then restart Cursor.

  1. Run Network Diagnostics — go to Cursor Settings > Network > Run Diagnostics and share the results here (use the “Copy diagnostics” button). This will help us see if there’s a connectivity issue.

After trying the steps above, if the issue persists, could you grab a fresh Request ID from a stuck session and share it here? That would help us trace the specific failure.

62708f9e-9c6b-494c-a65e-120e1b3b4d46
The new one

Version: 3.1.10 (user setup)
VSCode Version: 1.105.1
Commit: dacbe9b31599a253763e4910eb6ab38704653320
Date: 2026-04-13T11:39:16.806Z
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: Windows_NT x64 10.0.26200

After the update, I found that as long as it’s during a conversation (after the AI ​​asks a question),

when I not only select an option but also type text in the text input box below and send it, the “Taking longer than expected” message is immediately triggered,

and all actions are processed in the background.

As you can see from the screenshot above, after I referenced “file:14-16”, “thought for 2s” stopped appearing (although there was actually some thinking), and it jumped directly to the next Asking. However, before that, it did show any expected behavior, thoughts, or text output.

Thanks for the updated info and the screenshot.

The new request ID (62708f9e-...) is also not appearing in our backend logs. This is now the second request ID that’s untraceable, which strongly suggests the issue is with the connection between your client and our servers, not just a UI stall.

Before we dig further, a couple of important questions:

  1. Did you try disabling HTTP/2 as suggested in my previous reply? (Adding "cursor.general.disableHttp2": true to settings.json and restarting.) This is the most important step to try.

  2. Did you run Network Diagnostics? (Cursor Settings > Network > Run Diagnostics, then “Copy diagnostics”.) The results will help us understand if there’s a connectivity issue preventing requests from reaching our servers.

Both of these are critical for diagnosing why your requests aren’t reaching our backend at all. The specific trigger you described (selecting an option + typing text when answering an AI question) is a useful data point that I’ll pass along.

Could you try the HTTP/2 disable if you haven’t already, and share the network diagnostics results here?

92c1a5b1-0dc0-45be-ae7d-6e41d9bd0439

Yes, I have disabled HTTP/2 and am currently making requests using HTTP/1.1.

Cursor Network Diagnostic Results

DNS: Success
Logs:
[2026-04-14T07:56:57.302Z] Host: api2.cursor.sh
[2026-04-14T07:56:57.302Z] Servers: 168.95.1.1,8.8.8.8
[2026-04-14T07:56:57.302Z] Resolved to 52.0.58.168 in 30ms
[2026-04-14T07:56:57.304Z] Resolved to 52.0.58.168 in 1ms
[2026-04-14T07:56:57.304Z] Resolved to 52.0.58.168 in 0ms
[2026-04-14T07:56:57.304Z] Resolved to 52.0.58.168 in 0ms
[2026-04-14T07:56:57.316Z] Host: api2.cursor.sh
[2026-04-14T07:56:57.316Z] Servers: system
[2026-04-14T07:56:57.316Z] Resolved to 3.226.113.83, 100.29.217.106, 54.205.26.79, 100.25.13.90, 34.193.62.243, 18.215.54.33, 52.55.254.140, 98.84.210.115 in 7ms
[2026-04-14T07:56:57.318Z] Resolved to 3.226.113.83, 100.29.217.106, 54.205.26.79, 100.25.13.90, 34.193.62.243, 18.215.54.33, 52.55.254.140, 98.84.210.115 in 1ms
[2026-04-14T07:56:57.320Z] Resolved to 3.226.113.83, 100.29.217.106, 54.205.26.79, 100.25.13.90, 34.193.62.243, 18.215.54.33, 52.55.254.140, 98.84.210.115 in 1ms
[2026-04-14T07:56:57.321Z] Resolved to 3.226.113.83, 100.29.217.106, 54.205.26.79, 100.25.13.90, 34.193.62.243, 18.215.54.33, 52.55.254.140, 98.84.210.115 in 0ms
[2026-04-14T07:56:57.321Z] Result: true

SSL: Success
Logs:
[2026-04-14T07:56:57.271Z] Start
[2026-04-14T07:56:58.031Z] URL: https://api2.cursor.sh/
[2026-04-14T07:56:58.031Z] Status: 200
[2026-04-14T07:56:58.031Z] IP: 52.0.58.168
[2026-04-14T07:56:58.031Z] Issuer: C=US; O=Amazon; CN=Amazon RSA 2048 M01
[2026-04-14T07:56:58.031Z] Name: api2.cursor.sh
[2026-04-14T07:56:58.031Z] AltName: DNS:api2.cursor.sh, DNS:prod.authentication.cursor.sh, DNS:*.api2.cursor.sh
[2026-04-14T07:56:58.031Z] DNS Time: 4ms
[2026-04-14T07:56:58.031Z] Connect Time: 267ms
[2026-04-14T07:56:58.031Z] TLS Time: 243ms
[2026-04-14T07:56:58.031Z] Result: true in 760ms

API: Success
Logs:
[2026-04-14T07:56:57.271Z] Start
[2026-04-14T07:56:58.044Z] Result: true

Ping: Success
Logs:
[2026-04-14T07:56:57.272Z] Sending ping 1
[2026-04-14T07:56:58.159Z] Response: ‘ping’ in 887ms
[2026-04-14T07:56:58.160Z] Sending ping 2
[2026-04-14T07:56:59.005Z] Response: ‘ping’ in 845ms
[2026-04-14T07:56:59.005Z] Sending ping 3
[2026-04-14T07:56:59.941Z] Response: ‘ping’ in 936ms
[2026-04-14T07:56:59.941Z] Sending ping 4
[2026-04-14T07:57:00.916Z] Response: ‘ping’ in 975ms
[2026-04-14T07:57:00.916Z] Sending ping 5
[2026-04-14T07:57:01.756Z] Response: ‘ping’ in 840ms
[2026-04-14T07:57:01.756Z] Result: true

Chat: Success
Logs:
[2026-04-14T07:56:57.272Z] Starting streamSSE
[2026-04-14T07:56:58.166Z] Response: ‘foo’ in 893ms
[2026-04-14T07:56:59.175Z] Response: ‘foo’ in 1009ms
[2026-04-14T07:57:00.186Z] Response: ‘foo’ in 1011ms
[2026-04-14T07:57:01.188Z] Response: ‘foo’ in 1002ms
[2026-04-14T07:57:02.202Z] Response: ‘foo’ in 1014ms
[2026-04-14T07:57:03.171Z] Result: true

Agent: Success
Logs:
[2026-04-14T07:56:57.272Z] Starting stream
[2026-04-14T07:56:57.273Z] Pushing first message
[2026-04-14T07:56:58.357Z] Response: ‘foo’ in 1084ms
[2026-04-14T07:56:58.859Z] Pushing next message
[2026-04-14T07:56:59.764Z] Response: ‘foo’ in 1407ms
[2026-04-14T07:57:00.269Z] Pushing next message
[2026-04-14T07:57:01.169Z] Response: ‘foo’ in 1405ms
[2026-04-14T07:57:01.671Z] Pushing next message
[2026-04-14T07:57:02.674Z] Response: ‘foo’ in 1505ms
[2026-04-14T07:57:03.178Z] Pushing next message
[2026-04-14T07:57:04.067Z] Response: ‘foo’ in 1393ms
[2026-04-14T07:57:04.067Z] Result: true

Marketplace: Success
Logs:
[2026-04-14T07:56:57.268Z] Host: marketplace.cursorapi.com
[2026-04-14T07:56:57.538Z] Response in 270ms
[2026-04-14T07:56:57.538Z] Response: 200
[2026-04-14T07:56:57.538Z] Response Type: cors
[2026-04-14T07:56:57.538Z] Server: null
[2026-04-14T07:56:57.538Z] Result: OK in 270ms

Authentication: Success
Logs:
[2026-04-14T07:56:57.269Z] Host: prod.authentication.cursor.sh
[2026-04-14T07:56:58.036Z] Response: 200 in 767ms

Authentication UI: Success
Logs:
[2026-04-14T07:56:57.271Z] DNS lookup: authenticator.cursor.sh
[2026-04-14T07:56:57.303Z] Resolved authenticator.cursor.sh to 104.18.35.233 in 25ms

Cursor Tab: Success
Logs:
[2026-04-14T07:56:57.271Z] DNS lookup: api3.cursor.sh
[2026-04-14T07:56:57.302Z] Resolved api3.cursor.sh to 104.18.19.125 in 25ms

Agent Endpoint: Success
Logs:
[2026-04-14T07:56:57.271Z] DNS lookup: agent.api5.cursor.sh
[2026-04-14T07:56:57.303Z] Resolved agent.api5.cursor.sh to 50.18.248.73 in 25ms

Codebase Indexing: Success
Logs:
[2026-04-14T07:56:57.271Z] DNS lookup: repo42.cursor.sh
[2026-04-14T07:56:57.303Z] Resolved repo42.cursor.sh to 34.230.193.156 in 26ms

Downloads: Success
Logs:
[2026-04-14T07:56:57.271Z] Host: downloads.cursor.com
[2026-04-14T07:56:57.528Z] Response: 403 in 257ms

CDN: Success
Logs:
[2026-04-14T07:56:57.271Z] Host: cursor-cdn.com
[2026-04-14T07:56:57.518Z] Response: 404 in 246ms

I tested the dialogue for this situation, and the following is a recording:

It includes:

  1. Answering using only the options

  2. Answering using only the options and entering text in the “Other” option (keeping the text input box blank)

  3. Answering using the options and adding additional information through the text input box.

The following is the ID of this request: 5839d777-ae3e-4b23-b27c-c806ac28318e

Thanks for the video and diagnostics — this is exactly the kind of evidence we need.

Good news first: with HTTP/2 disabled, your latest request is now visible in our backend logs, and the network diagnostics look clean. So the connection is working.

I watched the recording and can confirm the pattern you described. When you answer the agent’s questions using only the option buttons, everything streams normally. But when you type text in the input box while also responding to the question options, the streaming stalls immediately and shows “Planning next moves” until everything catches up at once.

This is a client-side bug in the Asking UI’s handling of combined input (option selection + typed text). I’ve added your video evidence and backend data to the tracking issue for our team.

Thanks for being so thorough with the testing — this makes it much easier for our team to reproduce and fix.