[Bug]: Parent is never notified when a delegated child's provider-initiated run ends (e.g. after a background command finishes)#21772

Thanks for the clear timeline. Confirmed on current main.

Delegated results reach the parent per task. When a child run ends, the server looks for the task that owns it (apps/server/src/orchestration-v2/Orchestrator.ts:10252-10258). It skips the original task once its result has already been delivered (Orchestrator.ts:10607-10617). The fix for #13490 creates a new task only for a message that a user or an MCP sender dispatches into the child (Orchestrator.ts:6940-6949). A run the provider starts by itself, such as after a background command finishes, gets no task, so nothing is delivered and the parent is never woken.

This isn't a duplicate of #16603. That issue covers the task finishing early while T3 can still see work running in the child. Here the task finished correctly, and the later work happens outside anything T3 tracks.

Accepting this as a bug. Your workarounds still apply for now: have the child message the parent when it needs a decision, or have the parent check task status.

Another data point for this one, from 0.1.2-nightly.20261021.3486 (macOS, Claude Code 2.1.307, a Sonnet 5.5 child at low effort). In my case the parent got the wrong result, not only a missing wake, so it may be worth checking against the open fix in #21813.

What I ran (my agent drove the MCP calls):

1. I used delegate_task to start a Claude child. It ran sleep 45 with native Bash background execution, ended the turn, and was to reply CANARY-1 when the job finished.
2. While the job was still pending, two t3_thread_send calls to the child with mode: "queue": /compact, then a note asking it to reply CANARY-2.

The child's runs, in order: run 1 ended with the job pending, run 2 was the compaction, run 3 replied CANARY-2, and run 4 started from the background-task notification and replied CANARY-1. Both queued turns finished before the background job did.

What the parent got: one wake for the original task, with summary CANARY-2. task_status later showed latestTerminalSummary: "CANARY-1", and no second wake came. So the original task was published with the queued turn's text as its result, and I recovered the requested answer by reading task_status, without receiving another wake.

My guess at the mechanism from reading main at ed9b7ca9 (not confirmed with finalizer timestamps): the #22709 listener rechecks the task for finalization when the background roster empties (Orchestrator.ts L11879-L11907), and delegatedTaskProgress picks the newest terminal work run as the result (subagentProjection.ts L241-L268). In the provider log the roster emptied at 23:29:53.089Z and the wake turn started at 23:29:53.882Z. That ordering is consistent with the finalizer seeing the queued CANARY-2 turn as the newest terminal run before the wake turn was registered. After that the finalizer skips a task that already has both a result and a result transfer from that child (Orchestrator.ts L10886-L10924).

Expected: the parent gets CANARY-1 as the task's result, either because publication waits for the provider's wake turn or because the later answer is delivered on its own. Queued user or maintenance text shouldn't stand in for the task's answer.

A queued note without the /compact is probably enough to reproduce it, but I only ran the version above.

This still happens on 0.1.2-nightly.20261022.3541 (Ubuntu Linux, T3 server as a user service). Parent and children are Claude Agent, claude-opus-5-5. The build does not include #21813.

In one overnight run, 4 of about 25 async delegate_task children hit it. Each child started its final checks with Bash run_in_background and ended run 1 with an interim text ("checks are running, I will send the full report"). The parent got only that interim text.

The worst case, from the child's run list:

• Run 1 ended at 03:20 UTC. The parent was notified at 03:23 with the interim text.
• Runs 2 to 4 were provider wakes after background commands finished. Run 4 ended at 03:28 with the final report (head SHA, all checks passed).
• At 04:03 the parent was woken by a different child's completion. Nothing told it that this task had a newer result.
• The parent read latestTerminalSummary only at 07:51, when the user asked. The result had waited about 4.5 hours.

task_status at that time showed status: completed, hasPendingChildRuns: false, and latestTerminalRunId at ordinal:5.

For now we tell delegated children to run their checks in the foreground with a long timeout, so the result is in run 1.

This was my number one issue when I ran Matt Pocock's /retro skill.

Another data point from 0.1.2 stable (macOS, Claude Code 2.1.310). Parent and children are Claude Agent, claude-opus-5-5 at high effort.

• A parent started three async delegate_task children. Each child's last step was a test run of about 15 minutes. That's too long for one foreground Bash call, so the child started it with run_in_background and ended its turn with an interim "waiting on the tests".
• That interim text became the task result. When the run finished, the child woke, completed the work (a PR marked ready) and wrote its final report. The parent was never woken with it.
• Two of the three children hit this within an hour, and we found the finished work only by reading the child threads. On Linux (0.1.2, Claude Code 2.1.309), an earlier child did the same with a 5-minute background test run.

Each child's earlier turns ended while its own Agent subagents were running, and those correctly kept the task open. So the trigger is specifically a background command, and any step longer than the Bash timeout forces one.

Same outcome on 0.1.2 stable, two children in one parent thread: each child's final report after a background CI watch never woke the parent, and the work sat idle for about 2 h and then 1 h 40 min until the user asked for a status. In both cases the trigger was the race in #24297 (timestamps there), so a fix that delivers the later runs' results would have covered both.