[Bug]: Claude's per-line Monitor wakes are tagged background_task, so each one wakes a delegated child's parent

Start in apps/server/src/orchestration-v2/Adapters/ClaudeAdapterV2.ts around the terminal task_notification handling (about lines 9344-9367) and backgroundWorkNotification (about 9448-9466), then check ProviderContinuationService.ts lines 247-256 where the default background_task/updated tag is applied. Related gate logic is in Orchestrator.ts near line 752, subagentProjection.ts, and orchestrationV2PendingBackgroundWork.ts. Done means a per-line Monitor event records a monitor/updated report while other updated wakes keep their current tag, with the gate behaving as the issue's table describes.

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

Derived from a production lifecycle read back from the state DB and the child's Claude session log. I did not rerun it as a clean repro.

1. A parent delegates an async delegate_task to a Claude child. The child finishes, and the original task is delivered.
2. The parent sends the child a follow-up with t3_thread_send. The child starts a long command and arms a Monitor on its output that emits one line per event (for example, one line per surviving mutant). It does not call t3_background_wait on the Monitor. It ends the turn.
3. Each Monitor line wakes the child. The child replies briefly ("Covered. Waiting for the rest.") and ends the turn.

Expected behavior

The follow-up gate drops Monitor progress, as its comment says ("monitor updates only report progress", Orchestrator.ts:752). The parent is not woken for each Monitor line.

Actual behavior

Every Monitor line wake starts a new follow-up delegated task (completionWake: "always"). Each one completes and wakes the parent. In one lifecycle, a dispatcher received 42 such progress-only hand-backs from one worker in about 5 hours. Each one cost the dispatcher a full model turn.

The cause is the tag. A per-line Monitor wake reaches the orchestrator as {source: {kind: "background_task"}, outcome: "updated"}, not as monitor. The gate refuses only monitor, so it lets these through. The Monitor's own end does carry monitor (a terminal task_notification), so on main the gate drops the one wake it should keep (#31843) and keeps the ones it should drop.

Claude event	Tag T3 gives it	Gate on main	Gate after #31856
Per-line Monitor event	background_task / updated	passes, one follow-up per wake	passes
Monitor ends	monitor / completed	dropped	passes

Why the per-line wake has no Monitor tag:

• The Claude adapter records a wake report only for a terminal task_notification system message (ClaudeAdapterV2.ts:9344-9367). A Monitor line is a queued <task-notification> prompt carrying an <event>, not one of those.
• With no report, backgroundWorkNotification returns null and the continuation is offered with no notification (ClaudeAdapterV2.ts:9448-9466).
• ProviderContinuationService then fills in its default background_task / updated (ProviderContinuationService.ts:247-256).

The same tag also feeds delegatedTaskProgress, which excludes runs from an original task's work runs only when their notification is monitor (subagentProjection.ts:273-280), and monitorHoldsWakeCompletion (orchestrationV2PendingBackgroundWork.ts:120). So the mislabel is not limited to follow-ups.

A possible fix: when a buffered Claude wake is a Monitor event, record a {kind: "monitor", outcome: "updated"} wake report, the way a terminal task_notification records one today. The gate, delegatedTaskProgress and monitorHoldsWakeCompletion then work unchanged. Dropping every updated wake at the gate instead would also drop other wakes that arrive with no report and the same default tag, such as a ScheduleWakeup, whose turn can hold a real answer.

This is separate from #21837, which is about a follow-up settling while awaited work is pending. None of the Monitors here were awaited, so a fix for #21837 would not stop these wakes.

Impact

Major degradation or frequent failure

Version or commit

0.1.10-nightly.20261112.4564 (bc647ed53595888efacdd8ca435967d48888a952). The cited code is unchanged on main ed05c0e43b64631f9780ad538fb4db1f0e0cd66d.

Environment

macOS arm64, local server. Claude Opus 5.5 parent and child.

Logs or stack traces

# Child's Claude session log: one queued Monitor line, then the wake
20:59:14.289Z queue-operation enqueue  <task-notification> <task-id>br517lnp6</task-id> <summary>Monitor event: "...: survivors and the end"</summary> <event>ok  Unmutated baseline in 3s build + 3s test</event> ...
# The same wake in the T3 child thread (projection message)
20:59:14.482Z user  notification={"source":{"kind":"background_task"},"outcome":"updated","summary":"Background activity updated"}
20:59:18.046Z assistant  "The baseline passes. Waiting for survivors or the final tally."
# -> a new follow-up task, completed and delivered to the parent at 20:59:18

# Across the lifecycle
Monitor-event notifications enqueued in the child: 76, across 10 Monitors
Follow-ups started by background_task/updated wakes: 42 (20:59:18Z to 01:48:35Z), all delivered to the parent
Monitors awaited with t3_background_wait: 0

Workaround

Tell delegated children to use a background command that ends once, instead of a Monitor that emits a line per event. Awaiting the Monitor does not help after the first result, because follow-ups ignore awaited work (#21837).