## Reproduction 1. Set the current model to `gpt-5.3-codex`. 2. Start Codex and wait for the migration prompt that recommends `gpt-5.4`. 3. Explicitly choose `Use existing model`. 4. Check `~/.codex/config.toml`. ## Actual behavior Codex writes the following entry: ```toml [notice.model_migrations] "gpt-5.3-codex" = "gpt-5.4" ``` ## Why this is a problem - This looks like a real model redirect, not like “I already saw this migration prompt.” - The user explicitly chose to keep the existing mo

Model migration prompt stores acknowledgements as [notice.model_migrations] mappings when keeping the existing model

Resolved 💬 5 comments Opened Apr 18, 2026 by Eric-Terminal Closed Apr 18, 2026

💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

Reproduction

Set the current model to gpt-5.3-codex.
Start Codex and wait for the migration prompt that recommends gpt-5.4.
Explicitly choose Use existing model.
Check ~/.codex/config.toml.

Actual behavior

Codex writes the following entry:

[notice.model_migrations]
"gpt-5.3-codex" = "gpt-5.4"

Why this is a problem

This looks like a real model redirect, not like “I already saw this migration prompt.”
The user explicitly chose to keep the existing model, but the config now contains an old -> new mapping that strongly suggests Codex may still route requests to the new model.
In the current implementation, this field is mainly used to suppress the prompt on later launches, not to persist the actual model selection. That makes the table name and stored value misleading.

Expected behavior

Store “model migration prompt acknowledged” state in a separate config table with explicit semantics.
Do not keep writing old -> new mappings under [notice.model_migrations] when the user chooses Use existing model.
Continue reading the legacy field for backwards compatibility so existing users do not get prompted again.

Related but different

#15009 is about adding a global switch to disable all model migration notices.
#11045 is about migration prompts showing up too often.
This issue is about the config semantics being misleading enough that users can no longer trust what model they are actually using.

View original on GitHub ↗

5 Comments

Eric-Terminal · 4 months ago

I have the patch ready and pushed to my fork here:

https://github.com/openai/codex/compare/main...Eric-Terminal:fix/model-migration-acknowledgement-config?expand=1

I tried to open a PR, but GitHub blocks it on this repository because pull requests are currently limited to collaborators.

The change is ready to review and includes:

storing migration prompt acknowledgements in a dedicated notice.model_migration_prompt_acknowledgements table
stopping new writes to notice.model_migrations
continuing to read the legacy field so existing users do not get prompted again

If you want, I can open the PR immediately once external PRs are allowed, or a maintainer can cherry-pick/adapt the patch from the compare link above.

etraut-openai contributor · 4 months ago

This mechanism is working as intended, so we don't consider this a bug.

Eric-Terminal · 4 months ago

This mechanism is working as intended, so we don't consider this a bug.

But... if the program behaves this way, whether I select gpt-5.3-codex or gpt-5.4, it ultimately calls gpt-5.4 anyway... Furthermore, selecting gpt-5.3-codex silently swaps it to gpt-5.4 behind the scenes, leaving me with no way to actually use gpt-5.3-codex... Is this really working as intended?

etraut-openai contributor · 4 months ago

The [notice.model_migrations] portion of the config is used by the TUI to remember whether it has already told you about a new available model. This way, it won't continue to tell you about it every time you launch the CLI. It does not affect which model you have selected or which models are available for you to select using the /model slash command.

Eric-Terminal · 4 months ago

Thanks for the clarification, and sorry for the confusion and for sending everyone on a bit of a wild goose chase here.

I re-checked the code and I agree that I overstated the behavior in my previous comment.

What threw me off was the shape of [notice.model_migrations] in config.toml: an old -> new mapping looks a lot like actual model-selection state, so I read it as a silent redirect rather than a notice-tracking mechanism. After looking again, I understand that it is only used to suppress repeated migration notices and does not itself change the selected model.

So my actual concern is narrower than I first described: even if this is working as intended, the config semantics are easy to misread, and they convinced me I had caught a hidden switch to gpt-5.4 when I had in fact just confused myself.

Thanks again for the explanation, and sorry again for the noise.😂