RetriableError: [canceled] http/2 stream closed CANCEL (0x8)` mid long agent turn (Grok 4.5)

Support Bug Reports
, ,
1

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

Long agent turns intermittently fail with:

Error: RetriableError: [canceled] http/2 stream closed with error code CANCEL (0x8)

Seen twice. Turn runs ~15–20 minutes, then the HTTP/2 stream is canceled and the agent stops. Partial file changes from before the drop remain. Looks like a transport cancel between the local agent runtime and Cursor backend, not a model refusal.

Steps to Reproduce

  1. Open a Cursor agent session (here via T3 Code on a local Mac mini checkout).
  2. Select model: Cursor Grok 4.5 (High / Full access / Build).
  3. Start a multi-step agent task that runs for ~15–20+ minutes.
  4. Wait until the turn ends with RetriableError: [canceled] http/2 stream closed with error code CANCEL (0x8).

Reproduced twice on similar long turns. Not every short turn fails.

Expected Behavior

The agent turn should complete, or Cursor should retry/resume the stream without ending the turn on CANCEL (0x8).

Operating System

MacOS

Version Information

IDE: Cursor 3.14.7 (a758f2241ca99fecf380180b6cbdbbce0f1f42c0)
CLI / agent: cursor-agent 2026.07.23-e383d2b
Hosted via: T3 Code (app.t3.codes) → local Cursor Grok agent lane on Mac mini

For AI issues: which model did you use?

Cursor Grok 4.5 (High)

Additional Information

  • Error surfaces in T3 Code UI, but the RetriableError / HTTP/2 CANCEL shape matches Cursor agent transport failures reported on the forum (stream drop mid-request).
  • Happens after long runtimes (~18m in one case), so idle/proxy timeout is possible.
  • Partial progress survived (example: 2 files changed, +8/-0) before the stream died.
  • Happy to attach Network Diagnostics output if useful.

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey, thanks for the detailed report. Your diagnosis is correct: http/2 stream closed CANCEL (0x8) is a transport-level stream drop between your machine and the Cursor backend, not a model refusal. Partial progress is checkpointed, so work isn’t lost.

What to try:

  1. Continue the session with resume. After the drop, run cursor-agent --resume. It’ll pick up from the last checkpoint without restarting the turn.

  2. Update the CLI: cursor-agent update. You’re on a July 23 build, newer builds have improvements for handling transient stream drops.

  3. Test directly, without T3 Code. You’re running the agent through a third-party wrapper app.t3.codes, which adds an extra network hop. On long HTTP/2 streams around 18 minutes, that can introduce idle or proxy timeouts. Run the same long task directly via cursor-agent on the same Mac mini. If it doesn’t drop directly, the wrapper path is likely the issue.

  4. Try HTTP/1.1 for the agent as a workaround on long turns. It sometimes helps when HTTP/2 gets CANCELed behind a proxy. In the CLI network config, set "network": { "useHttp1ForAgent": true } and see if the drop still happens.

If the problem still happens after updating and running directly without T3 Code, please share a Request ID from one of the failed turns and the Network Diagnostics output. That’ll help us dig deeper. Let me know how it goes.