TUI: /status shows wrong model in multi-agent sessions (Selected model vs turn_context.model)

[palvaleri]

What version of Codex CLI is running?

codex-cli 0.106.0

What subscription do you have?

Team

Which model were you using?

• TUI /status shows: gpt-5.2 (reasoning xhigh)
• But the session rollout (turn_context) shows the effective model is: gpt-5.3-codex

What platform is your computer?

macOS 15.7.4 (Apple Silicon)

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

zsh

What issue are you seeing?

In multi-agent / collab sessions, the TUI /status (and the header “Model:” line) can show a different model than the one actually used for the active thread.

This is extremely confusing because it becomes impossible to tell which model is actually answering.

Evidence (sanitized)

TUI /status (for a spawned agent thread):

Model: gpt-5.2 (reasoning xhigh, summaries detailed)

But the corresponding rollout contains turn_context with model=gpt-5.3-codex:

{"timestamp":"2026-02-27T18:52:21.984Z","type":"turn_context","payload":{"model":"gpt-5.3-codex","effort":"xhigh","approval_policy":"never","collaboration_mode":{"mode":"default","settings":{"model":"gpt-5.3-codex","reasoning_effort":"xhigh"}}}}

Also, codex-tui.log shows the app-level selection can differ from the resumed session model (paths redacted):

INFO  codex_tui::app: Selected model: gpt-5.2, Selected effort: xhigh
WARN  session_init: codex_core::codex: resuming session with different model: previous=gpt-5.2, current=gpt-5.3-codex

What steps can reproduce the bug?

I don’t yet have a perfectly minimal repro, but it seems to involve:

1. Starting a multi-agent / collab session where at least one thread ends up with a different turn_context.model than the app’s selected model.
2. Switching into that thread in the TUI.
3. Running /status (or looking at the header).

What is the expected behavior?

/status should show the effective model for the active thread (ideally from the latest turn_context / session context), not a stale app-level selection.

If the app model is global, then the UI should still reflect the actual model used; or show both “Selected model” vs “Effective model” when they differ.

Additional information

Possibly related (same surface area: collaboration modes / model state): #9766, #9783, #11013.

[github-actions]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• The limitations of GPT-5.3-Codex-Spark can be seen in /status but not in /model. It is not clear whether Plus users can use Spark models. #12992
• Model thinking level resets to "medium (default)" when sending prompt in 0.104.0 with different thinking level configured #12270
• Are Pro 5.3 users all secretly just using 5.2? Certainly looks like it! ~/.codex/models_cache.json, gpt-5.3-codex is marked supported_in_api: false #11328

Powered by Codex Action

[palvaleri]

Thanks for looking.

Here’s additional evidence + a likely code-level root cause (sanitized, no tokens).

Extra evidence (logs + rollout)

1) TUI still considers the selected model = gpt-5.2

From codex-tui.log (timestamps from a multi-agent collab run):

2026-02-27T20:34:54.937310Z  INFO codex_tui::app: Selected model: gpt-5.2, Selected effort: xhigh
2026-02-27T21:06:01.860146Z  INFO codex_tui::app: Selected model: gpt-5.2, Selected effort: xhigh

2) But the spawned agent thread rollout is consistently gpt-5.3-codex

In the agent thread rollout, every turn_context.payload.model is gpt-5.3-codex (no switches).

First turn_context (trimmed):

{"timestamp":"2026-02-27T18:52:21.984Z","type":"turn_context","payload":{"model":"gpt-5.3-codex","effort":"xhigh","approval_policy":"never","collaboration_mode":{"mode":"default","settings":{"model":"gpt-5.3-codex","reasoning_effort":"xhigh"}}}}

(Separately, the same thread’s /status output in TUI showed Model: gpt-5.2 … — that mismatch is the core bug here.)

3) Another worktree shows the same “model state drift” symptom

From a different worktree (260101_details), I can reproduce model drift on resume:

2026-02-27T21:13:17.871689Z  WARN session_init: codex_core::codex: resuming session with different model: previous=gpt-5.2, current=gpt-5.3-codex

And the same session’s rollout shows a turn_context transition gpt-5.2 -> gpt-5.3-codex shortly after resume.

Likely root cause in TUI (code pointers)

The /status “Model:” line is ultimately coming from ChatWidget::model_display_name() → ChatWidget::current_model().

• /status path:

  • codex-rs/tui/src/chatwidget.rs: add_status_output() passes self.model_display_name()
  • codex-rs/tui/src/status/card.rs: renders that string as the “Model” row

• current_model() prefers active_collaboration_mask.model over current_collaboration_mode.model:

  • codex-rs/tui/src/chatwidget.rs: current_model()

• On thread/session switch, on_session_configured() updates current_collaboration_mode from SessionConfiguredEvent.model, BUT it does not sync/clear active_collaboration_mask.model.

  • codex-rs/tui/src/chatwidget.rs: on_session_configured()

So if active_collaboration_mask.model still holds the previous thread’s model (e.g. the app’s selected gpt-5.2), it will override the newly configured session’s model (e.g. gpt-5.3-codex) for:

• the header model display
• /status model display
• any other UI places calling current_model()

Minimal fix sketch

In ChatWidget::on_session_configured(), after model_for_header is known, ensure the active mask can’t override it with stale state. For example:

if let Some(mask) = self.active_collaboration_mask.as_mut() {
    mask.model = Some(model_for_header.clone());
}

(or clear mask.model so current_model() falls back to current_collaboration_mode.model).

Happy to provide more rollouts/log excerpts if you want specific thread IDs / timelines.