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

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.

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) https://github.com/pingdotgg/t3code/issues/15250#issuecomment-5971310561

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 (aad732901e). Your nightly (8ed276c) is an ancestor of it, and this lookup path hasn't changed since. This is the V2 version of #10185 https://github.com/pingdotgg/t3code/issues/10185, which was closed when Orchestrator V2 shipped. It isn't #15214 https://github.com/pingdotgg/t3code/issues/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 https://github.com/pingdotgg/t3code/issues/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 https://github.com/pingdotgg/t3code/pull/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 https://github.com/pingdotgg/t3code/issues/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: @.***>

Submitted a focused fix in https://github.com/pingdotgg/t3code/pull/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.

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:

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.

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.

Reproduced on 1688f96568: when the one-time metadata lookup for a native Codex child failed, the child's model stayed "Not reported" through completion. #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.