Repository navigation
Delegated task: final wake-turn completion never delivered to the parent; task result stays on run 1 #28448
Description
Area
apps/server (delegated-task result delivery)
Version
T3 Code 0.1.3, Claude parent (claude-opus-5-5), Claude child (claude-sonnet-5-5).
What happened
A parent thread started a Claude child with delegate_task (mode: "async", isolation: "shared"). Over about an hour, the child ended its turn several times to wait on its own background Bash commands and on two reviewer grandchildren it had started with delegate_task. Each time, Claude Code ran a wake turn later.
The parent received a completion for the original task (run 1). It then received one for each of four later wake turns, delivered under provider-continuation task IDs, for example:
node:delegated-task:provider-continuation%3Amessage%3Athread%3Athread%253Adelegated-task%253Acommand%25253Amcp%25253A5917fdbb-…%25253Adelegate-task%25253A3a4db4d4-…%3Aordinal%3A1%3A<message-id>
The child's last wake turn completed at about 21:57Z, with its final report (PR opened). No completion for it ever reached the parent, and the parent stayed idle. The delivered summaries before it had said things like "yielding until the reviewers finish". The gap was noticed 2h18m later, only because the user asked the parent for status.
task_status on the original task ID at that point:
status: completed,workState: result_available,hasPendingChildRuns: falselatestTerminalRunId: …:ordinal:10,latestTerminalStatus: completed, andlatestTerminalSummaryheld the final report- but
summaryandresultContextTransferIdstill held run 1's result ("The full verification run … is still going in the background")
So T3 recorded the final run as terminal but neither delivered it nor promoted it to the task's result.
Expected
Every wake turn's completion, and the final one above all, is delivered to the parent. summary and resultContextTransferId reflect the latest terminal run.
Impact
An orchestrating parent depends on that delivery as its only wake signal, because it is told not to poll. A lost final delivery stalls the whole queue until a human notices. A delegated child cannot work around it by watching its PR for the parent: watch_pull_request is not available to delegated children (see #25764).
Related
- [Bug]: Original delegate_task task finalizes on a stale result in the gap before the child's background-exit wake turn #24297: the original task finalizes on a stale result before the child's background-exit wake turn. Same family; here the stale run-1 summary also persisted after run 10 completed, and the run-10 delivery itself went missing.
- Delegated task reports finished while its child thread still has running work #16603, Queued native child continuation output is dropped after root completion #19228, Delegated children are told never to watch their PR, so nobody follows CI on a child's fix PR #25764.
Activity
collisdigital commentedon Nov 1, 2026
Not a duplicate of #28444, though the symptom is the same (parent never woken):
finalizeTurnwaits onsdkRun.wait, which resolved 8 h afterturn-ended, so no completion exists yet to deliver. The fix there (fix(provider-cursor): finalize turn when SDK wait hangs after turn-ended #27185) is inprovider-cursor.task_statusshowedlatestTerminalRunId …:ordinal:10,latestTerminalStatus: completedand the final report inlatestTerminalSummary. Earlier wake turns of the same task were delivered. The miss is downstream of finalization: the run-10 completion was never delivered to the parent, and the task'ssummary/resultContextTransferIdstayed on run 1. That makes it closer to [Bug]: Original delegate_task task finalizes on a stale result in the gap before the child's background-exit wake turn #24297 than to Cursor agent turns stay "running" for hours after the reply is finished (8 h 00 min measured) #28444, and fix(provider-cursor): finalize turn when SDK wait hangs after turn-ended #27185 would not change it.Shared impact: an orchestrating parent that relies on completion delivery stalls with no signal in both cases.
1kuna commentedon Nov 9, 2026
Title: Historical frequency evidence for undelivered later child turns
Problem: A read-only audit of 4,846 finished app-owned delegated tasks on one T3 Code 0.1.6 installation (macOS arm64) found 535 tasks with a child turn requested more than one second after task closure; 520 had at least one such turn complete. No parent notice corresponding to those inspected later turns was found. This includes child turns triggered by peer messages and scheduled checks, not only background-command exits.
Reproduction or observation: Retained task, run, message, and orchestration-event records were compared; a fresh current-build reproduction was not performed. Runs starting a new delegation on the same reused child thread were excluded. The most common recorded trigger was an MCP send or scheduled check (1,893 turns), followed by grandchild notices (128) and background exits (31).
After 790 later turns, the parent remained idle for more than 10 minutes. Grouping by parent produced 261 distinct idle windows: median 27 minutes, p90 175 minutes, maximum 25.4 hours; 75 exceeded one hour, 25 exceeded three hours, and seven exceeded six hours. A human message ended 45 windows.
Caveat: These counts are an upper bound on actionable missed results: many later turns were routine checks, and not every turn was read to distinguish a substantive result from a heartbeat. Three hand-checked cases did contain substantive results that never reached the parent. The measurements describe this installation and historical window, not all installations or a failure rate on current main. Older first-turn summaries and later terminal summaries must also be distinguished; a later result being readable in child history does not mean the parent was notified.
Proposed behavior: Deliver new substantive child output after task closure exactly once, or reopen/reassociate the task so that its latest result and parent wake remain coherent. Cover peer sends, scheduled checks, grandchild results, and background exits. #24391 and #21877 remain open at this check; please include the peer-message/scheduled-check path when assessing coverage.
Why native: T3 knows the child-to-parent relationship and each run's terminal transition. Polling a task's original summary is not a replacement for reliable event-driven delivery.
Aplietexe commentedon Nov 10, 2026
A data point from 0.1.8 (Windows desktop app, WSL runtime, Claude Code 2.1.322), with minimal repros. It narrows down when the final result is lost.
delegate_task) ransleep 45withrun_in_background, marked it witht3_background_wait, and ended its turn. On waking, it ran a secondsleep 30the same way, then repliedFINAL. The parent got three deliveries. The last one wasFINAL, under aprovider-continuationtask ID. So I couldn't reproduce the lost Bash wake turn in this simple case.Monitorevent: not delivered. The child started aMonitorrunningsleep 60; echo MONITOR_DONE, marked it, and ended its turn withWAITING. It repliedFINALwhen the Monitor fired. The parent was woken once, after the Monitor ended, withWAITING.FINALnever arrived. Without the mark, the sameWAITINGwas delivered at the first turn end instead, and nothing followed.The
task_statussection ofdocs/orchestration-v2/orchestrator-mcp-server.mdsayslatestTerminal*exposes later "non-monitor results", so the Monitor case may be by design. Either way, a child loses its final report whenever its last wait was a Monitor.Drafted with Claude (Opus 5.5) in T3 Code; the repro ran on my install.