Sign up
View stargazers13Sign up

[Bug]: Native Codex subagent completion leaves the parent idle after it ends its turn#16900

opened16d agobyLLLBlumire

Before submitting

  • I searched existing issues and did not find an exact duplicate.
  • I included enough detail to investigate the problem.

Area

apps/server

Summary

A Codex parent launches native subagents, ends its turn while they are still working, and expects their completion to resume it. The children finish and their results are available, but the parent stays idle until the user sends another message.

This has happened repeatedly. One incident was traced through the parent and child Codex transcripts and T3's stored run/subagent state. The affected children were recorded with origin: "provider_native", rather than as app-owned delegate_task jobs.

Steps to reproduce

This outline describes the observed workflow. A fresh, isolated reproduction with the generic task below has not been run.

  1. Start a Codex thread on Orchestrator V2.
  2. Ask it to launch a native subagent using spawn_agent, for example to review a sufficiently large diff.
  3. Let the parent finish its launching turn with a status message while the child continues. Do not have it remain in wait_agent.
  4. Let the child finish without sending another message to the parent.
  5. Inspect whether child completion starts a parent continuation.
  6. Send a manual message to the parent. It resumes and can retrieve the completed result.

Expected behavior

The parent continues when its delegated work finishes, without the user having to notice the stall and send a message.

If native subagents intentionally require the parent turn to stay active and explicitly wait, T3's injected instructions should state that requirement and direct agents to delegate_task for work that must resume an idle parent. They currently prefer native subagent tools for supported same-provider work without explaining this lifecycle difference.

Actual behavior

The parent completes its turn while its children are working. Child results are recorded, but no parent continuation starts from their completion.

In the clearest traced incident, the parent ended its turn, the lead reviewer finished about 20 minutes later, and a user message about 3 minutes after that restarted the parent. There was no intervening parent run. The parent then retrieved the finished review.

In another fan-out, seven native children finished after the launching parent turn ended. Parent turns during that period came from unrelated PR-watch notifications, rather than child-completion notifications. The review results were available during those turns. This supports a missing wake-up rather than missing child results.

Impact

Major degradation or frequent failure. Delegated workflows stall unless the user monitors the children and manually resumes the parent.

Version or commit

0.0.46-nightly.20261007.2774, Orchestrator V2.

The release tag points to 611132c171f3a821bd2e32f22261135cef6330ac. The source references below use that revision.

Environment

Linux x86_64 server, Codex provider, full access. The exact Codex CLI version was not established during this investigation.

Evidence and likely cause

Observed evidence comes from read-only inspection of the existing incident. No raw transcripts, database exports, screenshots, thread identifiers, project details, or local paths are attached.

Source inspection suggests a mismatch between native delegation and T3's completion-delivery mechanism:

These are candidate causes from source inspection, not a verified patch. The investigation does not establish whether the intended fix belongs in T3's native completion handling, its injected instructions, or the provider's continuation contract.

Workaround

Sending a manual message to the parent restored progress in the traced incident.

Potential workflow mitigations are to keep the parent active with wait_agent, or use app-owned delegate_task for asynchronous work that needs a completion wake-up. Those alternatives have not been tested in a fresh reproduction of this incident.

Related reports

  • #13490 covers missing wakes after follow-up turns on reused app-owned children. This report concerns native children completing after the spawning parent turn ends.
  • #15567 concerns lost native Codex child tracking after a server restart. Here, child completion and results were recorded.

Suggested verification

Cover a native child completing after its parent turn ends, multiple children completing close together, and a child completing while an unrelated parent turn is active. Verify that results reach the parent without a manual prod and without duplicate continuations. If automatic native wakes are intentionally unsupported, verify that the instructions prevent the parent from ending its turn while relying on one.

Nnicsaul8d ago
Synced from GitHub

Here is an isolated reproduction on 0.0.46-nightly.20261012.3010 (d83929ad), Codex 0.160.1, gpt-6.1-sol. It also shows the related parent_not_active failure from #16808 / #19751.

