fix(server): keep Claude subagent output in the subagent's thread

[scratchyone]

When Claude runs a subagent through its built-in Agent tool, the subagent's narration, final report, and often its tool calls show up in the parent thread. It's worst with background subagents: once the parent's turn ends, the parent chat fills with another agent's work, while the subagent's own thread shows only a few commands and a result.

Claude sends subagent output in the parent's stream, tagged with parent_tool_use_id. ClaudeAdapterV2 handled that tag in three places, each wrong in a different way:

• Assistant messages ignored the tag, so subagent text always went to the parent.
• Tool calls found their subagent through a map that belongs to the current turn. After the parent's turn ends, background subagent output is buffered and replayed into a new turn whose map is empty, so those tool calls went to the parent too.
• Output that arrived before the subagent's task_started had nowhere to go.

Fix

• Session-wide lookup: a session-lived index maps tool-use id → subagent, resolved through the session registry, which always holds the current subagent entry. Tool calls, text, and model snapshots all use it.
• Text routing: subagent assistant text now goes into the subagent's thread.
• Early output: output that arrives before its subagent is known is held, then replayed as soon as any task_started, task_progress, or task_notification frame names the subagent. Frames are replayed before a notification is handled, so they land ahead of the result. Replayed frames skip turn-level bookkeeping (retry recovery, message cursor), which already ran when they first arrived.
• Subagents started while the parent is idle: their task_started is now kept in the wake buffer, so their output has an owner when the buffer is drained.
• Result dedupe: the subagent's final message is shown once. The separate result message is skipped when it matches the last message (content blocks with the same native message id are joined first). Failed and cancelled results always show.

Subagents started through T3's delegate_task weren't affected, since they run in their own sessions.

Testing

Transcript replay: a new replay fixture, claude_background_subagent_after_root, replays a recorded Claude session in which a background subagent narrates and runs commands after the root turn ends, then wakes the root. Its output reaches the adapter through the wake buffer and drains into the continuation run, the path where it leaked. The fixture fails on the previous adapter (SUB_STEP_1 leaked into the parent thread) and passes with this fix.

Replay fixtures previously could not reach that path: the replay runtime never ran the continuation worker, so wake requests were dropped and no fixture got past its first run. A separate commit adds an opt-in runContinuationWorker flag that wires in the production worker (off for every other fixture), lets the Claude recorder capture the wake turn, and lets await_run_status also wait for a turn item.

Adapter tests cover the ordering cases a recording can’t pin down reliably:

• a subagent started while the parent is idle
• output that arrives before task_started
• a tool-use id first named by the notification
• a replay that must not resolve a newer API retry
• a final message split across content blocks
• a subagent update without a tool-use id

Each fails when its part of the fix is reverted. All replay fixtures, the replay contract tests, the Claude adapter suites, and the other harness consumers pass, and the server typecheck is clean.

Checked in a real client with Claude Opus 5.5, one background subagent running four steps.

Before:

before.mp4

After:

after.mp4

Model: Claude Opus 5.5 (Claude Code), reviewed by GPT-6 Astra (Codex)

🤖 Generated with Claude Code

[macroscopeapp]

Approvability

Verdict: Not approved

Macroscope's review found this PR not approvable — The production adapter changes existing Claude subagent routing across live turns, background wake drains, lifecycle events, retries, and result rendering, backed by substantial new state and replay logic. Although the added tests cover several race scenarios, the cross-turn runtime impact and implementation complexity warrant human review.

^{You can add or adjust custom eligibility rules. Learn more.}