[Bug]: V2 Codex subagent model stays "Not reported" after metadata lookup fails #15250

Activity

1. juliusmarminge commented on Oct 3, 2026

   

   juliusmarminge

   on Oct 3, 2026

   Member

   More actions

   Note

   Grok responding on behalf of Julius.

   Triage

   Thanks @niko-itswld for the careful, read-only investigation and the captured protocol trace.

   Confirmed on current main (aad732901e). Your nightly (8ed276c) is an ancestor of it, and this lookup path hasn't changed since. This is the V2 version of #10185, which was closed when Orchestrator V2 shipped. It isn't #15214, which is about missing reasoning effort.

   What I found

   The Lineage title Luna Five Shutdown comes from the subAgentActivity path. That path registers the child with model: null and turns the agent path into the title. SubagentTooltipContent then prints Not reported whenever subagent.model is null.

   The only recovery for that null is a single background thread/resume with excludeTurns: true, capped at five seconds. Any failure, including the -32603 empty-rollout error in your trace, is swallowed by Effect.catch(() => Effect.void), and nothing tries again once the rollout has metadata. thread/settings/updated and model/rerouted could still set the model later, but only if Codex sends them, and your projected subagent staying model: null means neither arrived.

   t3_thread_list uses a different field. The child thread is created with the parent's modelSelection and keeps it while task.model is null. A later subagent.updated that carries a real model would switch it, but that never ran here, so the list still shows gpt-6.1-sol.

   The existing adapter test covers a resume that succeeds and one that returns no model, but not one that errors at first and would succeed later. That's the same startup race seen on #10185.

   Likely fix area

   • Retry the child metadata read a bounded number of times after an empty-rollout error, and stop once the child is gone or a settings or reroute event has already set the model.
   • Don't fall back to the parent's model in the tooltip. Once a real child model arrives, the existing thread sync should move t3_thread_list off the parent placeholder.
   • If retries still can't read a model, consider not presenting the parent's model as the child's in the thread list.

   Open PR #14108 doesn't cover this case. It tries thread/read first and falls back to thread/resume only when that read succeeds with an empty model, so an empty-rollout error still ends the single attempt.

   A maintainer will decide on the fix direction.
2. juliusmarminge

   added

   bugSomething is broken or behaving incorrectly.Something is broken or behaving incorrectly.

   codex

   via-triageFiled through npx t3 triageFiled through npx t3 triage

   on Oct 3, 2026
3. niko-itswld commented on Oct 3, 2026

   

   niko-itswld

   on Oct 3, 2026 via email

   Author

   More actions

   FYI worked with Sonnet 5.5, no bug there. Maybe not deterministic. Verify further. la 3.10.2026 klo 19.56 Julius Marminge ***@***.***> kirjoitti:

   …

   *juliusmarminge* left a comment (pingdotgg/t3code#15250) <#15250 (comment)> Note Grok responding on behalf of Julius. Triage Thanks @niko-itswld <https://github.com/niko-itswld> for the careful, read-only investigation and the captured protocol trace. *Confirmed on current main (aad7329).* Your nightly (8ed276c) is an ancestor of it, and this lookup path hasn't changed since. This is the V2 version of #10185 <#10185>, which was closed when Orchestrator V2 shipped. It isn't #15214 <#15214>, which is about missing reasoning effort. What I found The Lineage title *Luna Five Shutdown* comes from the subAgentActivity path. That path registers the child with model: null and turns the agent path into the title. SubagentTooltipContent then prints *Not reported* whenever subagent.model is null. The only recovery for that null is a single background thread/resume with excludeTurns: true, capped at five seconds. Any failure, including the -32603 empty-rollout error in your trace, is swallowed by Effect.catch(() => Effect.void), and nothing tries again once the rollout has metadata. thread/settings/updated and model/rerouted could still set the model later, but only if Codex sends them, and your projected subagent staying model: null means neither arrived. t3_thread_list uses a different field. The child thread is created with the parent's modelSelection and keeps it while task.model is null. A later subagent.updated that carries a real model would switch it, but that never ran here, so the list still shows gpt-6.1-sol. The existing adapter test covers a resume that succeeds and one that returns no model, but not one that errors at first and would succeed later. That's the same startup race seen on #10185 <#10185>. Likely fix area - Retry the child metadata read a bounded number of times after an empty-rollout error, and stop once the child is gone or a settings or reroute event has already set the model. - Don't fall back to the parent's model in the tooltip. Once a real child model arrives, the existing thread sync should move t3_thread_list off the parent placeholder. - If retries still can't read a model, consider not presenting the parent's model as the child's in the thread list. Open PR #14108 <#14108> doesn't cover this case. It tries thread/read first and falls back to thread/resume only when that read succeeds with an empty model, so an empty-rollout error still ends the single attempt. A maintainer will decide on the fix direction. — Reply to this email directly, view it on GitHub <#15250?email_source=notifications&email_token=CMRD36TNDFS7U4763WPDUFD5SEVTHA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKOJXGEZTCMBVGYY2M4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5971310561>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/CMRD36S7OIPOL2MJQBLLVW35SEVTHAVCNFSNUABGKJSXA33TNF2G64TZHMYTCNJTGEZTAMZUHE5US43TOVSTWNJWHEYTKOJTGI2DTILWAI> . You are receiving this because you were mentioned.Message ID: ***@***.***>
4. niko-itswld commented on Oct 3, 2026

   

   niko-itswld

   on Oct 3, 2026

   Author

   More actions

   Submitted a focused fix in #15285.

   This is low-hanging fruit for a quick review and merge: the existing Codex child-model lookup now retries the captured empty-rollout startup error within a fixed limit, preserves newer metadata, and stops retries for interrupted children. The regression fails before the fix; all 128 adapter tests and server typecheck pass afterward.

   The PR links this issue and its triage comment, and records the verification limits. Maintainers decide merge timing.
5. Neonsy commented on Oct 4, 2026

   

   Neonsy

   on Oct 4, 2026

   Last edited by Neonsy

   More actions

   Note

   GPT Sol 6.1 (High) posted on Neonsy's behalf (cause Claude's 200 tier usage is not as infinite as people make it out to be)

   Additional observation on Windows x64 with Codex CLI 0.160.0. The currently installed T3 server reports 0.0.46-nightly.20261004.2644

   A parent thread using gpt-6-astra spawned three native Codex children with explicit gpt-6.1-sol / xhigh settings

   At the original observation, T3's imported child records reported gpt-6-astra for all three. Their corresponding Codex rollout turn_context records report model: "gpt-6.1-sol" and effort: "xhigh". One child's later turn records the same Sol/xhigh settings

   This corroborates parent-model attribution in imported child metadata. The requested settings appear in Codex's execution records despite T3 reporting the parent model

   No child metadata lookup error was captured, so this does not establish the same empty-rollout cause as the original report. Neither proposed fix has been tested against this session