Mid-session catalog refresh injects persistent model-override ban; restart repeats it

What version of Codex CLI is running?

codex-cli 0.151.0

What subscription do you have?

ChatGPT authentication.

Which model were you using?

The parent session was itself launched successfully with:

-m gpt-5.6-sol -c model_reasoning_effort=high

What platform is your computer?

macOS, Apple Silicon.

What issue are you seeing?

A live Codex session receives this new developer instruction after the model catalog refreshes:

<multi_agent_mode>The model catalog changed after Codex started; do not set model or reasoning_effort overrides until Codex restarts.</multi_agent_mode>

The guard is injected even though the active model and effort remain present and compatible in the refreshed catalog. It is also worded globally, so the model refuses to pass model/effort arguments to an independently launched new Codex process (in this case a Superset/First Mate worker), even though that launch does not use the current thread's built-in spawn_agent catalog.

Restarting is not an effective recovery: the same sequence recurs after starting a fresh session and waiting for the asynchronous catalog refresh.

The exact warning text is not present in the open-source repository, installed binary strings, local config, or the resulting models_cache.json; it appears to be runtime/orchestrator-supplied. The client-side catalog refresh and instruction publication paths are open source and seem to expose the trigger.

Observed timeline

On one fresh reproduction:

1. 17:05:59 EDT — Codex process starts as gpt-5.6-sol / high.
2. The session works normally.
3. 17:10:15 EDT — a new user turn starts.
4. 17:10:16 EDT — ~/.codex/models_cache.json is refreshed (fetched_at = 2026-08-30T21:10:16.123667Z).
5. The cache still reports:
   • client_version = 0.151.0
   • gpt-5.6-sol.multi_agent_version = v2
   • supported reasoning levels include high
6. The next model context receives the <multi_agent_mode> guard above.
7. Restarting and retrying eventually produces the same post-start refresh and guard.

Other simultaneous Codex surfaces were running against the same CODEX_HOME, so this may be a downstream manifestation of the originator/cache-isolation problem in #33593. This report is specifically about the resulting model-visible safety instruction, its overly broad scope, and the ineffective restart recovery.

Relevant source paths

At current main (94cbbddafc1776d5e377bca1b05932c697e82238):

• The model manager uses one global models_cache.json and a 300-second TTL:
  https://github.com/openai/codex/blob/94cbbddafc1776d5e377bca1b05932c697e82238/codex-rs/models-manager/src/manager.rs#L29-L30
• Cache eligibility still has a TODO for provider identity and currently validates primarily by client version:
  https://github.com/openai/codex/blob/94cbbddafc1776d5e377bca1b05932c697e82238/codex-rs/models-manager/src/manager.rs#L477-L509
• A changed X-Models-Etag intentionally refreshes /models during a running turn:
  https://github.com/openai/codex/blob/94cbbddafc1776d5e377bca1b05932c697e82238/codex-rs/core/tests/suite/models_etag_responses.rs#L35-L100
• Catalog-provided collaboration instructions intentionally refresh without a model or mode change:
  https://github.com/openai/codex/blob/94cbbddafc1776d5e377bca1b05932c697e82238/codex-rs/core/tests/suite/collaboration_instructions.rs#L240-L324
• A custom multi-agent mode renders arbitrary runtime-provided hint text as a developer message:
  https://github.com/openai/codex/blob/94cbbddafc1776d5e377bca1b05932c697e82238/codex-rs/core/src/context/multi_agent_mode_instructions.rs#L41-L52

Steps to reproduce

1. Use ChatGPT auth and a shared CODEX_HOME with two Codex surfaces/app-server originators running.
2. Start a new CLI session pinned to gpt-5.6-sol / high.
3. Record the process start time and models_cache.json metadata.
4. Continue sending turns until the cache refreshes or the Responses stream reports a different X-Models-Etag.
5. Inspect the following turn's developer context.
6. Observe the catalog-change <multi_agent_mode> guard even when Sol/high remains supported.
7. Restart the CLI and repeat; the asynchronous refresh can recreate the condition.

Expected behavior

• An equal or backward-compatible catalog refresh must not inject a model-override ban.
• Any safety comparison should use a semantic, identity-scoped catalog diff rather than cache freshness or a cross-originator cache replacement.
• If the concern is only the current thread's built-in multi-agent tool catalog, the instruction must explicitly scope itself to those tool arguments rather than all commands that launch another Codex process.
• Restart guidance should clear the condition; if the first post-start refresh can immediately recreate it, the runtime should recover automatically or provide actionable diagnostics.

Related issues

• #33593 — shared models_cache.json oscillates between originator-specific catalogs. Likely upstream trigger, but does not track this injected policy/restart-loop symptom.
• #35129 — model_catalog_json remains stale in a running app-server. Different custom-catalog refresh problem.
• #37536 — stale app-server process can preserve old subagent model filtering. Different version-skew mechanism.

Start in codex-rs/models-manager/src/manager.rs, then trace the refresh coverage in core/tests/suite/models_etag_responses.rs and collaboration_instructions.rs through core/src/context/multi_agent_mode_instructions.rs. Reproduce the shared-cache refresh with compatible model settings and verify that the resulting developer instruction is correctly scoped and does not recur after restart.