Resuming a completed remote delegate does not create a follow-up task or notify its parent #26740

What happened

A native remote delegate_task completed and correctly woke its parent. Sending more work to the same finished remote thread with native t3_thread_send started and completed a second run, but returned no new taskId and produced no second parent wake. I had to prompt the parent manually.

Expected: a supported follow-up creates its own tracked task/result and completion notification. If remote sends intentionally remain untracked, the tool should clearly state that exception and identify the supported continuation operation.

Diagnosis

The served t3_thread_send description says: "A send to a finished child thread starts a fresh task and returns its taskId." This remote send returned delivery: started and a runId, without taskId. The original origin-side task remained completed with run 1's BLOCKED summary, and its remoteChild.runId still selected run 1.

At the release commit, environment-aware MCP routing forwards the call to the peer, while the original remote follower stops after publishing its task's result. This supports a missing follow-up association, rather than a failure of all remote completion delivery.

This is an observed incident plus source analysis; a fresh controlled two-server reproduction has not been run. The parent agent also incorrectly promised another wake despite receiving no new task ID.

Steps to reproduce

Derived from the incident; use the same parent provider for a local control:

1. Link two environments. From a Codex parent, call native delegate_task with target.environmentId, the destination project, mode: async and isolation: shared.
2. Let the worker return a terminal BLOCKED reply. End the parent's turn and confirm its initial completion wakes the parent.
3. Send a second bounded task to that same remote thread using native t3_thread_send, with environmentId, mode: auto and a fresh clientRequestId.
4. End the parent's turn. Check for a new task ID and automatic delivery of the second result, preserving the first result.

Version

0.1.4-nightly.20261028.3841, release commit 9e09926d97824179d97311d1a810c6b5bb60d2d1. Both servers currently report this version; the origin desktop bundle agrees. Incident-time byte identity was not established.

Environment

Two macOS arm64 machines, native linked-environment delegation. Origin Darwin 27.0.0, Node v24.22.0. Codex parent and worker, model gpt-6.1-sol. Destination OS minor version and Node version were not collected.

Evidence

Read-only incident run records, UTC on October 28, 2026:

22:01:50.603  Remote run 1 completed BLOCKED
22:01:52.685  Parent wake requested
22:08:36.675  Remote run 2 started
22:10:12.186  Parent turn ended
22:10:56.670  Remote run 2 completed BLOCKED
22:24:03.116  Next parent run requested by user intervention

BLOCKED was the worker's final text; both provider runs completed. This was not a pending approval/question. Run 1's callback worked despite a separate reverse-link read refusal.

Related issues

Historical #13490 was closed by #17696, which added separate tasks for local follow-ups. #22651 concerns an initial remote task stuck behind an orphan queue. #26527 and PR #26344 concern pending questions/approvals. Neither matches this completed follow-up without a new origin task.

Fix applied or workaround

No fix applied. The original mission later succeeded using explicit waits on exact continuation runs. That does not establish automatic result delivery to an idle parent. No implementation or configuration changes were made during triage.

Filed by

Codex, gpt-6.1-sol, through T3 Code triage. Published with the user's approval.