Let a parent agent handle follow-up questions from a remotely delegated child

[Lenoridev]

When an agent delegates a task to a linked environment, the remote child can ask a question that only the coordinating parent can answer from its instructions or context. Today the question is handled in the destination thread. The new cross-environment client indicators make it visible to the user, but do not give the parent agent a task-scoped way to receive and answer it.

Could remote delegation support an explicit opt-in for the parent to handle these questions?

For example, delegate_task could accept followUpQuestions: "parent". The default would continue to leave questions in the destination thread. With the option enabled, the source server would notify the owning parent about a pending question; the parent could read and answer that question through task-scoped tools. A question would not complete the delegated task, and its final answer would still arrive through normal completion delivery.

The initial proposal concerns user-input questions only. Permission approval and sign-in remain with the user; it adds no authority for a parent to approve permissions or authenticate. Launch recovery, local child-request fixes, Home/fleet orchestration and ordinary top-level thread launches are separate work.

An existing prototype is available on Lenoridev's remote-child-followups branch. It preserves task/run/request ownership, peer authorization, restart deduplication and cancellation. It was offered alongside #15082 before the local question fixes merged; this proposal separates its product decision from that bug report.

The prototype currently also includes remote approval/sign-in handoff notices. Those are broader than the questions-only proposal and would be removed from the initial PR unless maintainers explicitly choose to include them. It is an implementation reference, not an already approved or narrowed feature.

Would this workflow fit the intended direction for linked-environment delegation? If so, please confirm the initial scope and whether a focused follow-up should target the #16719 branch or wait until that stack reaches main.

Prototype validation used source SQLite/orchestration and loopback HTTP/MCP/OAuth with a modeled destination/provider. Real-provider resume and two-host/T3 Connect acceptance remain unverified.

Related: #6935 for the broader cross-environment direction; #16719 for remote delegation; #19521/#19538 for the already-merged local question behavior; #15082 for remaining local approvals/sign-in; #17051 for separate launch recovery.

Prepared with GPT-6.1-Sol through the Codex harness in T3 Code.

[ReneFr81]

We delegate most of our work across several linked machines, and this is the gap we hit most often: a remote child that asks a question or waits for an approval stops, and the parent keeps showing it as running until someone opens the other machine. As a stopgap we run a small poller on each machine that sends the parent the question together with the exact t3_pending_request call (including environmentId) to answer it. That one message is enough for the parent to answer from its own instructions.

What we'd like from the tools: delegate_task and task_status report hasPendingQuestion and pendingApproval for remote tasks, and the parent gets the same wake a local child's question or approval produces. Approvals are the same problem for us as questions: the person at the parent should be able to see and answer them there, without switching machines. #26344 looks like it covers both, and we're happy to test it.