[Bug]: A remote delegated task finishes with the child's first turn, and the answer from its background-wake turn never reaches the parent #28114

Before submitting

• I searched existing issues and did not find a duplicate. Issue searches on this repo: "remote delegate", "delegated task", "linked environment delegate", "untilDelegatedWorkSettled", "remote child stale result", "background wake parent" and "Monitor wake subagent". Discussion searches: "remote delegate", "delegated task result", "linked environment delegate" and "monitor wake". I also read Resuming a completed remote delegate does not create a follow-up task or notify its parent #26740, Delegated task reports finished while its child thread still has running work #16603, [Bug]: Cancelling a background-only delegated task reports completed with an interim summary #16739 and Lineage shows a settled remote delegate as Done #26907. Resuming a completed remote delegate does not create a follow-up task or notify its parent #26740 is the closest: it covers the same missing follow-up when the parent sends a finished remote child a message. Here nothing is sent; the child's own background wake starts the turn. Delegated task reports finished while its child thread still has running work #16603 and [Bug]: Cancelling a background-only delegated task reports completed with an interim summary #16739 are about local children, and Lineage shows a settled remote delegate as Done #26907 is about the Lineage label.
• I included enough detail to reproduce and investigate the problem.

Area

apps/server

Steps to reproduce

You need two linked environments: A (origin) and B (destination). B runs the Claude provider; any model works (I used claude-haiku-5-5).

1. From a thread on A, call delegate_task with target.environmentId = B, mode: "async", and this task:

   Throwaway probe, change nothing. (1) Run the Bash command sleep 25; echo OK with run_in_background: true. (2) End your turn right away with the single word WAITING. Do not wait, poll or sleep yourself. (3) When the background command's finished notice wakes you, reply with the single word FINAL.

2. End the parent's turn and wait a few minutes.

3. Repeat, with two changes to the task. Replace step (1) with "start a Monitor with command sleep 25; echo OK, non-persistent, timeout 120000 ms". Replace step (3) with "When the monitor's finished notice wakes you, reply FINAL".

4. Controls: repeat steps 1 and 3 without target.environmentId, so the child is local.

Expected behavior

The parent gets the child's final answer, FINAL, whichever machine the child runs on. It can come as the task's result, or as a follow-up task with its own completion wake. Since #23542, a local child's background-wake turn is delivered the second way.

Actual behavior

On B, the child thread does exactly what it was told:

• run 1 replies WAITING;
• the background command (or Monitor) finishes, and T3 starts run 2 with a Command "…" finished (or Monitor "…" finished) notification;
• run 2 replies FINAL.

On A:

• While the background command runs, task_status reports status: running, workState: working. That part is right.
• The task then completes with summary: "WAITING". That is run 1's text.
• Run 2's FINAL is never delivered.
  • No follow-up task is created, and no second completion wake reaches the parent.
  • A task_status read taken after run 2 on B had posted FINAL still returned WAITING.
  • The parent thread never received a later wake from either remote probe.

Every machine should behave like the local background-command row. In the local Monitor case, the task completed with WAITING about 0.1 s before the Monitor's wake run was requested. Both timestamps come from the same server, and no second result followed.

Here is the remote background-command probe on each machine, in seconds from delegate_task. The two machines' clocks aren't synchronised to the millisecond.

B  t+0.2   run 1 starts
B  t+14.4  background command started
B  t+16.0  run 1 replies WAITING; run 1 completes at t+16.3
A  t+25.7  task_status -> running / working
B  t+40.2  "Command … finished" notification; run 2 requested
B  t+42.4  run 2 replies FINAL; run 2 completes at t+42.8
A  t+42.8  task_status -> completed / result_available, summary "WAITING"
A  later   no follow-up task, no second wake

Cause

From reading the source at cadf7d5fe3. None of the code cited here changed between that commit and 0.1.6.

1. A remote child gets no follow-up.
   • fix(server): notify parents after delegated background runs #23542 made a provider wake in a local child start a follow-up task that the parent hears back from. It runs through mayStartSubagentFollowup in Orchestrator.ts, then the relationshipToParent === "subagent" check.
   • A remote child's thread on B has relationshipToParent: null, so that path never runs.
   • On A, RemoteDelegation.followOnce completes the task once (complete(…, "ran-out")), and then the follower ends.
   • Nothing on either side picks up a later run on that thread. This looks like the provider-wake counterpart of Resuming a completed remote delegate does not create a follow-up task or notify its parent #26740.
