[Bug]: Batched `delegate_task` wait calls start children one at a time, but the parent reports both running#23191

Before submitting

• I searched existing issues and did not find a duplicate.
• I included enough detail to reproduce or investigate the problem.

Area

apps/server

Steps to reproduce

1. Start a thread with Codex or Claude Code as the agent and the T3 delegation tools available.
2. Have the agent submit two delegate_task calls together. Use mode: "wait", timeoutMs: 10000, and a read-only child task that runs longer than the wait.
   • In Codex code mode, run the cell below in one functions.exec call.
   • In Claude Code, have the agent emit the same two calls as parallel tool uses in one assistant message.
3. In the server traces, compare when T3 receives each delegate_task HTTP request with when the first call returns.

I did not run this exact cell. The tested runs gave the children the same work through file-backed prompts. The Claude Code run used these wait and delay values. The Codex runs used shorter and longer waits.

Expected behavior

When an agent intends to run two children in parallel, both children start. The agent reports a child as running only after T3 returns its taskId and a running status.

T3 does not promise that mode: "wait" calls dispatch in parallel. The mode description says only that a wait blocks until completion, a blocking question, a pending approval, or timeout. It does not tell the agent that a blocking call can hold back other calls submitted with it. Either the calls dispatch concurrently, or the guidance tells the agent to launch every child with mode: "async" before it waits on any of them.

Actual behavior

The second child starts only after the first wait returns. In the original incident, the parent reported both as running before the second child existed.

In the controlled Claude Code run, both complete tool uses were in one assistant message. B's arguments were ready about 8 seconds before A's response finished. Even so, T3 received B's HTTP request 18 ms after A's response finished. Codex code mode showed the same order with Promise.allSettled.

In the original Codex incident, only the first child existed after about two minutes, but the agent reported both as running. The user found the missing child. The agent then launched it with mode: "async", and T3 accepted that call while the first wait was still open. The original batched call reached T3 about three and a half minutes later, after the first wait returned. It reused the same clientRequestId, so it returned the existing child. No request was lost, no transport failed, and T3 created no duplicate child.

The delay happens before T3 receives the second request. T3 accepted another delegation during the wait, so T3 does not hold a server-wide lock. This report covers two calling paths, Codex code mode and Claude Code direct parallel tool uses, not every runtime or MCP tool. The scheduling policy inside each runtime is unknown. Whether T3 can change its runtime integration is an open question, but T3 owns the launch guidance that agents follow.

Related issues, with no confirmed duplicate:

• #11168: a blocking wait fails at a client timeout and returns no task ID. Here, both calls succeed, and the second call is late.
• #16621: child cards disappear after the children exist. Here, the second child does not exist yet.

Impact

Minor bug or occasional failure

Version or commit

0.1.2-nightly.20261021.3473

Environment

Debian 13 Linux backend; Codex MCP client 0.163.0; provider/model codex / gpt-6.1-sol;

Logs or stack traces

Screenshots, recordings, or supporting files

No response

Workaround

Launch every child with mode: "async" and keep each returned taskId. Report a child as running only after T3 returns its taskId and a running status. Start any blocking wait only after every launch returns.

I have a local change that adds this order to the orchestration instructions and to the delegate_task and mode descriptions. It changes only the guidance, not how calls dispatch.