[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. Jonathanm10 commented on Oct 17, 2026

   

   Jonathanm10

   on Oct 17, 2026

   More actions

   Same bug on a newer build: T3 Code nightly 0.1.1-nightly.20261017.3238 (desktop app, macOS 27 arm64, Codex CLI 0.163.0). The parent ran gpt-6.1-sol/xhigh. Every native subagent's chat view showed "Sol 6.1 xhigh", including one Codex ran as gpt-6-luna/high.

   New finding: Codex 0.163.0 already puts the child's model in the subAgentActivity started item:

   {"type":"subAgentActivity","model":"gpt-6-luna","reasoningEffort":"high","kind":"started","agentPath":"/root/azure_design_luna"}

   registerSubagentActivity (CodexAdapterV2.ts ~L3053 at tag v0.1.1-nightly.20261017.3238) passes model: null and no reasoningEffort, and the generated SubAgentActivityThreadItem schema doesn't include those fields. The fallback thread/read and thread/resume were sent in the same millisecond and both failed with -32603 … rollout at <rollout-path> is empty, so all four children in this run stored model: null. The child thread then kept the parent's modelSelection (~L2823), options included.

   Regenerating the schema and passing item.model / item.reasoningEffort from the started item would fix this deterministically on current Codex, without depending on #15285's retry. The retry would still help older Codex CLIs that don't send these fields.

   Investigated via t3 triage with Claude Code (Claude Opus 5.5). No files, settings or databases were changed.
6. Rewolbebol commented on Oct 20, 2026

   

   Rewolbebol

   on Oct 20, 2026 – with ChatGPT Codex Connector

   More actions

   Additional occurrence of the misleading child-model label:

   I explicitly requested that subagents use GPT-6-Luna, Extra High. T3 Code's child view instead displayed GPT-6.1-Sol, Extra High, matching the parent conversation. This made it appear that the requested subagent-model restriction was being ignored.

   Expected: show the child's own reported model and reasoning effort, or clearly mark the value as unknown. Do not silently present the parent's model as the child's model.

   This is a user-visible report of the label mismatch, not a claim that execution was actually routed to the wrong model. No local session logs, identifiers, machine details, or project information are included.

   Related: #17694. Adding this occurrence to the existing open report instead of filing a duplicate.
7. juliusmarminge commented on Oct 21, 2026

   

   juliusmarminge

   on Oct 21, 2026 – with GitCafe Production

   Member

   More actions

   Reproduced on 1688f96: when the one-time metadata lookup for a native Codex child failed, the child's model stayed "Not reported" through completion. https://git.cafe/pingdotgg/t3code/pulls/22830 adds bounded retries for that lookup; in an isolated runtime the child recovered the correct model and effort within seconds and kept them through completion. Claude children, the mobile card and remote modes remain unverified.
8. gitcafe-production

   added 2 commits that reference this issue on Oct 22, 2026

   test(server): add runtime evidence driver for #15250

   ...

   89d72c1

   chore(server): register #15250 evidence scripts as knip entries

   ...

   f311712