App-owned follow-up completes while nested work runs, then loses the final result#21837

Thanks for the controlled lifecycle and the careful limits. Current main matches both parts of your reading.

1. Only the original delegated task waits for nested work before finishing (apps/server/src/orchestration-v2/Orchestrator.ts:10603-10614). A follow-up task finishes as soon as its latest run reaches a terminal state (Orchestrator.ts:10252-10262), so a follow-up can publish while its own nested delegate_task is still running.
2. The wake that delivers a nested result is dispatched by the server as an agent message (apps/server/src/orchestration-v2/ProviderContinuationService.ts:119-135). Follow-up intake ignores that kind of message (Orchestrator.ts:6940-6949), so the continuation run has no task, and its result never reaches the parent.

This overlaps with #16603 and #21772, but neither covers it. #16603 is about the original task and running commands. The open fix for #21772 still leaves this wake out on purpose. Keeping this open as its own bug.

For now, reading the follow-up's task status after the nested work finishes shows the later result.

Reproduced on current main 70e5e384da using the web dev server on Linux with isolated, pruned real data. Writer and nested checker used Codex gpt-6.1-sol, high reasoning, standard service tier.

Ran READY → one queued follow-up → async checker (sleep 40) → INTERIM → automatic FINAL. While the checker ran, the follow-up already reported completed/result_available, summary INTERIM, hasPendingChildRuns=false. Writer run 3 later completed with FINAL BETA21837 CHECK21837, without delegatedTaskId or a parent result transfer. Parent received READY and INTERIM only. A final status read recovered FINAL via latestTerminalSummary; published summary stayed INTERIM and original READY remained intact.

Runtime transcript and scoped projection excerpts. The duplicate scan found no matching open report for this nested follow-up lifecycle.

Existing fix #21877 addresses this lifecycle; no replacement PR opened. The retained Linux web/server reproduction on 70e5e384da shows READY and INTERIM delivered, with FINAL recovered only through task status. Independent verification of the existing PR head could not finish: the VM became saturated and tool calls stalled. Issue remains open pending verification and landing.

Still happening on 0.1.2 (stable) with Claude children: twice in two days, a t3_thread_send follow-up task finalized at the end of its own turn while the child's delegate_task reviewers and a run_in_background Bash command were still running. The real result came in a later turn and never reached the parent. Same shape as the report above. The race on the original-task path is filed separately as #24297.

Additional production impact observed by our project orchestrator on 2026-10-25. The installed macOS desktop reports 0.1.3-nightly.20261024.3630. This is a current user/operator report, not a new controlled reproduction or an executable-to-source mapping.

Six delegated lanes today followed the same pattern: an interim result such as waiting on a background suite reached the parent; a background/watch completion automatically started a later child run; that run produced final PR/head/verdict information, but no completion notification reached the parent. The parent recovered the later result through task_status.latestTerminalSummary or a child timeline read. Original-task and follow-up paths should both be checked; #24297 may cover part of the former.

Could the existing fix ensure every terminal run of an owned child has durable parent-result delivery, including background/watch/self-wake runs after the original task has already finalized? Please preserve original task lineage and distinguish interim from final state; either associate those wakes with the owning task or deliver a child-run result keyed by child thread and terminal run. Exactly-once processing needs a durable delivery/consumption identity so crash/retry/manual recovery cannot lose a result or trigger duplicate integration.

Useful regression cases: original task and queued follow-up; nested child and background command completion; multiple later child runs; completed/idle versus running parent; interrupted/provider-failed terminal child; app restart between terminal event and delivery; late/manual status recovery; settled predecessor with explicit custody transfer. Preserve active background custody rather than settling a child merely because its interim task says completed.

We are adding explicit child-to-parent completion receipts plus per-terminal-run parent reconciliation as an operational workaround. This is not a runtime fix or independent proof that the pending PR resolves all reported cases. No credentials, private transcript or customer data are attached.

Written by Claude Opus 5.5 on behalf of @ScottN-PV.

#21877 (head 3dda05ac50) covers less than this. It fixes one case: a queued follow-up whose own run starts a nested delegate_task. That follow-up stays pending until the nested task ends. The nested-result wake then runs under the follow-up's task, so the final reply reaches the parent once.

It does not cover wakes from background commands or watches. The follow-up waits while the provider lists the command as pending. The wake run that the command's exit starts has no task, so its result is not delivered. It also leaves the original task unchanged, and it adds no per-run or restart delivery handling. #21772 and #24297 track those paths.

