[Bug]: "Waiting on subagent" chip never clears after the SDK reports the subagent stopped, and Stop does nothing #17847

Activity

1. juliusmarminge commented on Oct 10, 2026

   

   juliusmarminge

   on Oct 10, 2026

   Member

   More actions

   Note

   Grok responding on behalf of Julius.

   Thanks for the detailed report. I read through main (read-only). Here's what I found. Line numbers are approximate.

   stopped is treated as terminal. In apps/server/src/orchestration-v2/Adapters/ClaudeAdapterV2.ts (~L3408), claudeTaskOutcome maps SDK stopped to cancelled. So your first guess, that stopped isn't treated as terminal, doesn't look like the cause.

   The notification probably can't find the node. opaqueTaskWakeReport (~L3411) looks up the task_id only in in-memory per-process maps (pendingBackgroundTasksByNativeThread / lastKnownOpaqueTasks). After a restart, or a handoff to another Claude provider instance, those maps start empty. The task then resolves to undefined and is reported as a generic command with no childThreadId. If that's right, nothing settles the persisted subagent node, so the projection keeps it running and the chip stays. That fits your second guess, that the node is orphaned by the session or instance change. I haven't reproduced it, though.

   Why Stop is a no-op. ProviderTurnControlService.interrupt routes a subagent Stop to the adapter's stopSubagent (~L8101). That function looks the task up in the in-memory sessionSubagentsByTaskId and does return when it isn't there. That's a silent success: no error, and nothing settles the projected node. It errors only when the subagent is known but has no live owning query. So for a subagent from an earlier process or instance, Stop seems to do nothing, by design. Unlike the turn-level Stop, which has a follow-up that settles the projection, nothing repairs the stale subagent row afterwards.

   Likely fix direction (unverified): fall back to the persisted node when a task_notification arrives for an unknown task_id, and/or have Stop settle a subagent node in the projection as cancelled when no live query owns it. Another option is to sweep subagent nodes whose owning provider session is stopped or error.

   Related: #16355 (same stale-Running symptom after completed), #17154, #14802, #12694, closed #7585. Open PRs #16852 and #16022 may touch nearby code. I haven't checked whether either covers the unknown-task or orphaned-node path.
2. juliusmarminge

   added

   via-triageFiled through npx t3 triageFiled through npx t3 triage

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

   on Oct 10, 2026
3. SamuelFranks commented on Oct 10, 2026

   

   SamuelFranks

   on Oct 10, 2026

   More actions

   Same symptom on T3 Code (Nightly) 0.0.46-nightly.20261010.2908 (macOS, Claude provider, Opus 5.5). Two details differ from the original report:

   • No server restart and no instance handoff. The T3 server has been up since 2026-10-09 19:59 MDT (server-runtime.json startedAt 01:59:30Z). Only the thread's Claude session was replaced: a new claude process started 2026-10-10 09:28 MDT on the same provider instance. So the server-side maps weren't reset by a restart here, if they live for the server's whole lifetime.
   • The orphan is a Workflow-tool task, not an Agent call. The timeline item task:wi53hrhb5:subagent (type subagent, text "Prepare: prepare") still reads running. It was last updated 2026-10-10T02:37:42Z, and its run (ordinal:16) is completed.

   On the new session's first turn, the SDK delivered <status>stopped</status> for wi53hrhb5 ("didn't finish before the previous session ended"). The item stayed running, and the sidebar still shows it as a subagent running for 12+ hours. No process for it exists. TaskStop("wi53hrhb5") in the new session returns No task found with ID: wi53hrhb5, so the agent can't send a stop either. A new workflow run in the same thread started normally beneath it.
4. jameswasher commented on Oct 10, 2026

   

   jameswasher

   on Oct 10, 2026

   Author

   More actions

   Timeline (UTC), to rule out the provider-instance handoff as the cause:

   • 2026-10-05 17:41: background subagent launched (Claude instance A).
   • 2026-10-06 00:22: last write to the subagent's transcript; the session process ended with it unfinished.
   • 2026-10-06 13:28: same instance A resumes and the SDK delivers task-notification with status: stopped.
   • 2026-10-06 17:30: thread handed off to Claude instance B.

   So the stale chip already existed while the thread was still on instance A. The stopped notification arrived on the original instance about 4 hours before the handoff and still didn't clear it.