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

Activity

1. nicsaul commented on Oct 15, 2026

   

   nicsaul

   on Oct 15, 2026

   More actions

   Here is an isolated reproduction on 0.0.46-nightly.20261012.3010 (d83929a), 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 thread	Claude threads (all)
   Incidents where children finished after the parent's run ended	27	484
   Incidents where only a user message resumed the parent, more than 15 min later	7 (43 to 594 min each)	20, across 13 threads
   Delay to resume when the children were delegate_task jobs	0 to 11 min, always automatic	n/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.
2. NOirBRight commented on Oct 19, 2026

   

   NOirBRight

   on Oct 19, 2026

   More actions

   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.
3. juliusmarminge commented on Oct 22, 2026

   

   juliusmarminge

   on Oct 22, 2026 – with GitCafe Production

   Member

   More actions

   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

   

   
4. viell-dev commented on Oct 26, 2026

   

   viell-dev

   on Oct 26, 2026 – with ChatGPT Codex Connector

   More actions

   Note

   Agent-authored and submitted on the owner's behalf by GPT-6 Astra via Codex.
   The owner authorized this report but has not reviewed its text.

   Additional Windows evidence from 2026-10-26, including an interaction with PR watching that can make the stalled workflow continue to look active.

   Environment: Codex parent (gpt-6-astra), native Codex implementation child (gpt-6.1-sol), and separate app-owned Claude review tasks. The current t3_environment_read reports server 0.1.0, Windows x64. I have not independently established the exact incident build or Codex CLI version.

   A recorded native-child completion without a parent continuation (UTC):

   • 00:21:02.781: parent run completed while the native implementer continued.
   • 00:55:54.846: the native child's final result was recorded, reporting a clean, pushed implementation and completed local checks. It also reported that its T3 link/watch attempts had failed with inactive-run errors.
   • 01:00:44.872: the next parent run was requested by the user's “Keep going or tell me what the blockers are” message. The parent then recovered the completed work. There was no parent run between these events.

   The PR watch did not provide general workflow liveness:

   • At 01:04:51, the parent called watch_pull_request with the PR URL. It returned watching: true, wasWatching: false.
   • Subsequent CI and app-owned review notifications did resume the parent. The second review requested another correction, which the parent assigned to the native implementer.
   • At 02:01:44, another watch call returned watching: true, wasWatching: true; the parent finished at 02:01:50.795.
   • No next parent run occurred until the user intervened at 11:08:25.445, over nine hours later. The watch was still registered when checked. The native agent was no longer present in the native live-agent inventory; partial correction edits remained locally.

   The second interval is not proof that the child completed or that GitHub polling failed. The native child's T3 timeline only exposes its earlier result, so its later stopping point is not established. Existing CI was already green; a registered PR watch cannot substitute for waiting on local implementation work. This was also an orchestration mistake by the parent agent.

   The useful distinction is that native completion, app-owned review completion, and PR-event delivery behaved differently in the same workflow. The injected preference for native same-provider delegation should make the required parent lifetime explicit. An active PR watch should not be presented or relied on as evidence that outstanding native work will resume the parent.

   The user's requested fallback is bounded waits with explicit status checks; the mandatory PR-watching policy is the adjacent concern already tracked in #22369. No new duplicate issue, patch, fresh isolated reproduction, or claim of a verified root cause is intended here. This report uses scoped timeline reads; no raw transcripts, database exports, private paths, or session identifiers are attached.

   If you prefer no further agent-authored reports from this account, please say so; we will honor that.
5. t3dotgg commented on Oct 31, 2026

   

   t3dotgg

   on Oct 31, 2026

   Member

   More actions

   Note

   🤖 Claude Opus 5.5 responding on behalf of Theo

   Closing: this is covered by #23840, which landed. Reopen if an important part is still missing.
6. t3dotgg

   closed this as completedon Oct 31, 2026