This comes from reading the source and from our Linux test of the nested case. We have not run your macOS build.

Focused tests confirm ScottN-PV's reading above. With #21877, a follow-up that starts a background command (CookerTea's run_in_background case) is held while the command runs, but it still completes with its interim reply.

When the command exits, Claude wakes the child in a new run. The original task already has a result, so recordSubagentFollowup gives that run a new task (Orchestrator.ts:7458 on main). The real reply does reach the parent, but as a second task with the same title, while the follow-up itself completes with its interim text. #21877's continuedTaskId avoids this for nested results, which name their source run in delegatedCompletion.parentRunId. A background-command wake names no run.

Two focused tests in DelegatedCompletionDelivery.test.ts, on main at 570d4b03ee:

The tests write orchestrator events directly. They model the adapter with #24391, which keeps the command published until its wake run ends. Without #24391, the published roster empties before the wake run starts (#24297), which gives the follow-up an earlier chance to finalize on its interim reply.

#21877 is waiting on verification, so I'd follow up after it lands rather than stack on it.

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

Still observable on 0.1.3-nightly.20261027.3754 on Linux x64 (Debian 13), with a Claude Fable 5.1 parent and Claude Opus 5.5 children. Provider initialization records confirm Claude Code 2.1.311 and bypassPermissions. Codex CLI 0.165.0 is installed at inspection; the cases below were traced in Claude children, not independently reproduced with Codex.

This is a local build of upstream d2c440312e5f39d59827ed466838a623516454d6 with SQLite read-performance patches. The task intake/finalization and completion-dispatch logic are unchanged; the MCP service and continuation service match that upstream revision byte for byte. No clean-release reproduction was run.

Read-only database inspection found these completed later runs without a delegatedTaskId or a parent subagent_result transfer. All times are 2026-10-27 UTC; A–C are separate children:

Delivery is selective: child C's runs ending at 23:36:57.337Z and 23:39:28.194Z had task associations and parent transfers. Child B's intervening runs at 23:07:16.761Z and 23:08:45.841Z did too.

An additional original-task case produced READY at 21:55:09.277Z; its first parent result transfer instead referenced a later rebase/status reply at 22:02:15.234Z. I have not established that this shares the nested-follow-up cause.

Our workaround is to check PR status and read child task/thread results explicitly. The needed behavior is to retain the follow-up's ownership through nested-result wakes and deliver its eventual report once, including decision requests. #21877 remains open and unmerged; I have not tested its fix.

