Parent leaves Working when a resumed child waits on its own delegated work #30395

Activity

1. rafaeltab

   added

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Nov 3, 2026
2. nuuls commented on Nov 10, 2026

   

   nuuls

   on Nov 10, 2026

   More actions

   Same bug here with Claude (Fable 5.2, then Opus 5.5) on a three-level delegate_task chain, main @ 6c9adfb. Adding it because it shows the gap isn't Codex-specific, and that it covers grandchildren started from follow-ups, not only a single resumed child.

   Setup. A (top-level coordinator) delegated to B; B delegated to C1 and C2. All app-owned, all on one machine. A's original delegate_task for B had finished the day before, so everything below runs through follow-ups.

   What I saw. For over an hour, A showed as Done in the sidebar, chat, and mobile while C1 and C2 were working and B kept waking up to send them more work. Nothing on A said anything was still running, and A's lineage row for B said Done. A's agent was never woken again either, so it never heard about the later results (that half looks like #21837).

   Timeline (UTC, 2026-11-10, from a read-only copy of the state DB):

   11:45:08-11:45:45  A gets a follow-up row for a B run (a "Background command finished" notification).
                      It closes when that run ends, while C1 (since 11:32) and C2 (since 11:40) keep running.
                      From here on A shows nothing for them.
   11:53-12:09        Usage limit hits all four threads. Each automatic "Continue where you left off."
                      gets a (failed) row in its parent, so that part is tracked fine.
   12:11              A messages B after I switched to Opus      -> row in A, closes 12:15
   12:14              B messages C1 and C2                       -> rows in B
   12:45:51-12:46:02  A's last follow-up row for B (another background-command notification run) closes.
   12:46:04           A's turn ends.
   12:46:19           C2 completes -> B woken by a delegatedCompletion run. No row in A.
   12:46:26           B sends C2 another pass                    -> row in B
   13:16:26           Another delegatedCompletion wake in B, no row in A. B sends C1 another pass at 13:16:37.
   ~13:54             Chain finishes. A showed no running work from 12:46 on, and never ran again.
   

   Why (agrees with the diagnosis above):

   • Only the original task waits for nested work before it finalizes (finalizeAppOwnedSubagent). A follow-up task finalizes as soon as its bound run ends, even when that run left subagents running.
   • B's later runs are delegatedCompletion wakes (agent/server, no notification, no sender), which mayStartSubagentFollowup and recordSubagentFollowup never turn into a parent row.
   • On the client, thread shells are per thread. Approvals already roll up the chain (pendingSubagentRequestsByThread), but running work doesn't, so A has nothing to show once its own rows close.

   From reading the code, a subagent picked back up after a server restart (restartContinuationOfRunId) is excluded the same way. I haven't reproduced that one.

   Steps to reproduce (any provider; these mirror the live incident, I haven't run them in isolation):

   1. In thread A, delegate_task an async child B with a trivial task. Let A and B both finish, so the original task is done.
   2. From A, t3_thread_send to B: "Use delegate_task to start two async subagents. Each runs sleep 120 in the foreground and replies DONE. After dispatching, end your turn without waiting or polling. When a completion wakes you, reply GOT_ONE."
   3. Let A end its turn.
   4. While the grandchildren sleep: A shows Done in the sidebar, chat, and mobile thread list, with no background-work indicator, and A's lineage row for B says Done. B shows Waiting; the grandchildren show Working.
   5. When the first grandchild finishes, B wakes and runs. A still shows nothing and gets no row for that run.

   Expected: A shows that work is still running below it until the last descendant ends, as it already does while the original task is open. The sidebar docs say subagents keep a thread in Working.

   Fix. I have a fix ready. It's a client-side roll-up in client-runtime that does for running work what pendingSubagentRequestsByThread already does for approvals. A thread lists a subagent child as background work while that child, or anything under it, is still running and the thread's own rows no longer cover it. The entry clears when the last descendant ends. It covers web, desktop, and mobile, has tests that fail on main, and is running on my machine now against the chain above.

   It's around 230 lines across client-runtime, web, and mobile, so I wanted to ask first: would you take it as a PR? Or would you rather fix this on the server by keeping follow-up tasks open until nested work settles? That route would also cover task_status and result delivery (#21837), which a client-side roll-up doesn't.

   Investigated with Claude Opus 5.5 (Claude Code in T3 Code).
3. nuuls

   added a commit that references this issue on Nov 12, 2026

   fix(client-runtime): parents show nested subagent work that is still …

   ...

   59a0cb3
4. juliusmarminge commented on Nov 12, 2026

   

   juliusmarminge

   on Nov 12, 2026

   Member

   More actions

   This is the same problem as #21837, so I'm closing it in favour of that one. If it is different, say how and it will be reopened.
5. juliusmarminge

   closed this as duplicateon Nov 12, 2026