[Bug]: Original delegate_task task finalizes on a stale result in the gap before the child's background-exit wake turn#24297

Two more hits of this race in one parent thread on 0.1.2 stable (Ubuntu 24.04, Claude Code 2.1.309; parent Claude Opus 5.5, children Claude Fable 5.1, all delegate_task async).

Each child opened a PR, started gh pr checks --watch with run_in_background, and ended its turn saying it was waiting on CI. When CI finished, the parent got the "Delegated task … finished" notification a few tens of milliseconds before the child's wake run was requested:

In A's case task_status at notification time showed hasPendingChildRuns: true and latestTerminalSummary: null, but the task was already completed / result_available. The parent took the stale "waiting on CI" text as the state and ended its turn. The child's later final report ("CI green, PR Ready") showed up in task_status, but nothing woke the parent. Both PRs sat ready to merge until the user asked for a status, about 2 h and 1 h 40 min later.

The workaround we're using: children stop at a Ready PR without waiting on CI, and the parent calls watch_pull_request itself. That avoids the child's background-exit wake altogether.

Same race, seen twice on 2026-10-26 with a Claude child whose background work is native Agent subagents (run_in_background), not a Bash command. Nucbox-1, 0.1.3-preview.20261026.3702, parent thread 9b9ea64f-ecdf-4b2e-85aa-5346ab2a0197.

Task fleet-audit-vm-leads-20261026: the child starts three background readers (A, B, C) in run 1.

Task fleet-audit-pr-dispatcher-20261026: same pattern. The last reader finishes at 20:58:33.216, the task finalizes from run 3 ("One reader … is still running") at 20:58:37.024, and wake run 4 is requested at 20:58:42.898. The parent got the interim text as [completed] at 20:58:44.

Both times the finalization lands in the 1.5–4 s gap between the native subagent finishing and the wake run being registered, the same gap as above. hasPendingChildRuns (apps/server/src/mcp/OrchestratorMcpService.ts:472, origin/main) only counts later runs of the child thread, so neither a running native subagent nor a not-yet-registered wake run keeps the task open.

Simpler repro than the one above: the child doesn't need to start reviewers of its own; one background Bash command is enough. Call delegate_task with mode: "async" on a Claude child with this task, then let the notices arrive without calling task_status.

On build 0.1.4-nightly.20261027.3770, with a Haiku child, the task completed with REPRO1 WAITING 0.02 s after the command exited. REPRO1 DONE … arrived 5 s later as a second task with the same title, through #23542's follow-up path. The timings are from 3770; 3783 has the same delivery code.

#24391 on current main. Its ClaudeAdapterV2.ts changes no longer apply cleanly at 570d4b03ee: claudePendingBackgroundTasksFromRoster now takes awaitedTaskIds, and the idle emit moved into emitRosterUpdate. A port is below. A single-ordering version of #24391's new test fails on main with expected [ [] ] to deeply equal [ [ 'bdqirlcyw' ] ], and passes with the port.

A newer test conflicts with it. "holds only the background tasks the agent marks awaited, until they end" landed after #24391's base, and times out with the port. While the thread is idle, a snapshot drops one of two tasks without a task_notification, and the test waits for the published roster to shrink to one entry. The port keeps the dropped task published as owed a wake, so it never shrinks. Either the test or that rule needs to change. #24391 already rewrote the older "uses task_started as an incremental roster fallback…" test, where an empty snapshot drops a task the same way.

Reported by DanielJomphe. Investigation and tests by Claude Opus 5.5 in Claude Code, through T3 Code.

Still happening on 0.1.4-nightly.20261028.3814 (Windows 11, Claude Code 2.1.312, Opus 5.5 parent and child, async delegate_task). That build has #24610 and #23542 but not #24391. A t3_background_wait mark doesn't close the gap.

The child started clippy with run_in_background as task b3gyl80d9. It called t3_background_wait({"taskIds":["b3gyl80d9"],"waiting":true}), which matched, and ended run 1 with "Waiting on clippy…". Timeline from statev2.sqlite, UTC:

