[Bug]: Cursor delegated task in a T3 worktree replays its finished turn until "Connection failed repeatedly", and the failed task drops its output #23412

Filed by Claude (Opus 5.5, Claude Code in T3 Code) at the account owner's request. Paths below are redacted: <user> is a 9-character Windows username, <project> a 21-character project folder name.

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

On Windows, T3 Code 0.1.1 (server 0.1.1), bundled @cursor/sdk 1.0.35:

1. From a Claude (Opus 5.5) thread, call delegate_task with target: {providerInstanceId: "cursor", model: "grok-4.7", options: {reasoning_effort: "xhigh"}}, isolation: "worktree", mode: "async", role: "review", runtimeMode inherited (full-access). The task was a read-only review of a 5-file docs PR.
2. T3 creates the child's checkout at C:\Users\<user>\.t3\worktrees\<project>\t3-<8 hex>.
3. The Cursor SDK's per-agent checkpoint store for that workspace would be C:\Users\<user>\.cursor\projects\C-Users-<user>-t3-worktrees-<project>-t3-<8 hex>\sdk-agent-store\<sha256>\agents\agent-<sha256>\store.db: 268 characters here, past the 252-character limit described in [Bug]: Cursor SDK retries replay a finished turn (re-running tool calls) when its checkpoint save fails #19112.
4. Wait for the task.

Expected behavior

The review turn runs once and the delegated task completes with its final message. If the run fails after the turn has finished, task_status and the completion notification still return that final message, with the error beside it.

Actual behavior

• The first turn finished at 22:51:22 UTC with a complete report. About a minute later the SDK started the same prompt again from scratch inside the same run, with no new run.start from T3.
• That repeated: one run (run-5a87176c-...) has 9 turn-ended events, each after a full 7 to 12 minute review with its own final report. The verdicts differed between replays, so each was a real rerun with every tool call executed again.
• 44 s after the 9th turn ended, the run completed with status: "error", "Connection failed repeatedly". That's durationMs 6528508 (1 h 48 min) and 17,893,775 total tokens for one review.
• T3 marked the delegated task failed. task_status returned only summary: "Connection failed repeatedly", although the child thread holds nine finished reports. The parent rerouted the review elsewhere before anyone looked at the child thread.
• The agent folder sdk-agent-store\<sha256>\agents\agent-<sha256>\ is empty: no store.db was ever created, so no checkpoint was saved. index.db next to it was written normally.

Times (UTC):

Diagnosis.

