Delegated task reports finished while its child thread still has running work

Area: apps/server

Steps to reproduce

From a parent thread, delegate_task to a Codex child that starts a long-running shell command (a bot, a test watcher) and ends its turn without waiting for it.
Read task_status, or look at the parent once it settles.

Expected: The task stays in progress (or reports waiting_for_children) while the child's command is still running, and the parent stays Waiting.

Actual: The task finalizes as completed / result_available and the parent can settle to Done, while the child thread still has a running command_execution item and the process is alive. delegatedTaskProgress (SubagentProjection.ts:207-259) checks runs, subagent entities and the provider roster, but not active turn items, and finalizeAppOwnedSubagent (Orchestrator.ts:8472-8488) finalizes on that result.

A related path: t3_thread_send into an already-finalized child (ThreadManagementService.sendToThread) starts new runs there, but the parent task stays completed and its later result is never delivered (OrchestratorMcpService.ts:1058-1077, Orchestrator.ts:8537-8546).

Evidence (0.0.46-nightly.20261004 state DB): 3 of 145 completed delegated tasks since Oct 1 finalized while their child had live command items (2 still running now, one confirmed alive with pgrep). 5 later runs across 3 finalized children.

Possible fix: include pendingBackgroundTurnItems({ turnItems, runs }) in delegatedTaskProgress (and load turn items in both callers), retrying finalization when those items end. For the send path, reject sends into finalized app-owned children or reopen task tracking.

Impact: Minor bug or occasional failure.

Note

Grok responding on behalf of Julius.

Confirmed on current main: an app-owned delegated task can finalize as result_available / completed while the child still has live background command_execution work.

Main bug

delegatedTaskProgress decides working / waiting_for_children / result_available from:

non-terminal work runs
active child subagents / pending completion delivery
provider-thread pendingBackgroundTasks

It does not look at active turn items. finalizeAppOwnedSubagent loads the child without turnItems, calls that helper, and finalizes as soon as progress.state === "result_available".

So a Codex child that starts a long-lived shell (countsForRun: false / turn ends without waiting) can look “done” to the parent while the process is still alive — matching the state-DB evidence in the report.

The shared pendingBackgroundTurnItems helper already exists and is used elsewhere in the orchestrator (e.g. interrupt cleanup). It is the natural check to fold into delegatedTaskProgress (with callers loading turnItems).

Secondary path (distinct)

t3_thread_send into an already-finalized child can start new runs without reopening parent task tracking / delivering the later result. That overlaps open #13490 and open PR #15004 (follow-up result delivery). Those do not fix the premature-finalize case above.

Loosely related: #13625 (completion sound while background work runs), #15993 (stale background banner).

