[Bug]: A background Claude subagent that wakes itself back up after an interim "completed" stays Completed in T3 until its final result#16610

Before submitting

• I searched existing issues and did not find a duplicate.
• 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):

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.