• Trigger: [Bug]: Cursor SDK retries replay a finished turn (re-running tool calls) when its checkpoint save fails #19112's long-path checkpoint failure. T3's own worktree layout puts the store path for every Cursor child with isolation: "worktree" near or past 252 characters on Windows. Here it is 268 with a 9-character username, so a short project name doesn't avoid it.
• Replay: with no checkpoint saved, each retry resends the original action, so the whole finished turn replays ([Bug]: Cursor SDK retries replay a finished turn (re-running tool calls) when its checkpoint save fails #19112).
• Why it ends as "Connection failed repeatedly": the SDK's 10 transport retries count over the whole run and never reset. In the bundled SDK's retry loop, the transport counter only goes up (if(f.countAsTransportError)L++), even after an attempt that made progress. With Rj1={serverCap:3,transportCap:10}, the run throws "Connection failed repeatedly" once 10 transport errors have counted, however much finished work came between them.
• Not the network, as far as I can tell:
  • DNS from this PC: api2.cursor.sh and api2direct.cursor.sh resolve to the same three public addresses through the local resolver and through 1.1.1.1 (52.21.130.202, 34.225.159.174, 3.92.129.183).
  • On the same PC and network, two Grok reviews through the Cursor CLI (cursor-agent -p --mode ask, a short workspace path, no SDK agent store) ran about 16 min each without an error right after this.
• Couldn't check: the SDK's own [AGENT_ERROR_DIAGNOSTICS] lines for this window. server.trace.ndjson had rotated past it, and the provider event log doesn't carry them.

Asks:

• (a) A failed delegated task that has output returns that output along with the error: task_status.summary, or a separate field, carries the child's last assistant message, marked as coming from a failed run.
• (b) One automatic resume on a Cursor transport error. For this trigger, a resume needs a saved checkpoint, so it depends on the store fix in [Bug]: Cursor SDK retries replay a finished turn (re-running tool calls) when its checkpoint save fails #19112; without one, a resume would replay the turn again.

Related: #19112 (the same replay; this adds T3 worktrees as a trigger on Windows, and the transport-cap ending) and #12374 (earlier Cursor transport errors during runs).

Impact

Major degradation or frequent failure

Version or commit

T3 Code 0.1.1 (server 0.1.1), desktop on Windows; bundled @cursor/sdk 1.0.35 (@cursor/sdk-win32-x64 1.0.35)

Environment

Windows 11 Pro 10.0.26200; T3 Code desktop 0.1.1; Cursor provider, grok-4.7 with reasoning_effort: xhigh; parent thread on the Claude provider (Opus 5.5)

Logs or stack traces

# provider event log for the child thread, providerSessionId redacted
[2026-10-21T22:41:01.062Z] NTIVE: {"provider":"cursor","protocol":"cursor-agent-sdk.local","kind":"protocol","providerSessionId":"<redacted>","event":{"direction":"incoming","stage":"decoded","payload":{"type":"agent.opened","agentId":"agent-142a6644-c42a-4272-8d49-260a9b70ad27"}}}
[2026-10-21T22:41:06.597Z] NTIVE: {"provider":"cursor","protocol":"cursor-agent-sdk.local","kind":"protocol","providerSessionId":"<redacted>","event":{"direction":"incoming","stage":"decoded","payload":{"type":"run.started","runId":"run-5a87176c-73ec-4004-b6cb-740d3e78a22f","agentId":"agent-142a6644-c42a-4272-8d49-260a9b70ad27"}}}
# ... 8 earlier turn-ended events (times in the table above) ...
[2026-10-22T00:29:09.318Z] NTIVE: {"provider":"cursor","protocol":"cursor-agent-sdk.local","kind":"protocol","providerSessionId":"<redacted>","event":{"direction":"incoming","stage":"decoded","payload":{"type":"interaction.update","runId":"run-5a87176c-73ec-4004-b6cb-740d3e78a22f","update":{"type":"step-completed","stepId":54,"stepDurationMs":506051}}}}
[2026-10-22T00:29:10.383Z] NTIVE: {"provider":"cursor","protocol":"cursor-agent-sdk.local","kind":"protocol","providerSessionId":"<redacted>","event":{"direction":"incoming","stage":"decoded","payload":{"type":"interaction.update","runId":"run-5a87176c-73ec-4004-b6cb-740d3e78a22f","update":{"type":"turn-ended","usage":{"inputTokens":744932,"outputTokens":56108,"cacheReadTokens":629888,"cacheWriteTokens":0,"reasoningTokens":49391}}}}}
[2026-10-22T00:29:53.465Z] NTIVE: {"provider":"cursor","protocol":"cursor-agent-sdk.local","kind":"protocol","providerSessionId":"<redacted>","event":{"direction":"incoming","stage":"decoded","payload":{"type":"run.completed","result":{"id":"run-5a87176c-73ec-4004-b6cb-740d3e78a22f","requestId":"55c04cf7-0e7c-44a7-9ad6-e836265014ae","status":"error","error":{"message":"Connection failed repeatedly"},"model":{"id":"grok-4.7","params":[{"id":"reasoning_effort","value":"xhigh"}]},"durationMs":6528508,"usage":{"inputTokens":9345552,"outputTokens":513151,"cacheReadTokens":8035072,"cacheWriteTokens":0,"totalTokens":17893775,"reasoningTokens":448803}}}}}
[2026-10-22T00:59:53.492Z] NTIVE: {"provider":"cursor","protocol":"cursor-agent-sdk.local","kind":"protocol","providerSessionId":"<redacted>","event":{"direction":"outgoing","stage":"decoded","payload":{"type":"agent.close","agentId":"agent-142a6644-c42a-4272-8d49-260a9b70ad27"}}}

# Cursor agent store for the child's workspace
C:\Users\<user>\.cursor\projects\C-Users-<user>-t3-worktrees-<project>-t3-<8 hex>\
  mcp-auth.json
  sdk-agent-store\<sha256>\index.db        30400512 bytes, last written 00:29 UTC
  sdk-agent-store\<sha256>\index.db-wal
  sdk-agent-store\<sha256>\agents\agent-<sha256>\   (empty: no store.db)

# bundled SDK retry loop (server.asar), excerpt
if(!Y&&Z.transportErrorRetries>=J.transportCap)return B(F(),{countAsTransportError:!0})
...
if(f.countAsServerError)F++
if(f.countAsTransportError)L++
...
Rj1={serverCap:3,transportCap:10}

Workaround

Run Grok through the Cursor CLI (cursor-agent -p --mode ask) in a checkout with a short path, or use Claude subagents, which aren't affected. When a Cursor delegated task fails, read its child thread before rerunning: the finished output is usually there.