[Bug]: Getting error during cursor runs, RetriableError: [canceled] http/2 stream closed with error code CANCEL (0x8) #12374

Activity

1. aashishsingla567

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Sep 18, 2026
2. juliusmarminge commented on Sep 18, 2026

   

   juliusmarminge

   on Sep 18, 2026

   Member

   More actions

   Triage

   Verdict: Valid bug. Keep open.
   Not a duplicate of #7830. That issue was Cursor leaking transport dumps as assistant text and T3 marking the turn completed. #10337 already fails those turns. This report is the leftover: the run still dies mid-work and the user has to Continue.
   Not a duplicate of #10480. That one is RetriableError: [internal] Failed to run step, exceeded max retries (agent-loop). #11365 stopped labeling that class as a transport failure. This diagnostic is [canceled] http/2 stream closed … CANCEL (0x8), which is the transport class.
   Not already fixed on current main (53510d44e) or on the reporter’s 0.0.42 (719a76ca1). Same fail-the-turn path, no retry, no session recycle.

   Same reporter already left this exact string on #10480 a few minutes before filing this.

   Area on the form is wrong: this is the Cursor ACP adapter (apps/server), not apps/web. The web client is only showing the failed turn.

   What happens

   1. Cursor ACP finishes session/prompt with a normal end_turn, but the assistant text is only a transport dump:

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

   HTTP/2 CANCEL (0x8) is a stream reset on a long-lived Cursor backend request. Cursor’s interactive agent retries these internally. ACP leaks them as agent_message_chunk plus a successful prompt result. Cursor has acknowledged that error-channel leak (forum). #7830 already listed HTTP/2 CANCEL / stream-reset as part of this class.

   2. T3’s matcher treats a standalone Error: RetriableError: … that is not [internal] as a transport failure. This string matches:

   const maxLineLength = 4096;
   // Cursor also uses RetriableError for agent-loop failures; preserve those diagnostics.
   const transportError =
     /^Error: (?:RetriableError: (?!\[internal\]).+|ConnectError: \[(?:unavailable|aborted|deadline_exceeded)\].*)$/;

   3. After draining ACP events, sendTurn fails the turn. It does not retry and does not drop the session:

             yield* ctx.acp.drainEvents;
             const failure = ctx.assistantReply.failure;
             if (ctx.promptsInFlight === 1 && result.stopReason !== "cancelled" && failure) {
               return yield* new ProviderAdapterRequestError({
                 provider: PROVIDER,
                 method: "session/prompt",
                 detail: "Cursor reported a transport failure.",
                 cause: failure,
               });
             }

   That is why the user sees a hard stop instead of a fake completed answer, and why Continue works for a while: the next prompt often succeeds until the next cancel. On a long run that already used tools, this is the expected current behavior, not a missed matcher.

   Related (do not close as these)

   Item	Why it does not close this
   #7830 (closed)	Fail-the-turn only. Retry was explicitly left out of #10337
   #10480 (open)	[internal] max-retries, not HTTP/2 CANCEL
   #10337 (merged)	Detection + Failed status. Shipped in 0.0.42
   #11365 (merged)	Carve-out for [internal] only
   #11225 (open, conflicting)	Bounded retry when the failed attempt did no work. A long run that already ran tools still stops
   #12337 (open)	Recycles the ACP session after this exact diagnostic so Continue is a fresh session/load. Still no replay

   Suggested fix

   Do not replay a long run that already used tools. #10337 was right to refuse that.

   Two stacked workarounds, neither of which is on main yet:

   1. Land the session recycle in fix(server): recycle Cursor sessions after transport failures #12337 so Continue does not reuse a dead HTTP/2 transport. That matches the reporter’s current workaround and uses this exact CANCEL (0x8) string in the regression test.
   2. Keep fix(cursor): retry prompts that only returned a transport failure #11225 (or a rebased follow-up) for the no-work case only: first-prompt / pre-tool blips. It will not satisfy “agent keeps running until work is done” on a long run that already called tools.

   A later “auto-Continue after recycle” (new turn, not a replay of the original prompt) is the piece that would match the expected behavior for mid-run cancels after tools. That is not in either open PR. Do not buffer-and-hide the leaked diagnostic; leave it visible.

   Root cause stays upstream: Cursor ACP should return these as JSON-RPC errors, not assistant text.

   Labels: bug upstream (remove needs-triage)
3. juliusmarminge

   added

   upstream

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   and removed

   needs-triageIssue needs maintainer review and initial categorization.Issue needs maintainer review and initial categorization.

   on Sep 18, 2026
4. gbgelado commented on Sep 23, 2026

   

   gbgelado

   on Sep 23, 2026

   More actions

   Additional report from macOS arm64, T3 Code 0.0.42 (719a76ca1dbf), using Cursor Agent 2026.09.18-9a7762b.

   Cursor consistently fails during longer runs and does not complete the task. The observed error is:

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

   T3 then reports:

   ProviderAdapterRequestError: Provider adapter request failed (cursor) for session/prompt: Cursor reported a transport failure.
   

   The failure occurs after Cursor has already executed tools. Continuing the thread allows the work to resume temporarily, but the same failure can recur. The run involved an iOS Simulator build; the assistant output immediately before the transport error mentioned a separate Keychain entitlement failure caused by an unsigned Simulator build.

   The T3 server was running locally and cursor-agent was available on PATH. The Cursor ACP integration was configured with the default cursor-agent binary and no custom API endpoint.

   This appears to match the issue’s described HTTP/2 transport failure during long Cursor runs. It blocks reliable completion of work because the turn is terminated and there is no automatic recovery after tools have already run.
5. juliusmarminge

   closed this as completedin #2829on Oct 2, 2026