[Bug]: Cancelling a delegated task leaves its Claude native subagents running forever (task stuck waiting_for_children) #17154

Activity

1. juliusmarminge commented on Oct 8, 2026

   

   juliusmarminge

   on Oct 8, 2026

   Member

   More actions

   Note

   Grok responding on behalf of Julius.

   Thanks for the detailed report and the projection dumps. I checked this against main at 37eaf5d. I haven't reproduced it locally, but the code has a gap that fits what you saw.

   What task_cancel does

   • task_cancel dispatches thread.stop on the child, then stopDelegatedTasks for the app-owned tasks under it (OrchestratorMcpService.ts#L2005-L2034). A task in waiting_for_children always passes the "cancellable" check (#L2070-L2078), so a second cancel is accepted but has nothing to act on.
   • thread.stop interrupts a running run. If no run is running, it targets the latest run only when derivePendingBackgroundWork still lists something (Orchestrator.ts#L9034-L9048). Otherwise it just records the stop and holds the thread (#L9080-L9092).
   • With a live session, the interrupt only queues provider-turn.interrupt (Orchestrator.ts#L8991-L9006). After the adapter call returns, the worker dispatches thread.background-work.settle (EffectWorker.ts#L165-L195).

   Where the native subagents likely fall through (from reading the code)

   • dispatchBackgroundWorkSettle calls settleInterruptedRun only when the stopped run is still running (Orchestrator.ts#L8584-L8599). settleInterruptedRun is the path that cascades a terminal status to run-owned native subagent rows and nodes (#L8279-L8317), and even then only for subagents whose runId is that run.
   • Otherwise it falls through to settleBackgroundWork. That marks pending background turn items interrupted (including subagent items) and clears the roster (Orchestrator.ts#L8134-L8191). It emits no subagent.updated or node.updated, so the linked orchestration_v2_projection_subagents row and the subagent node stay running.
   • The live-turn interrupt cascade in RunExecutionService likewise covers only subagents reported with runId === run.id while that run's ingestion is still open (RunExecutionService.ts#L629-L638, #L1041-L1056).
   • The Claude adapter doesn't fill that gap. Stop on a settled turn closes the CLI process and resets the roster (ClaudeAdapterV2.ts#L7652-L7678), and on query exit it ends the subagents' open tool calls (#L4953-L4968, #L7434-L7442). It never emits a terminal subagent.updated for the tasks in sessionSubagentsByTaskId, so they also stay running in the session registry (#L7845-L7849).

   Startup recovery already handles this case. Its comment says "Cancelling only the turn item would leave the linked subagent entity non-terminal forever", and it cancels the linked subagent row and node along with the item (ProviderRuntimeRecoveryService.ts#L489-L529). The Stop settle path has no equivalent.

   Why it then stays stuck

   • delegatedTaskProgress returns waiting_for_children whenever any subagent row on the child is active, whatever its origin (SubagentProjection.ts#L237-L256), and task_status reads the child's subagent rows directly (OrchestratorMcpService.ts#L1234-L1243). That matches your running / waiting_for_children / hasPendingChildRuns: false / latestTerminalStatus: completed output.
   • Stop, the thread list and t3_thread_interrupt look at runs, turn items and the roster instead. derivePendingBackgroundWork explicitly "does not consult subagent entities" (orchestrationV2PendingBackgroundWork.ts#L186-L222). Once the turn items are interrupted there is nothing for a later Stop to target, which likely explains no_active_run and a second task_cancel doing nothing.

   My best guess at your sequence: the child turn had already settled with the native agents still running in the background, so Stop took the settled-run path above. I couldn't confirm that from the dump alone. If it holds, a restart may not clear it either, because recovery's stale sweep keys off non-terminal turn items, and those were already marked interrupted.

   Related

   • fix(server): Claude subagents from a closed process no longer stay running #16814 (open) is the closest fix. It makes the Claude adapter interrupt subagents left by an earlier, closed process, but only when the next turn starts on a new process. A stopped delegated child is held and never gets a next turn, so on its own it likely wouldn't clear this case.
   • [Bug]: Cancelling a background-only delegated task reports completed with an interim summary #16739: the same "provider turn ended, background work pending, then cancel" shape, with a different symptom (the task reports completed).
   • [Bug]: Nested Claude subagent stays Running after the SDK reports it completed during a user turn #16355 (lost nested completion), [Bug]: Provider turn projection stays running after T3 ends the turn #16557 (provider turn projection), Delegated task reports finished while its child thread still has running work #16603 (task finishes too early) and [Bug]: Claude background subagents stay Running forever when their wake continuation runs on another provider #17099 (subagents stuck when the wake runs on another provider) are nearby but have different causes.
   • fix(orchestration): reconcile stale delegated task and held queue state #15201 changes delegatedTaskProgress for held queues but not how native subagent rows are settled.

   Suggested fix (untested)

   In settleBackgroundWork (Orchestrator.ts#L8134-L8164), when a subagent turn item is interrupted, also emit subagent.updated (status interrupted) for the linked non-app-owned row and node.updated for its node, the way startup recovery does. Do the same for open provider_native rows on the stopped thread whose turn item is already terminal, so state that's already stuck gets repaired by the next Stop. #16814's adapter-side cleanup could then also run when Stop closes the process (ClaudeAdapterV2.ts#L7665-L7677), not only at the next turn start. A regression test should cover a Claude child that settles with background native agents and is then cancelled via task_cancel, asserting the subagent rows and nodes end terminal and the task reaches a terminal state.
2. juliusmarminge

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Oct 8, 2026
3. im-kvijay

   added a commit that references this issue on Oct 8, 2026

   test(server): cover task_cancel and deeper native subagent chains

   ...

   5d8256c
4. Yash-Singh1

   closed this as completedin #17223on Oct 10, 2026