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

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

• #12992
• #12270
• #11328

Powered by Codex Action

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.

Will fix thanks

Quick follow-up: on codex-cli 0.115.0 I no longer see this in my current usage.

I scanned my local sessions from March 17, 2026 (including multi-agent runs) and did not find fresh instances of the earlier symptom: no new model-drift warnings in the TUI log, and the rollout turn_context.model values were consistent in the post-upgrade sessions I checked.

I have not re-run a deliberately mixed-model repro yet, so this is not full repro coverage, but for day-to-day usage this looks resolved on 0.115.0.

Thanks.