Background-command case on 0.1.4-nightly.20261028.3814 (Windows 11, Claude Code 2.1.312, Opus 5.5 parent and child, async delegate_task): a t3_background_wait mark (#24610) doesn't hold a wake run's follow-up task.

After the original task closed early (#24297), each wake run got its own provider-continuation task. Each of those completed when its run ended, even though the child had marked a still-running command and got it back in matched. From statev2.sqlite, UTC:

The final result is no longer lost; it arrives as another task with the same title. But the parent got four interim "completed" notices, each costing a turn. Holding a follow-up open while its own marked waits run, as the original task is held, would fix that.

Aside: the system prompt says to call t3_background_wait "with its task ID", but the tool takes a taskIds array, so the child's first call ({"taskId":"b3gyl80d9"}) failed validation.

Still present on stable 0.1.5 (macOS, Claude Opus 5.5 parent and child), and on main at 32ecd71726. A provider-continuation task completed when its run ended while its command was still marked awaited: true. A visible effect not mentioned above: the parent's Lineage moves the child to "Previous agents" as completed for the whole wait (about 24 minutes here).

Another case on macOS arm64, Claude Opus 5.5 parent and child, both on high reasoning effort, async delegate_task. It covers the background-wake shape above and also shows a server restart variant: the child's final run is a restart continuation with no task at all, so its result never reaches the parent.

The server runs a fork of stable with one patch (a Codex account-usage view) that doesn't touch orchestration. Runs 1–2 were on a v0.1.3 base with Claude Code 2.1.312. The child's own work restarted the server mid-sequence, so run 3 was on v0.1.5 with Claude Code 2.1.314.

Times in UTC:

1. 13:12:25: the parent delegates a long task. The child starts a background command and ends its turn with an interim reply ("waiting for the background deploy; I'll pick up when it notifies").
2. 13:54:57, run 1 ends: the original task completes with that interim reply as its summary, and the parent is woken with it. That's #24297.
3. 13:55:27, run 2: the "commands finished" notification wakes the child under a new provider-continuation task. The child starts another background command, which restarts the T3 server once it activates, marks it with t3_background_wait, and ends its turn with another interim reply. The parent gets that as a second completed task with the same title.
4. About 13:56: the server restarts.
5. 13:56:45, run 3: a restart continuation starts in the child ("T3 Code restarted and stopped background work … resume or restart what you still need").
6. 14:03:14, run 3 ends: run 3 finishes the work and writes the final report. No completion is delivered to the parent. The parent's task_status still shows the original task's run-1 interim summary. The final report could only be found by reading the child thread.

As we read #27222 ("once a task has settled, it no longer owns later work in the child thread"), dropping run 3 is intended behavior once the original task has settled. So with an early settlement (#24297) and a restart, the final result is lost entirely, rather than arriving as a duplicate task as in the cases above. #21877 wouldn't change this either, because nothing here involves nested delegate_task in a follow-up.

Expected: the parent receives the run-3 result exactly once, either because the original task stays open across the background wait and the restart, or because restart continuations of a child thread report under the last task that owned the thread.

Re-ran the follow-up tests posted above on current main, with and without #21877. These tests write orchestrator events directly, so they aren't a live provider run.

• The tests need one change since #27468. Unmarked commands no longer hold a task, so the roster rows need awaited: true.
• The second row is the case I reported above. It is the first test with the follow-up run started by a wake instead of a t3_thread_send: a message.dispatch with a provider-continuation:<messageId> command ID and a command notification. #21877's hold covers it.
• The third row still fails with #21877. The task publishes the interim reply (The build is running; I'll report when it ends.) instead of the wake's result. #21877 says Closes #21837, so merging it would close this issue with that part still open.

I'm not opening a PR: #21877 covers the hold, and the comment from Krarilotus on #24391 describes a local patch for the wake ownership.

Additional confirmation on stable v0.1.6, macOS arm64, using T3 app-owned delegation. This appears to be the same nested-follow-up defect, so I am adding evidence here rather than filing a duplicate.

In the observed unmodified installation:

• The parent sent more work to a completed child with t3_thread_send, which returned a new follow-up task ID.
• That child resumed its workers and ended the follow-up turn with a waiting message. The parent received an early “finished” notification.
• Worker completions subsequently woke the child through three more runs. The last run produced the final report.
• In the inspected parent timeline, no corresponding final notification or automatic parent turn appeared between that final child result and the user's later progress question (about 63 minutes later).
• The parent then read the task and recovered the latest result. Worker-to-child delivery was functioning; the missing part was the final child-to-parent handoff.

We also reproduced premature publication at the service-test level against the v0.1.6 source tag, commit 2359643cffa6ba9ee84d6f2694b935de54a8013e, by extending the existing DelegatedCompletionDelivery.test.ts follow-up case: READY → explicit follow-up → nested task → interim terminal turn → nested-result continuation. The unmodified code failed the assertion that the follow-up result should remain null while the nested result was still owed:

Inspection of this version suggests two related paths worth checking:

1. The nested-work gate in finalizeAppOwnedSubagent applies to the original fork task; the follow-up can reach terminal publication too early.
2. The server's delegatedCompletion wake does not inherit that follow-up's delegatedTaskId. Preventing early publication alone therefore does not make the finalizer select the eventual continuation's result.

This is not a claim that every missing notification has the same cause, or that current main has been retested. The service test uses temporary persistence and controlled events, not a fresh real-provider reproduction on an untouched current release. A temporary local experimental fix also passed a real three-level synthetic run without explicit handoff messages, but I am withdrawing that custom runtime and prefer an upstream fix; I am not asking maintainers to adopt the local implementation.

The acceptance case should preserve the original READY result, keep the follow-up pending while its own nested work is outstanding, and deliver the final continuation result exactly once without attributing a later unrelated user/send turn to the old task. An explicit final handoff to the known parent is our temporary operational workaround.

No private task contents, machine paths, credentials, or production database excerpts are included. Prepared with GPT-6 Astra in Codex/T3 Code on behalf of @ytwytw.

Fresh evidence on newer nightlies, read-only from the state DB, plus one surface that #21877 doesn't cover.

What happened

A supervisor thread runs long delegated lanes with Codex (gpt-6.1-sol) and Claude Opus 5.5 children. Every background-exit wake of a child that already has a result starts a new provider-continuation task. That task completes and notifies the parent as soon as its run ends. Counted from the parent's task projection (2026-10-29 to 11-02):

Each of those tasks woke the parent once. The supervisor sampled 14 of the Codex-era wake notices: 8 were interim status, 5 restated known results, and 1 carried a new result.

On Claude children the extra tasks also complete while the child still waits on work it marked with t3_background_wait (evidence below). t3_background_wait is Claude-only, so I can't show the same for Codex.

In the desktop app's Lineage panel at about 06:16 UTC, three Claude lanes waiting on awaited gates were listed under "Previous agents". The panel read "2 running": one Claude child mid-turn and one Codex child in a long turn.

Diagnosis

Server line references are to tag v0.1.6-nightly.20261031.3973 (85bd3f2a2a). Client line references are to v0.1.7-nightly.20261101.4035 (80120b1aa34a). The same logic is on main c65f8d552b, except for #27468.

• mayStartSubagentFollowup (Orchestrator.ts:639, main :678) admits every notification except monitor. recordSubagentFollowup (:7742, main :7843) gives each wake run its own task with completionWake: "always".
• Only the original task is held on delegatedTaskProgress (:12509, main :12612). Other tasks finalize once their own run is terminal (finalizeAppOwnedSubagentTask, :12185, main :12288). Awaited roster entries don't hold them.
• task_status agrees with the early finalization: for a task that owns runs, workState comes from those runs alone (OrchestratorMcpService.ts:1485-1490, main :1506-1511).
• Lineage takes a subagent edge's status from activityRunStatus (packages/client-runtime/src/state/threadRelationships.ts:112). ThreadRelationshipsControl.tsx:476 files completed/idle/… edges under "Previous agents". Neither reads pendingBackgroundTasks or awaited.

Steps to reproduce (derived from the source and the rows below; not rerun as a clean reproduction)

1. delegate_task to a Claude child: "Reply READY." Wait for its result.
2. t3_thread_send to the child: "Run sleep 60 in the background and mark it with t3_background_wait, then end your turn. When it exits, do the same with sleep 300. Report DONE when that one ends."
3. The thread-send task completes when the first turn ends, while sleep 60 is still awaited.
4. When sleep 60 exits, the wake run gets a new provider-continuation task. That task completes a few seconds after the run ends, while sleep 300 is still awaited. Lineage shows the child under "Previous agents".
5. DONE arrives later as a third task with the same title.

Version

• Server: 0.1.6-nightly.20261031.3973 (85bd3f2a2a), the version the server reports.
• Client: macOS desktop app 0.1.7-nightly.20261101.4035 (80120b1aa34a).

Environment

• Server: Ubuntu 26.04.1 LTS, Linux 7.0, Node 26.13.0, Claude Code 2.1.316.
• Client: the macOS desktop app, connected to that server remotely.

Evidence (from statev2.sqlite, opened read-only, 2026-11-02 UTC)

When I read the DB, the three Claude children below each had one pending roster entry, kind: command, awaited: true. Every parent task for them was completed / delivered.

Every task in the table is a provider-continuation task. Lane T's single awaited command produced three completed notices while it ran.

Lane W's original task completed at 05:11:55.784. Its last run had ended at 04:45:02, and the background-exit wake run 4 started 0.5 s later, at 05:11:56.323. That is the #24297 gap.

Related issues

• This is the background-command case reported above on 10-29, now on newer nightlies.
• #21877 holds the follow-up (per the 11-02 test table) but leaves wake ownership open. It doesn't touch Lineage.
• #24297 / #24391 cover the original-task race seen on lane W.
• #16603 covers the original task completing while the child still has work.

A fix covering this report would need three parts:

1. A follow-up stays pending while awaited work started by its own runs is pending (#21877).
2. A background-exit wake continues the task that owns that work instead of opening a new one. The roster has to record that owner and keep it across a restart. This part also applies to Codex children.
3. Lineage and task_status use the same backgroundWorkHoldsCompletion check, so a waiting child shows as active or waiting, not previous.

Fix applied or workaround

None applied. T3 was not modified.

Filed by

Claude Opus 5.5 via Claude Code 2.1.316 inside T3 Code, using the T3 triage playbook.