Control: native child, parent ends its turn

  1. Through delegate_task, start a Codex thread (the "parent") with this instruction: spawn one helper with the native spawn_agent, do not wait for it, end the turn.
  2. The helper runs sleep 90. It then calls t3_thread_send to the parent's own thread id.

Result:

  • The parent's turn ends at 16:53:23 and the helper finishes at 16:54:57.
  • The helper's t3_thread_send fails with {"code":"parent_not_active","message":"The calling provider no longer owns an active thread run."}.
  • The parent never gets another run. Its latest run was still ordinal 1 when we checked about 25 minutes later.

Same steps with delegate_task instead of spawn_agent

  • The parent's turn ends at 16:53:11 and the grandchild finishes at 16:54:46.
  • The grandchild's t3_thread_send succeeds, because it runs under its own live run.
  • The parent is woken at 16:54:44 by the send and at 16:54:46 by the delegated-completion notification, with no user message.

Impact in real use

We measured this from statev2.sqlite by grouping each finished child under the parent's next run.

Codex coordinator threadClaude threads (all)
Incidents where children finished after the parent's run ended27484
Incidents where only a user message resumed the parent, more than 15 min later7 (43 to 594 min each)20, across 13 threads
Delay to resume when the children were delegate_task jobs0 to 11 min, always automaticn/a

Claude is mostly fine because its background-agent notifications become wake runs. Codex native children have no equivalent path. The cohort/delivery logic only covers origin === "app_owned".

The coordinator switched to native subagents partly because of the delegate_task description, which says "Prefer native subagent tools for same-provider work only when they support the chosen model." That steers Codex-to-Codex fan-out into this path.

Workaround we're using

A Codex PreToolUse hook denies *spawn_agent* when T3CODE_CLI_PATH is set. The deny message tells the agent to use delegate_task instead.

--disable multi_agent --disable multi_agent_v2 on the app-server does not remove collaboration.spawn_agent on Codex 0.160.1. We verified native spawn still succeeds with both flags.

Possible fixes

Either of these would help:

  • (a) When a provider_native child settles after its parent run has completed, queue a wake through the same delivery used for app-owned tasks.
  • (b) Keep the parent run in waiting while native children are alive. The runtime liveness check already counts them.

The tool-description guidance should also say that native children don't resume an idle parent. #19751 fixes the credential half, but not the missing wake.

Minor, found while testing: if the Codex app-server process exits underneath T3, later turns on that instance keep failing with Codex App Server process exited with code 0 instead of starting a new process.

NNOirBRight4d ago
Synced from GitHub

We observed the same behavior again on 2026-10-19 after updating T3 Code locally (Windows, Codex provider, gpt-6.1-sol).

In an isolated smoke-test conversation:

  1. The Codex parent spawned a native subagent, then ended its turn without waiting for the child.
  2. The child completed, and its completion token was visible on the subagent card.
  3. After approximately two minutes, the parent conversation still had only its initial run. No automatic continuation appeared.

We stopped the test at that point. We did not send a follow-up to test whether the parent could retrieve the result, so this observation establishes the missing wake, not missing result delivery into a later parent turn.

The exact T3 build/commit and Codex CLI version were not captured for this test, so this is an additional reproduction report rather than verification against a specific merged revision.

We are retaining our workaround: keep the Codex parent turn active until required native subagents finish, with individual waits limited to about 60 seconds. This lifecycle distinction would also be useful to state explicitly in the injected guidance that currently prefers native subagents for supported same-provider work.

JJulius Marminge1d ago

Reproduced on current main a12d6ed942, Linux x86_64, Codex CLI 0.163.0, gpt-6.1-sol, in the real web dev app with isolated state.

  • Fresh project: native child ran sleep 90; parent ended without wait_agent at 22:56:36 UTC. Child completed at 22:58:10 with its result recorded, but no parent continuation started.
  • A manual message resumed the parent, which retrieved the completed result.
  • Existing conversation: repeated with two native children. Both completed; the parent again stayed idle.

Runtime transcript

Native child finished while parent remained idle

Manual message recovered the native child result