[Bug/Severe] High-tier main sessions bypass subagent model limits, hiding threads and causing token bleed

What version of Codex CLI is running?

codex-cli 0.144.1

What subscription do you have?

Plus (home), Enterprise (office)

Which model were you using?

gpt-5.6-luna, gpt-5.6-sol

What platform is your computer?

Linux 7.0.0-27-generic x86_64 unknown

What terminal emulator and version are you using (if applicable)?

mobaxterm terminal (ssh remote login to ubuntu)

Codex doctor report

_No response_

What issue are you seeing?

There is a serious orchestration issue in the Codex CLI regarding how subagents are spawned and handled. Depending on the main session model, subagents either spawn correctly using the multi_agent_v1 flow or silently fall back to maybe main session implementation.

When this fallback occurs, the subagent thread is missing from the /agent TUI, and it appears to ignore the configured lower-tier model and reasoning limits, instead silently burning through the main session's higher-tier quotas/credits.

Expected Behavior

1. Executing the /agent command opens a visual UI option to select the subagent thread.
2. The subagent uses its explicitly configured model and reasoning level (e.g., a lower-tier model to save costs).
3. The runtime output accurately exposes the subagent's identity, thread ID, model name, and reasoning effort.

Actual Behavior

Under certain conditions, the /agent command only prints a text status in the terminal with no UI selector. When queried, the main session reports that the subagent's model and reasoning effort are "unavailable":

Agent was asked to report actual model name and reasoning effort. It's runtime exposed neither value, so I cannot independently confirm that the backend used the intended model or effort setting. Both explicitly reported: - Model name: unavailable. - Reasoning effort: unavailable.

Critical Impact: Because the intended lower-tier model and reasoning levels are ignored, the subagent seems to inherit the session's higher-tier model. This rapidly depletes usage limits (e.g., Plus) or incurs significant unnecessary credit costs (Enterprise) despite correct configuration.

What steps can reproduce the bug?

✅ Scenario A: Works as Expected (Native Flow)

• Main Session: gpt-luna-5.6 medium
• Subagent Configuration: gpt-luna-5.6-medium (explicitly named luna_medium)
• Output: Spawned Planck [luna_medium] (gpt-5.6-luna medium) └ .......
• Result: I can use the /agent command to select the subagent thread in the UI and view its runtime output.

Main session explanation of this success:

- The parent session was gpt-5.6-luna on Codex CLI 0.144.1, using the native multi_agent_v1 flow. - The spawn call explicitly created Planck [luna_medium], returned a stable child thread ID, and was followed immediately by wait_agent with a long timeout. - No special picker flag, UI setting, or model configuration was used. The most likely explanation is that the picker initially displayed the child before nickname/thread metadata finished propagating, then refreshed while the child initialized and the parent remained active in wait_agent.

❌ Scenario B: Fails (Metadata Loss & Hidden Thread)

• Main Session: gpt-5.6-sol high
• Subagent Configuration: gpt-5.6-luna medium (explicitly named luna_medium)
• Output: Started /root/luna_medium_legacy (Note: _legacy here is just part of the working path/codebase, not a CLI mode)
• Result: No friendly nickname or thread ID is shown. The /agent TUI selector is unavailable.

Main session explanation of this failure:

This run already followed the lifecycle pattern: 1. One native child worker was spawned. 2. Stable canonical identity was returned. 3. The parent immediately entered a one-hour native wait. 4. The wait has remained active except when your new messages intentionally wake it. The meaningful difference is metadata exposure: my tool response contained /root/luna_medium_legacy, but no friendly nickname or child-thread ID field. There is no additional picker-refresh or thread-registration option available to me.

Environment

• Codex CLI Version: 0.144.1 (Based on agent output)
• Models Tested: gpt-5.6-luna, gpt-5.6-sol

Conclusion

There is a severe bug in how gpt-5.6-sol high (and potentially other high-tier models) orchestrates subagents compared to gpt-luna-5.6 medium. The spawning process strips metadata, breaks the TUI thread picker, and most importantly, results in extreme token/usage inefficiency by bypassing the subagent's configured model limits.

What is the expected behavior?

Expected Behavior

1. Executing the /agent command opens a visual UI option to select the subagent thread.
2. The subagent uses its explicitly configured model and reasoning level (e.g., a lower-tier model to save costs).
3. The runtime output accurately exposes the subagent's identity, thread ID, model name, and reasoning effort.

Additional information

_No response_