[BUG] Built-in edit/patch actions fail with gpt-5.4 (xhigh), but work with gpt-5.3-codex (xhigh)

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

• #13574
• #12350
• #12241

Powered by Codex Action

I figured out why it is the case. Codex pulls parameters/tools for models from a model configuration file. When you have a ChatGPT subscription, it fetches that metadata from the server. Without a ChatGPT sub, it uses the json that's bundled with Codex itself.

The big problem: when a new model comes out, Codex updates it on their ChatGPT backend so if you have a subscription, Codex will fetch the updated model list and all works fine.

But, if you're using a proxy or a custom API key, this will not work properly for newer models, because, if there's no "gpt-5.4" entry in the bundled json, Codex falls back to a very pessimistic generic config for the model that doesn't let it use good tools.

Now, Codex does have GPT 5.4 in the repo, but it wasn't released with Codex 0.111, so you have to wait for the next release.

The solution right now is one of these:

1. Wait for the next Codex release
2. Auth with ChatGPT in Codex (even a free sub will work), open it, check that in /models you see the new gpt-5.4, then exit, change the config back to your older setup with a custom proxy/API key. Then you should edit the config to add this: model_catalog_json = "/Users/dian/.codex/models_cache.json". This is needed because the normal cache TTL is 5 minutes.
3. Download the newest nightly Codex build or build Codex yourself.

Codex' own explanation:

Yes. Why older models work - Codex ships with a built-in static model catalog in codex-rs/core/models.json. - gpt-5.3-codex is explicitly in that bundled file at codex-rs/core/models.json:21. - gpt-5.2-codex is too at codex-rs/core/models.json:166. - So even without a live /models refresh, Codex already knows those models’ metadata: visibility, shell type, patch tool type, context window, instructions, etc. What that means - If you pick an older model that exists in the bundled catalog, Codex gives it the full intended wiring. - If you pick a model Codex does not know, it falls back to generic metadata from codex-rs/core/src/models_manager/model_info.rs:61. - That fallback is intentionally weak: - visibility = None - apply_patch_tool_type = None - generic instructions - So known older models feel “fully supported,” while unknown/newer ones can feel degraded. Important nuance - gpt-5.3-codex and gpt-5.4 are both wired in current repo metadata as apply_patch_tool_type = "freeform". - gpt-5.3-codex: codex-rs/core/models.json:7 - gpt-5.4: codex-rs/core/models.json:81 So if gpt-5.3-codex works fine with your proxy but gpt-5.4 doesn’t, that points less to a generic Codex tool-wiring difference and more to one of these: - your running binary had built-in support for gpt-5.3-codex earlier than for gpt-5.4 - your proxy/model handles gpt-5.3-codex better than gpt-5.4 - gpt-5.4’s much larger built-in instructions change how it reasons about custom/freeform tools Direct answer - Yes, Codex has built-in data for gpt-5.3-codex. - And yes, that’s a big reason older models “just work.” If you want, I can diff the cached gpt-5.4 entry against bundled gpt-5.3-codex and show exactly what changed that might be tripping your proxy/model.