2. Why the follower takes run 1 (inferred).
   • followOnce waits with untilDelegatedWorkSettled: true.
   • On B, delegatedTaskProgress (packages/provider-core/src/server/subagentProjection.ts) returns result_available when no work run is active and pendingBackgroundTasks is empty. resultRun is then the latest finished run.
   • It looks as if the finished command leaves pendingBackgroundTasks before its wake run is created. For a moment, then, the thread reads as settled on run 1. I haven't confirmed this ordering in the Claude adapter.
   • What I did see once: a t3_thread_wait with untilDelegatedWorkSettled on the remote child's thread returned resultRun = run 1, and run 2 then produced the real answer.
3. Runs that a Monitor wakes are excluded.
   • delegatedTaskProgress drops every run whose triggering message has notification.source.kind === "monitor" (monitorRuns).
   • fix(server): notify parents after delegated background runs #23542 treats monitor updates the same way, because they "report progress rather than asking for new work". That fits PR-watch and output-progress notices.
   • But when a Claude Monitor finishes, that is the agent's chosen way of waiting for its own work, and the run it wakes holds the answer.
   • As written, that run can never be a task's result or start a follow-up. This applies to local children as well as remote ones; see the local Monitor row above.

Impact

Major degradation or frequent failure. Any remote child whose work outlasts one turn loses its result. For us that's every long test run delegated to a second machine: the agent's foreground command limit ends the first turn while the suite is still running in the background. The parent then either acts on "still running…" as if it were the answer, or waits for a wake that never comes. It hit two real runs in one morning. One result went unseen for about 45 minutes and the other for about 80, until someone noticed by hand.

Version or commit

Reproduced on 0.1.5 (6d450a4284) on both servers. Both servers now run 0.1.6 (2359643cff), where the code paths above are unchanged. I haven't re-run the probes on 0.1.6.

Environment

Origin: Linux x64 server. Destination: Windows x64 desktop. Both children run Claude Code; the probes used claude-haiku-5-5. Seen with both background Bash commands and the Monitor tool.

What doesn't work

• The child marks the work as awaited. One remote child called t3_background_wait on its background task before ending run 1. The outcome was the same: the task completed with WAITING, and run 2's FINAL was never delivered. This was observed once.
• The parent waits on the thread instead. t3_thread_wait with untilDelegatedWorkSettled returned run 1. This was also observed once; see Cause, point 2.
• The parent sends the child a follow-up to collect the result. A t3_thread_send to a remote child creates no task, so the reply never wakes the parent. That is Resuming a completed remote delegate does not create a follow-up task or notify its parent #26740.

Workaround

The remote child reports back by itself:

• The parent gives the child its own thread ID and environment ID.
• In the turn that has the real answer, the child's last action is a t3_thread_send (mode queue) to the parent, carrying the result line.
• The parent treats a "Delegated task … finished" wake from a remote child as final only if it contains that result line. Otherwise it ends its turn and waits for the child's message.
• A periodic check reads the child's thread with t3_thread_read, never task_status, to recover any result that still slips through.

Suggested fix

• Follow later runs. Treat a provider-wake run on a remote task's thread as a follow-up, the way fix(server): notify parents after delegated background runs #23542 does for local children.
  • B can't record it, because the thread has no parent there. So A's follower should keep watching the remote thread after it completes the task, until B reports no pending background work and no queued wake.
  • It should record a follow-up task for each later run and wake the parent when that run ends.
  • fix(server): a follow-up to a finished remote task is a new task that wakes the parent #26776 (open, the fix for Resuming a completed remote delegate does not create a follow-up task or notify its parent #26740) adds a RemoteDelegation.followUp path that records a follow-up for a run on a finished remote task's thread. That path could probably serve both triggers.
• Count finished Monitors. In delegatedTaskProgress, count a run woken by a finished agent-started Monitor as a work run, and in mayStartSubagentFollowup as a follow-up. Keep progress notices and PR watches excluded.
• Add tests:
  • in RemoteDelegation.test.ts, a remote child whose background wake produces a second reply, which reaches the parent;
  • a local child woken by a finished Monitor, whose reply is delivered.

I'm happy to file a PR for this if you approve the direction.

Related: #26740, #26776, #23542, #16603, #22651

Filed by Claude Opus 5.5 via Claude Code.