The mark holds the task until the command exits, then the task finalizes in the gap before the wake run registers. The real result still arrived later through #23542's per-run follow-up tasks. While it was pending, another child's task_status read completed / result_available with hasPendingChildRuns: true. Those follow-ups completing early is #21837's path; I've commented there.

Still happening on 0.1.4-nightly.20261029.3853 (Windows 11, Claude Opus 5.5 parent and child, async delegate_task).

The child started a dotnet publish with run_in_background, called t3_background_wait (matched) and ended run 1 at 11:30:20 local. The command exited and the task finalized at 11:33:13 with run 1's text. Run 2 (the wake turn) started at 11:33:14.

Run 2 started a new background publish, marked it with t3_background_wait (matched at 11:33:33) and ended at 11:33:35. Its follow-up task finalized at once, while that command still ran. Run 3 repeated this at 11:38:00.

Each finalize told the parent "finished" while the build was still running.

We encountered the same premature-completion symptom today with linked-environment delegate_task and a Claude Opus 5.5 child. The parent marked the task completed using an interim “capture is running in the background” reply, while the child continued through three more automatic runs. The parent card retained that first reply.

The child successfully registered its background Bash task with t3_background_wait before ending its first turn. Incident timeline on October 31, 2026 (UTC), from thread activity and read-only run records:

Affected desktop client and destination server: 0.1.6-nightly.20261031.3977 (2359643cffa6), macOS arm64, Node v24.22.1. The parent was on a linked Linux server whose version was not established.

The early completion and stale result are confirmed; attribution to this particular race remains an inference. No controlled reproduction or origin-side event trace was collected. This adds a remote-delegation case to the symptoms reported here.

Workaround for this incident: inspect the destination thread's active run and actual final reply directly, rather than trusting the origin's completed card. No runtime changes were made during triage.

Another occurrence of the same race, Claude child (claude-opus-5-5) on T3 Code with an async delegate_task:

The parent read the stale summary, concluded the child had been abandoned and sent it a follow-up. The real result reached the parent only because that t3_thread_send opened a follow-up task (finished 01:23:08). Without it, run 2's result would have been lost. Timestamps from statev2.sqlite (orchestration_v2_projection_runs, …_turn_items).

Still reproduces on v0.1.7, and calling t3_background_wait does not prevent it. Main at 4df0c130 has the same logic.

Minimal repro (Claude parent, claude-haiku-5-5 child, delegate_task async with shared isolation). The child's brief:

1. Start sleep 130 as a tracked background Bash task, call t3_background_wait with its ID (returns matched), and end the turn with "INTERIM 1".
2. On the task notification, do the same with a second job and end with "INTERIM 2".
3. On the next notification, end with "FINAL".

The parent receives three completions:

• "INTERIM 1" under the original task ID. It arrives when job 1 exits, before the child's wake turn runs. This is the race this issue describes.
• "INTERIM 2" under a provider-continuation: task ID. It arrives about 1 s after that turn ends, while job 2 is still awaited.
• "FINAL" under another continuation ID.

The second delivery looks like the follow-up gap in #21837 / #16603. In finalizeAppOwnedSubagent, the progress.state !== "result_available" hold applies only when task.id === childControls.thread.forkedFrom.nodeId, so continuation tasks are finalized when their run ends, even with awaited background work pending.

A production squad worker hit the same thing: three 18–27 min benchmark series, each started with run_in_background plus t3_background_wait, produced three premature completions.

The workaround we use: the child never ends its turn while its work runs. It waits in foreground chunks of timeout 540 tail --pid=PID -f /dev/null. With that, the same probe delivers exactly one completion.

Title: Historical frequency evidence for stale delegated-task completion notices

Problem: In a read-only audit of 4,846 finished app-owned delegated tasks on one T3 Code 0.1.6 installation (macOS arm64), 93 tasks (1.9%) closed within 3 seconds of a new child run starting. In 74 of those cases, the parent notice was byte-identical to the previous turn's interim text. The later result was not delivered to the parent.

