Let an orchestrator thread hear from its workers, and pass their questions to the user

[zjorichardson]

The problem

V2 already has the pieces to run one thread as a coordinator: delegate_task across providers, t3_thread_launch with its own worktree, t3_thread_send, and pending-request read/respond. The pattern I keep using is:

I talk to one thread. It splits the work into lanes, runs Claude and Codex workers in parallel, answers what it can, and brings me only real decisions.

What stops it working on its own is that the coordinator can't hear its workers. It finds out about anything by polling, and once its turn ends it doesn't poll. Today:

Worker event	Parent hears it?
delegate_task child finishes	✅ woken (#12285 / #13938)
delegate_task child asks a question or needs approval	❌ (#15082, fix proposed in #13343)
Thread from t3_thread_launch finishes, blocks, or errors	❌ only t3_thread_wait, which blocks the parent
Worker errors, stalls, or hits a milestone it declared	❌

As a workaround I run a sidecar that polls every worker thread every 20 seconds and texts me when one stops or needs input. That copies state T3 already owns, which is why I think this belongs in the product.

Proposal

Building on #13343, which already adds the delivery path (a server-owned notice to the parent with queue_after_active, de-duplicated, cancelled on Stop):

1. Same notices for threads an orchestrator launched. When thread A launches thread B through t3_thread_launch, record A as B's coordinator. B's completion, question, approval, and sign-in notices go to A, the same way delegate_task children's do. No new event types.
2. Opt-in for more events. A launch/delegate option such as notify: ["done", "input", "error", "stalled"]. The default stays what fix(server): tell parents when a delegated task is waiting for input #13343 ships.
3. A "needs you" surface on the coordinator. The client half of fix(server): tell parents when a delegated task is waiting for input #13343 (already planned as a follow-up in [Bug]: A delegated task that asks a question or needs approval never tells its parent (V2) #15082): the coordinator's row shows a count, and its thread lists the open child requests, which can be answered without opening each hidden child. The coordinator agent still sees each notice first, so it can answer from context and only pass the real decisions along.

Out of scope

• Workers messaging each other directly, or shared task boards. t3_thread_send already covers the explicit cases.
• Any change to how results are delivered or acknowledged.
• Auto-approving anything on the user's behalf. Approvals still need the user, just without hunting for them.

Questions for maintainers

• Is recording a coordinator on t3_thread_launch threads acceptable, or should launched threads stay independent and this be limited to delegate_task?
• Is point 3 already designed somewhere I should align with?

If the direction looks right, I'm happy to implement point 1 as a focused PR on top of #13343 once it lands.

[vasanthsreeram]

For the coordinator's "needs you" surface, I would test two workers asking the same question text. Each notice should keep its worker ID, pending-request ID and request kind, so answering worker B clears B only. Replay the same event and check it adds no second pending item. Then stop or relaunch the coordinator before opening an old notice: a stale answer must not reach the new run. Keep sign-in and tool-approval requests in their own host-controlled flows.

That gives a focused fixture for the existing polling/texting workaround without assuming a new launch relationship has maintainer approval. I have read your proposal; I have not reproduced T3's runtime behavior.

Disclosure: I build JustCallMe, a hosted phone channel for a blocking agent question. Would you try one harmless worker decision from a phone in a disposable Claude Code/Codex session? For example, "Should dummy worker B use a nullable field?" I can help with own-phone verification and private scoped-key skill setup. 20 free minutes, no card. T3 pairing is unimplemented and untested; native approvals stay with the host, and an unanswered request leaves the decision pending. Keep phones, codes, keys and real task details private.