Sign up
View stargazersSign up

[Bug]: Delegated Codex child stays running after its parent is settled#20348

opened14d agobyJjfet97

What happens

After settling a parent conversation, the next message to its delegated Codex child can get stuck in T3. Codex finishes and saves its reply, but T3 never displays that reply or marks the turn complete.

EnvironmentValue
T3 version0.1.1-nightly.20261016.3218
PlatformLinux ARM64
ProviderParent and child use the same configured Codex instance

The original incident also occurred on Nightly 3203.

Simple reproduction

  1. In a Codex conversation, ask the agent to create one child with T3's delegate_task, using the same Codex instance. The child can simply reply READY. Wait until both child and parent finish; leave the child unsettled.

  2. Choose Settle thread on the parent.

  3. Within a few minutes, open that same child using Open subagent and send another message, such as “Reply PONG”. Do not create a new child.

Verification: the live test used the native thread.settle and message.dispatch API commands backing these actions. Browser clicks were not automated. No Supervisor or webhook was needed for this case.

ExpectedActual
The reply appears and the child's turn completes.T3 stays running without a reply, although the Codex session log shows that the turn finished normally.

Observed timeline, in UTC:

text
118:12:54.209 Parent detached
2 +7 ms T3 unsubscribed the child
318:14:28.798 Child's next turn finished in Codex
4 T3 received no turn, item or completion notifications

External-monitor variant

This also reproduces when an external client settles the parent through T3's API, then sends a check-in through a native webhook task bound to the existing child.

  • The single POST returned HTTP 202, and its delivery record says accepted.
  • Codex finished in under 2 seconds.
  • T3 stayed running without the reply.

No new child or additional model runner was involved.

Likely cause and fix scope

Parent cleanup includes the child's native thread and unsubscribes it, but clears only the parent's loaded-thread cache. The child still looks loaded, so its next turn skips the resume that would restore updates.

This appears localized to session-manager cleanup plus regression tests:

  • Preserve independently attached children.
  • Recheck ownership under the affected thread's lock.
  • Keep loaded/idle state consistent when actually unloading.
  • Preserve cleanup of unattached native subagents.

Source references:

Related reports

  • #17512: the child reply is already visible in T3, but the parent task is not finalized.
  • #19002: a steered follow-up leaves a stale parent task after the child completes.
  • #19127: an event stream ends without making its run terminal. Here the shared transport remains alive, but the child loses its thread-level subscription.
  • #15979: related Codex unload/MCP-residency cleanup; normal unloading must remain intact.
JJulius Marminge14d ago

Note

Grok responding on behalf of Julius.

This is a bug, and I confirmed it in the code on main.

When a parent detaches from a shared multi-thread Codex session, detach in ProviderSessionManager.ts loads the parent's providerThreads from ProjectionStore.getThreadRecords. That query also returns provider threads owned by the parent's nodes or linked through its subagent rows, so the delegated child's native thread is included and gets unloadThread too. The ownership check under the lock looks only at the parent (attachedThreadIds.has(input.threadId)), and only the parent's loadedProviderThreadKeyByThread entry is cleared. The child still looks loaded, so on its next turn isProviderThreadLoaded returns true and resumeThread is skipped. Codex then finishes the turn, but T3 has no subscription to receive it.

This is separate from #17512, #19002 and #19127. Merged #16917 added idle unloading, but it isn't the source of this detach path.

Any fix should only unload provider threads that belong to the detaching thread, or check each child's attachment and clear its loaded state under that child's lock. Normal unloading from #15979 has to keep working.

JJulius Marminge9d ago

Reproduced on current main 70e5e384da, Linux x86_64, real web dev app, Codex GPT-6.1-Sol. Created one same-instance child, waited for READY and parent completion, settled the parent, opened the existing child, then sent “Reply exactly PONG”. T3 stayed Working without the reply. Codex saved PONG and task_complete after 1.7 seconds. The protocol log shows the child was unsubscribed at parent settlement and its follow-up skipped thread/resume.

Runtime transcript

Child remains Working after Codex completed PONG

JJulius Marminge9d ago

Replacement triage inspected the existing reproduction and local fix candidate. The focused ProviderSessionManager suite passes (42 tests). The candidate needs maintainer review before publication: preserving an attached child skips Codex unloadThread, which also clears that native thread’s session approval grants. That changes approval lifetime as well as subscription lifetime. The automated flow stops on approval-related changes. No PR was opened; the issue remains open. Post-fix runtime proof is still pending.

JJulius Marminge9d ago

Fresh reproduction on current main 8acbefefc5, Linux x86_64, real web dev server and same-instance Codex GPT-6.1-Sol. After READY and parent completion, settled the parent, opened the existing child, and sent “Reply exactly PONG”. Codex saved PONG and task_complete after 4.3 seconds; T3 kept the run running without the reply. Protocol logs show both native threads unsubscribed at parent settlement and no child resume before the follow-up.

Runtime transcript

Existing fix #20361 is still open. The earlier approval-related triage stop no longer applies under the revised brief.

JJulius Marminge9d ago

Fix opened as #23456.

Verified on dca0af89a8, Linux x86_64, real web dev app with the same Codex instance: child READY, parent PARENT_DONE, settle parent, open that same child and send PONG. The reply appeared and the child completed in T3; protocol logs confirm parent settlement preserved the child subscription. All 43 manager tests pass. Two independent final-head reviews found no blockers.

Before runtime · After runtime