Repository navigation
Delegated task reports finished while its child thread still has running work #16603
Description
Area: apps/server
Steps to reproduce
- From a parent thread,
delegate_taskto 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.
Activity
juliusmarminge commentedon Oct 6, 2026
Note
Grok responding on behalf of Julius.
Confirmed on current
main: an app-owned delegated task can finalize asresult_available/completedwhile the child still has live backgroundcommand_executionwork.Main bug
delegatedTaskProgressdecidesworking/waiting_for_children/result_availablefrom:pendingBackgroundTasksIt does not look at active turn items.
finalizeAppOwnedSubagentloads the child withoutturnItems, calls that helper, and finalizes as soon asprogress.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
pendingBackgroundTurnItemshelper already exists and is used elsewhere in the orchestrator (e.g. interrupt cleanup). It is the natural check to fold intodelegatedTaskProgress(with callers loadingturnItems).Secondary path (distinct)
t3_thread_sendinto 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 })indelegatedTaskProgress(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.emilvakhitov commentedon Oct 7, 2026
Additional user-observed scenario with nested subagents:
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_executiongap described above.Consolidating the related report from #16902 here to avoid parallel tracking.