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

Ouverte
  • Quelque chose ne va pas ?
#36,113 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

@juliusmarminge y travaille déjà.

Depuis le 13/11/2026.

  • #36339 par @juliusmarminge — ouverte

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
22/100
Type d'issue
Bug
Clarté
Plutôt claire
Activité
Active
Stack technique
typescript
Domaine
ai-infra-agents, backend

Piste de recherche

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.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

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).

Langage dominant
TypeScript
Étoiles
24.8k
Forks
6.4k
Merge moyen
59 min
PR mergées (30 j)
418

Préparer son environnement

Ouvrir dans Codespaces

Lance le conteneur de développement du projet dans votre navigateur, avec votre propre compte GitHub.

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de pingdotgg/t3code

Toutes les issues de pingdotgg/t3code

Issues similaires

Plus d'issues TypeScript

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.