[Bug]: Remote delegate_task drops the child's background-wake run; the parent keeps run 1's interim result #32563

Before submitting

• I searched existing issues and did not find a duplicate. [Bug]: Original delegate_task task finalizes on a stale result in the gap before the child's background-exit wake turn #24297, Delegated task reports finished while its child thread still has running work #16603 and App-owned follow-up completes while nested work runs, then loses the final result #21837 cover local children. fix(server): notify parents after delegated background runs #23542 fixed result delivery for a local child's background-wake run. Resuming a completed remote delegate does not create a follow-up task or notify its parent #26740 covers t3_thread_send follow-ups to a remote child. This report is about a remote (linked-environment) delegate_task child whose own background command wakes it after its first run. The parent never receives that run's result.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Link environment B to environment A. Both run T3 Code 0.1.7.
2. From a thread on A, call delegate_task with mode: "async" and target.environmentId set to B, on a Claude child (claudeAgent, claude-haiku-5-5), with this task:

   1. Run this in one Bash call with run_in_background set to true:
      sleep 75 && date -u +%H:%M:%S > /tmp/t3-remote-repro.txt
   2. Do not wait for it. Reply with exactly "REPRO WAITING" and end your turn.
   3. When you are woken because that command finished, read the file and reply exactly "REPRO DONE <its contents>".
   

3. Do not poll. Wait for the parent's notices, then read task_status and the remote thread with t3_thread_read (environmentId B).
4. Control: send the same task as a local delegate_task on A (claudeAgent through a different provider instance, same model).

Expected behavior

The parent receives the child's final result, "REPRO DONE …", as it does for a local child. That can be either a held task or a follow-up delivery (#23542).

Actual behavior

The parent receives only "REPRO WAITING". On B, the child's background command wakes it, and run 2 replies "REPRO DONE 17:50:47". Nothing reaches A: there is no follow-up task and no second notice, and task_status still reports run 1's text.

Remote run, 2026-11-07 UTC:

Local control on A, same prompt and model:

So locally the interim result is followed by the final one. Remotely, the final result is lost.

A second remote run with claude-sonnet-5-5 showed the same result (B on 0.1.6 at the time, A on 0.1.7).

Source reading (not verified by a debugger)

At main @ 25bf84a, RemoteDelegation.followOnce waits on the task's recorded run (runId: remote.runId, L602) with untilDelegatedWorkSettled: true (L607). It completes the task with that run's last reply as "ran-out" (L637), and settled then ends the follower (L648). Nothing on A follows later runs of the remote thread. The local follow-up path from #23542 has no remote counterpart. RemoteDelegation.ts has no commits after v0.1.7. I have not tested main itself.

Impact

Major degradation or frequent failure. Agents commonly end a turn while CI or a test command runs in the background. In our use, 2 of 5 real remote tasks hit this. In one, the parent took the interim text as the final result. The child's run 2 then failed on a provider 429 that A never saw, and the work sat for about 3.5 hours until someone checked the remote thread by hand.

Version or commit

T3 Code 0.1.7 (stable) on both environments. A is the Linux desktop AppImage, B is t3 serve --lan from npm t3@0.1.7.

Environment

A: Arch Linux (Omarchy), desktop 0.1.7. B: Debian cloud VM (instabox), t3 serve 0.1.7, linked over Tailscale with full access. Child provider: Claude Agent through a Claude-compatible proxy, claude-haiku-5-5 and claude-sonnet-5-5.

Workaround

• Remote children never end a turn while a background command or subagent they started is still running. They wait inside the turn.
• Before trusting a remote task's result, the parent reads the remote thread with t3_thread_read (environmentId) and checks that its latest run is the one that produced the result.

Filed by

Claude Opus 5.5 (Pi agent), on behalf of @phoduke. Every timestamp above comes from statev2.sqlite on A, B's thread record read through the link, and B's server journal.