Repository navigation
Remote delegate_task: record the task before launching it there #17051
Description
Follow-up to #16719 (delegate_task to a linked environment).
Problem. A remote task starts on the other environment before this one records it. If this server dies, or the launch response is lost after the other side accepted it, the thread there keeps running with no task here to follow, stop, or report it. #16719 narrows this:
- a failed local record interrupts the launched thread;
- a retry with the same
clientRequestIdreplays the launch (feat(server): t3_thread_launch takes clientRequestId #16654) and records it.
Without a retry, nothing here knows about the thread there.
Proposed fix.
delegated_task.remote.requestrecords a pending task first, keyed by the launch key. It stores what a re-launch needs: project, model and options, modes, title, and prompt.remoteChild.threadIdis unset while pending.- Launch there with that key.
- A new internal attach command sets
threadIdandrunId. It must not require an active parent run, since after a restart there may be none. - On startup, the follower re-sends the launch for each pending task with the same key, which the other side replays, then attaches.
Cost. About 2–3 hours, mostly from making remoteChild.threadId optional. That touches:
- the
delegate_taskresult; - web
ThreadRelationshipsControl; - the mobile subagent rows;
- the three hard-coded internal command lists.
It needs its own restart test.
Found by the adversarial review of #16719 (GPT 6.1 Sol, Claude Fable 5.1); deferred so the stack could go to manual testing.
Activity
Lenoridev commentedon Oct 11, 2026
I've reproduced the launch/record window on #16719's current head (
d79fdd537c): the destination accepts the launch while its response is held, and the source has no task record. I'm preparing the record-first recovery described here in a separate branch.The regression covers source restart without the response or an active parent run. I'm preserving the original launch namespace/key, since
PeerForwardingscopesclientRequestIdand the follower has a different namespace. I'm also covering pending cancellation and keeping workspace/Home changes separate.Is someone already taking this? If not, would a follow-up PR targeting
t3code/peer/remote-delegate, or a commit for you to apply/restack, be more useful? I'll continue the focused tests and patch preparation while we settle routing.Written with GPT-6.1-Sol through Codex in T3 Code, on behalf of Lenoridev.
Lenoridev commentedon Oct 11, 2026
Prepared a focused patch based on #16719 at
d79fdd537ca222fc43fb41c1496466da77ee3449: bfef035876. It is on my fork for application/restacking; I have not pushed to the maintainer branch or assumed the preferred PR base.A now commits launch intent before calling B, then attaches B's accepted receipt. Startup recovery retains the original namespace/key and resolved inputs without requiring a live parent run. Pending cancel/Stop reconciles the original child; a known-unsent cancelled intent does not launch. Authorization loss is reported explicitly, including when the original cancellation result must remain unchanged.
One additional regression exposed a second identity boundary: re-linking B after its accepted response is lost created two destination thread IDs even with the original source key. The patch pins the original OAuth grant generation and checks it against the resolved credential snapshot before sending. The durable binding contains no OAuth token; replacement grants cannot launch a replacement child.
Validation: 138 tests across eight focused files passed, including existing link/forwarding coverage, source runtime rebuild, destination launch-receipt replay, pending cancellation, reduced/revoked/replaced authority, and duplicate/mismatched attachment. Formatting and targeted lint passed. Scoped server/web/mobile typechecks passed, as did the existing contracts and client-runtime package typechecks. Full CI remains for the stack integration; lint reports two unchanged baseline warnings.
These are same-host tests: real loopback HTTP/MCP/OAuth and source SQLite/orchestration, modeled destination thread/provider services, plus a separate real ThreadLaunchService runtime/receipt test. They are not physical-host, real Connect, OS-process-restart or real-provider acceptance. An isolated real web client also shows Launching with pending navigation disabled; before/after evidence is captured locally. Only one host is available, so the physical/Connect acceptance items remain clearly tracked as unperformed.
This addresses the launch/attach window only; completed-child Stop, nested coordinator completion, workspace selection and Home watches remain separate. I can adapt the commit to the routing you prefer for the stack.
Written with GPT-6.1-Sol through Codex in T3 Code, on behalf of Lenoridev.
fix(server): recover remote delegations interrupted during launch
Lenoridev commentedon Oct 19, 2026
The patch offered above is now PR #20937, which implements this issue’s record-before-launch and restart recovery. It targets
t3code/peer/remote-delegate(#16719).Written with GPT-6.1-Sol through Codex in T3 Code, on behalf of Lenoridev.
juliusmarminge commentedon Oct 22, 2026
Fresh triage: this describes a durability/recovery bug, not a reported exploitable vulnerability. Checked 948 open issues in 19 pages; no matching duplicate. #22622 concerns an already-recorded task waiting on an orphaned queue, a different symptom.
No runtime reproduction claimed. The available main checkout is 5a264a8b34; its delegate_task contract lacks remote targeting. The prerequisite #16719 remains open against t3code/peer/links-ui. The comments already identify a proposed recovery patch.
Leaving open for Julius: the requested pending-task representation changes delegate_task results and restart launch behavior, which hits the automated triage hard stop for MCP tool-surface changes. No fix or new PR created.