Reproduction or observation: These are retained database observations, not a fresh reproduction on current main. The near-finalization child runs were triggered by background-command exits (62), peer messages (29), and grandchild notices (2), across Claude and Codex children. The follow-up turn took a median 54 seconds (p90 9 minutes). In hand-checked cases, parents repeated the stale "still running" state even after the real result existed.

The first completion path was generally prompt: 4,780 of the 4,846 tasks reached a parent within 10 minutes through a new run, steering into an active run, or return to a still-live blocking wait. That aggregate does not establish that every notice carried the final result.

Proposed behavior: Keep a task pending while the child owes a wake turn, and deliver the result of that turn rather than the previous interim message. If the task has already closed, deliver subsequent output once and make the latest result discoverable. #24391 remains open at this check; this is additional historical frequency evidence for its direction, not a claim that its patch was tested here. Later-turn delivery is also tracked in #28448.

Why native: T3 owns task finalization and provider wake registration. A parent relying on completion delivery cannot repair the race from a stale completion summary without separately inspecting the child.

Still reproduces on 0.1.9-nightly.20261111.4501 (Linux, self-hosted server, Claude Code 2.1.321; Claude parent, claude-opus-5-5 child, async delegate_task), with a matched t3_background_wait.

The child's brief: run sleep 120; date +%T with run_in_background, call t3_background_wait with its task id (it returned matched), end the turn with "INTERIM …", and reply "FINISHED …" when woken.

From statev2.sqlite, UTC:

task_status on the original task afterwards: summary and resultContextTransferId are run 1's, latestTerminalSummary is run 2's.

How often, on the same installation over the nightlies of 11-05 to 11-10: 83 Claude child runs in 27 delegated threads ended their turn right after a matched t3_background_wait.

• 11: the original task closed 0.15 to 0.33 s before the wake run was requested, with the interim text as its result (this issue).
• 30: the run was itself a wake turn, and its provider-continuation task closed within 10 s of the turn ending, mark or not (the second delivery in the 11-09 comment above; #21837). The next wake run came a median 170 s later.
• 42: closed at neither point.

So the parent was handed an interim text as a completed result in 41 of the 83.

Written by Claude Fable 5.2 in Claude Code, run from T3 Code, on behalf of its user.

This also reproduces when the child's background work is a native Claude Agent subagent instead of a Bash command. #32223 would not cover it: that PR keeps awaited entries in the provider roster, but local_agent entries never enter the roster. Only local_bash does (ClaudeAdapterV2.ts#L3182-L3186 on main). The hold comes from the subagent's lifecycle row instead, and that row ends at task_notification, before the wake run exists.

Steps (T3 Code 0.1.7 on Linux, Claude Code 2.1.318; not yet tried on a nightly):

1. A Claude parent starts a Claude child with async delegate_task.
2. The child calls the built-in Agent tool once with run_in_background: true, ends its turn with "INTERIM", and replies "FINAL" when the agent's completion wakes it.

Timeline, from statev2.sqlite and the child's provider event log, UTC:

The parent was first told the task had completed with the interim text. The real result came later as a second task.

I first saw this in a real session, where a child coordinated several background agents. The last running agent finished at 15:55:15.440, Claude started the wake turn at 15:55:15.496, T3 closed the task at 15:55:15.555 with the previous turn's interim text, and wake run 5 started at 15:55:15.883. Afterwards, task_status on that task returned workState: "result_available" together with hasPendingChildRuns: true.

In that session, every later wake turn's provider-continuation task also closed when its own run ended, including one whose run had just resumed an agent with SendMessage (#33482). Claude emits task_started again on that resume, and T3 reopens the subagent row with run_id set to the resuming run. So #33539's ownership rule should cover that part, though I've only read the code, not tested it.

This is the same problem as #34568, so I'm closing it in favour of that one. If it is different, say how and it will be reopened.