Fix direction: include pendingBackgroundTurnItems({ turnItems, runs }) in delegatedTaskProgress (and load turn items in both finalize / status callers); keep finalization deferred until those items end. Separately, for send-into-finalized-child, either reject or reopen tracking (coordinate with #15004).

Labeling bug + via-triage.

Additional user-observed scenario with nested subagents:

Root thread: completed
`-- Subagent A: completed
    `-- Subagent B: still running

From the original root thread, the remaining descendant activity is not visible, so the delegated workflow appears finished while B continues working.

This is an observation, not an independently reproduced case. It is unclear whether it has the same underlying cause as the command_execution gap described above.

Consolidating the related report from #16902 here to avoid parallel tracking.

Same outcome with a Claude child, on 2026-10-20. The open work here is a native background subagent, not a shell command. The machine's installed runtime is 0.1.1-nightly.20261019.3373.

18:23:32Z: the parent sends the child a follow-up with t3_thread_send. T3 tracks it as a delegated task.
18:24:11Z: the child launches a background subagent. T3 writes a record for it on the child in orchestration_v2_projection_subagents (origin: provider_native, status: running).
18:31:45Z: the child's turn ends with "I'm waiting on two things in the background: the price-research child and a watcher for its output file."
18:31:45Z: T3 finalizes the delegated task and delivers its result to the parent. The record for the child's subagent still reads status: running.
18:35:59Z: the child's subagent completes.

The issue body says delegatedTaskProgress checks subagent entities. This record read status: running when T3 finalized the task. The parent agent learned the work was unfinished only from the child's final text, and sent another follow-up at 18:31:57Z.

Triage read the report and follow-up, scanned all 949 open issues, and inspected current main at a12d6ed942. No earlier duplicate identified; #21837 covers a related follow-up lifecycle. Runtime reproduction was not attempted. This requires maintainer review under the automated triage restriction on MCP tool-surface changes: the requested behavior changes delegated-task completion returned by task_status and follow-up handling through t3_thread_send. No code changes or PR.

Additional observed case on 2 November 2026: a delegated implementation agent displays Done while its required asynchronous review delegate is still running. Adding here because #16902 explicitly consolidated this nested-descendant visibility case into #16603.

Steps observed

An implementation coordinator launches a required asynchronous review with delegate_task.
The host result instructs it: "Completion wakes this thread, so end your turn. Do not wait on it or poll it."
The coordinator ends its turn awaiting that review.
Open Lineage while the review remains active.

These steps describe the supplied live-session evidence. No fresh isolated reproduction was run.

Expected behavior

The aggregate workflow status remains pending, for example Waiting for review/delegates, while a required descendant is active. The parent agent's completed turn can remain visible separately. Active required descendants should remain discoverable from ancestors.

Observable acceptance:

Aggregate status remains pending during required child activity.
It transitions correctly when that child completes, fails, or is cancelled.
A terminal parent-turn status remains distinguishable from completion of the delegated workflow.

Actual behavior and evidence

A screenshot from the implementation conversation shows "Lineage · 1 running", the implementation parent marked Done, and its required Opus review still running at about 16 minutes elapsed.
A separate root-conversation screenshot shows only direct previous agents. This supports a related nested-descendant discoverability concern; it does not establish the same underlying cause as the Done ambiguity.
The main coordinator's read-only T3 thread inspection confirmed an active claudeAgent / claude-opus-5-5 run with a parent relation to the ended implementation delegate. Completed command activity was recorded at 14:01 AEDT, UTC+11, on 2 November 2026. That command completion is not evidence that the review itself completed.
The required source milestone remained pending at observation time.

This is evidence of user-visible pending-work/status ambiguity. It does not establish premature backend task finalization, a reducer defect, lost tasks, cancelled work, or failed completion delivery. Root cause is unknown.

Environment and version limits

T3 Code on Linux, with nested T3 asynchronous delegation and a Claude Agent Opus 5.5 reviewer. Read-only installed metadata identifies CLI runtime 0.1.4-nightly.20261028.3814 and desktop package 0.1.3-nightly.20261023.3566. These are installed versions, not a verified binding of the screenshot or active server to either version; the exact affected running build is unknown.

Impact and workaround

Users can mistake an ended parent turn for finished work and lose visibility of a required pending review. No verified UI workaround. The supplied evidence distinguishes parent-turn completion from outstanding review work; no claim is made that execution stopped.

Related reports and scope

#27126 concerns an async delegate hint stopping otherwise independent work. Here the review is required and ending the turn is expected; this report concerns the displayed aggregate state. #27700 concerns native Claude subagent background commands/monitors. This case uses a required T3 asynchronous review delegate, without assuming the same cause.

Sanitized text only. Private screenshots, transcripts, task identifiers, repository details and machine paths are intentionally omitted. No implementation, task cancellation, restart, or monitoring was performed for this report.

Same bug with a Claude child, on 0.1.7-nightly.20261102.4066 (macOS, Claude Code 2.1.316, Claude Opus 5.5). The report above uses a Codex child.

Steps observed

A Claude parent starts a child with delegate_task, isolation: "worktree", mode: "async".
The child starts a long script with Bash run_in_background and ends its turn with the message "Waiting for background task <id>, the final evidence run."
The parent calls task_status.

Result

While the script was still running, task_status returned:

{
  "status": "completed",
  "workState": "result_available",
  "hasPendingChildRuns": false,
  "latestTerminalSummary": "Expect: about 25 minutes and little plan usage. Waiting for background task `<id>`, the final evidence run."
}

At the same moment, on the machine, the script's process and the child's claude process were alive, and the child had not pushed its branch.

The parent was woken with a [completed] message whose whole text was the waiting line. The same thing happens on every turn the child ends while it waits: in this session four workers sent about 15 [completed] messages between them that were not final results. Each background completion starts a new child run through a provider continuation, and that run delivers another [completed].

Impact

A parent has no reliable way to tell a finished child from a waiting one. Here both the parent agent and the person watching the app read a running worker as done. The parent has to inspect the child's checkpoint or processes to find out.

Not tested

I did not check whether calling t3_background_wait inside the child changes this. I did not run a patched build.

Related: #27700 covers the same state for native Claude subagents, and anthropics/claude-code#92952 covers the completed status it comes from.

Written with Claude Opus 5.5 in T3 Code.

Same nested case on v0.1.6 (Linux desktop app), with counts from one long-running session. All delegates were started with delegate_task. The parents were Claude Opus 5.5, and the children were a mix of Claude and an ACP provider.

Observed

root: latest run completed, no active run, 72/72 subagent records completed
├─ orchestrator A: latest run completed → review delegate: running
├─ orchestrator B: latest run completed → build delegate: running; review delegate: running
└─ orchestrator C: latest run completed → mapping delegate: running

From the code, the root row should read as finished: its status comes from its own runs and its own unfinished records, and nothing here is active. I read this from the state database and the source, and did not capture the sidebar itself.

Two paths, both in the state database

A follow-up closes while its nested work runs. In finalizeAppOwnedSubagent, only the original task is held back by progress.state. Example from orchestrator C:

12:09:07.563  orchestrator opens a nested delegate
12:09:17.934  orchestrator's run ends
12:09:18.449  root's follow-up record closes as completed; the nested delegate is still running

A run starts with no root record open. Orchestrator A's last root record closed at 10:31:31. A nested completion woke it at 12:06:13, and it opened a new delegate at 12:06:36. The root had no open record for any of this.

Orchestrator	Root records closed while a nested record was open	Runs with no open root record
A	26 of 29	110 of 166
B	10 of 13	49 of 67
C	17 of 21	45 of 96

These compare timestamps across each orchestrator's own records. They count overlaps, and don't show that each overlap was visible in the UI.

Related work

Path 1 looks like what #21877 addresses, and path 2 looks like what #28462 addresses. I have not run a build with either PR, so I can't say whether the two together keep the root in a pending state for this whole tree.

Written with Claude Opus 5.5 in T3 Code.

Another case with a Claude child on v0.1.6 on Windows, using mode: "async", isolation: "shared". The child's own final message says it isn't finished, but the task and the thread read as done.

What happened. A child started a background Bash watcher, then ended its turn with this message:

W6 isn't finished: nothing has been submitted yet... Background watcher bqkvktnji checks both local files every 2 minutes, for up to 2 hours, and wakes me when the gate opens, the suite fails or it times out.

The parent received Delegated task ... [completed] with that text. t3_thread_read shows the thread as status: completed, activeRunId: null, runCount: 1, and t3_thread_list with statuses: [running, starting, queued, waiting] doesn't list it, while the watcher it describes is meant to still be alive.

Why the status can't be relied on, in the same session. Two sibling children showed the same completed state after similar turns and then woke up later and did real work:

One submitted 30 cluster jobs under a later provider-continuation task ID, after its original task had reported completed.
Another woke up several more times on its own, reported state changes and resubmitted a failed job.

So completed can mean either "finished" or "waiting on my own background work", and the parent can only tell by reading the child's prose.

The practical cost. A parent seeing completed on unfinished work starts a replacement, which then risks duplicating the original if it wakes. I had to start a replacement for this child with no way to confirm the first wouldn't resume. For long fan-outs this also produces many [completed] notifications carrying interim text such as "Waiting for the retry to report back."

Expected. As this issue describes: waiting_for_children or similar while a child has live background work, including Claude run_in_background commands, and a final completed only when it has really ended.

test(server): reproduce a follow-up task finishing while the child's …

fix(server): keep follow-up tasks pending until nested work finishes

Same bug with a Claude child on 0.1.6-nightly.20261031.3977 (macOS 27.0.1 arm64, desktop app on a local server). This adds what it does to the parent's Lineage panel.

Observed

A Claude Opus 5.5 parent started a Claude Opus 5.5 child with delegate_task (isolation: "worktree").
The child started long test runs with Bash run_in_background, called t3_background_wait on them, and ended its turn. It woke and carried on each time a run finished.
In orchestration_v2_projection_subagents, every task record for the child read completed / delivered, one per turn. Each was written while the child's background runs were still pending; four of its test processes were alive on the machine at the time.

What the parent's Lineage panel showed

While the child was working, the parent's thread details panel showed no active agent. Lineage showed only a collapsed "Previous agents · 1 failed · 194", with the live child folded in among the finished ones. The child's own panel listed the parent correctly.

From the source (checked against main at c52df24), this follows from the task status:

Between turns the child has no live run, so its activityRunStatus is null. The subagent edge's status in deriveThreadRelationshipGraph (packages/client-runtime/src/state/threadRelationships.ts) then falls back to the child's completed status, because the subagent record is no longer active.
ThreadRelationshipsPanel (apps/web/src/components/chat/ThreadRelationshipsControl.tsx, the groupBy that returns "previous") puts every subagent edge with a settled status under "Previous agents".

So if the subagent record stayed running while the child waits on its own background work, the edge would take that status and the child would stay in the active list. The Lineage symptom should not need a separate client fix.

Observed in a live session, not reproduced in isolation.

Filed by Claude Code (claude-opus-5-5) inside T3 Code, following .github/triage/PLAYBOOK.md.