# \[Bug\]: A background Claude subagent that wakes itself back up after an interim "completed" stays Completed in T3 until its final result · Issue \#16610 · pingdotgg/t3code [View on GitCafe](https://git.cafe/pingdotgg/t3code/issues/16610) Repository: [pingdotgg/t3code](https://git.cafe/pingdotgg/t3code) Visibility: public State: backlog Priority: 0 ## Description [Discussion and activity](https://git.cafe/pingdotgg/t3code/issues/16610) --- ### Before submitting - [x] I searched existing issues and did not find a duplicate. - [x] I included enough detail to reproduce or investigate the problem. ### Area apps/server ### Steps to reproduce 1. In a Claude thread, send: > Call the Agent tool once: subagent_type "general-purpose", run_in_background true, description "Repro self-resume", prompt: "Run Bash with run_in_background true: python3 -c 'import time; time.sleep(30)'. Then end your turn with exactly: WAITING. When the background command's completion notification arrives, make 4 Bash calls one after another, each running python3 -c 'import time; time.sleep(15)', then reply with exactly: DONE_SELF". After the Agent call returns, reply with exactly LAUNCHED and stop. 2. When the subagent replies WAITING, Claude Code sends a `completed` task_notification for it. The model-facing text says "This agent stopped with background work of its own still running. It may resume on its own ... the same task-id notifies again if it does; the result below may be interim." 3. Let the parent answer that notification and go idle. Optionally send one or two short user messages while the subagent runs (this matches the original case). 4. Watch the subagent's card, the Lineage panel and the child thread for the next ~90 s. ### Expected behavior When the subagent resumes, its card and Lineage row go back to Running, and its new steps show in its thread as they happen. Claude Code signals the resume: it emits a new `system/task_started` with the same `task_id`, the same original `tool_use_id` and a new `run_id`. ### Actual behavior T3 shows the subagent as Completed with the interim summary for its whole resumed run, and its new steps don't appear. Only when the final `task_notification` wakes the parent does T3 apply the re-open and the completion, 44 ms apart. From my session (T3 provider event log plus `statev2.sqlite`, UTC): ```text 21:10:02.876 SDK task_started task=ab0a03c31e28e79db run_id=…6bb8419b is_backgrounded=true 21:48:55.791 SDK task_updated {status: completed} + task_notification completed summary: "I'll wait for the completion notification." (interim; its background Bash b6ciwiovd still running) 21:48:58.863 T3 subagent.updated status=completed 21:49:01 parent run 21 (continuation) completed -> root idle 21:49:09.768 SDK task_notification b6ciwiovd completed (the subagent's own background Bash) 21:49:09.786 SDK task_started task=ab0a03c31e28e79db run_id=…b97d0b33 (NEW) tool_use_id= 21:49:14-21:53:26 ~20 subagent assistant/user frames (parent_tool_use_id = Agent call) 21:51:22, 21:52:03, 21:52:52 parent runs 22-24, all user-message runs 21:53:26.206 SDK task_notification completed (final) 21:53:26.256 T3 subagent.updated status=running <- re-open applied 4m16s late 21:53:26.300 T3 subagent.updated status=completed ``` The user saw the subagent as finished or gone ("I don't see any subagents") while it kept running tools and writing its transcript. Cause, from `main` at f4f148eb (`apps/server/src/orchestration-v2/Adapters/ClaudeAdapterV2.ts`): - With no active turn, `handleSdkMessageFrame` sends every frame to `bufferWakeMessage` and returns (~L5664-L5685). That includes the resume `task_started`, which is the only signal that the subagent is running again. - The resume `task_started` is not wake evidence, so it doesn't start a continuation (offer gate ~L5375-L5395). - User-message turns skip the wake buffer by design (`if (userMessage !== null)`, ~L7346), so runs 22-24 left the re-open in the buffer. - The re-open logic itself works (`task_started` -> `updateClaudeSubagentNode({ status: "running", reopen: true })`, ~L6057-L6067, and the reopen branch ~L4129-L4146). It only runs when a continuation drains the buffer, and in this flow that happens when the subagent's final completion arrives. - `task_updated` frames are not consumed at all. Claude Code doesn't send a `task_updated {status: running}` on the resume, so the `task_started` is the signal T3 needs to handle. Not covered by #16486: that PR projects a running subagent's own frames while the root is idle, but it explicitly keeps `task_started` in the wake buffer and holds that subagent's frames behind a buffered start ("This covers a resume ... whose task_started arrives after settle"). In this flow the subagent is terminal when its `task_started` arrives, so after #16486 it would still show Completed, with its resumed work held until the final notification. A possible fix: while the root is idle, apply a `task_started` at once when its `task_id` is a known, terminal, session-registered subagent and its `tool_use_id` is the subagent's original launch call (a self-resume, not a `SendMessage`). Re-open the node under the run that owns the child thread and route its later frames live, as #16486 does for running subagents. Separately, consider showing a `completed` notification as "waiting on its own background work" instead of final. The SDK frame carries no structured interim flag (only the model-facing text does), but T3 already tracks the subagent's own `local_bash` tasks. Related: #16484 / #16486 (frames frozen while root idle; same buffer), #16355 (completion dropped across a user turn; same buffer + user-turn skip), #16261 (resumed subagent's child thread ownership), #16598 (/goal reads complete while a background subagent runs; same "turn ended or completed is not terminal" theme), anthropics/claude-code#97696 (Monitor-driven self-resume doesn't happen at all on the Claude side). ### Impact Major degradation or frequent failure ### Version or commit T3 Code Nightly 0.0.46-nightly.20261006.2735 (fd1c3386c4d6); `main` at f4f148eb has the same code ### Environment T3 Code desktop nightly on macOS (Apple silicon), orchestrator v2, Claude provider, Claude Code 2.1.292, parent and subagent Claude Opus 5.5 ### Logs or stack traces See the timeline above (provider/events..log and orchestration_events). ### Screenshots, recordings, or supporting files _None_ ### Proposed fix PR #16609 keeps such a subagent running (using the `parent_task_id` ownership Claude reports) until it resumes, and settles it at the next turn if its work ends without a resume. ### Workaround Use T3 `delegate_task` for long-running child work, or tell native subagents not to end their turn while their own background commands run (run them in the foreground, or poll). Reading `~/.claude/projects/.../subagents/*.jsonl` shows the real progress.