›_ Codex Issues
Codex Issues / #33146

Codex CLI /model picker hides GPT-5.6 when models_cache.json is stale

Open 💬 3 comments Opened Jul 14, 2026 by msugas-giga
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

On one Linux machine, the Codex CLI /model picker does not show any GPT-5.6 options even though the same ChatGPT login shows GPT-5.6 options on another laptop.

The local CLI has a stale-looking model cache:

  • Running binary: codex-cli 0.144.4
  • codex doctor runtime version: 0.144.4
  • ~/.codex/models_cache.json has client_version: "0.142.3"
  • ~/.codex/models_cache.json was refreshed today but contains only 5 models:
  • gpt-5.5
  • gpt-5.4
  • gpt-5.4-mini
  • gpt-5.3-codex-spark
  • codex-auto-review
  • codex debug models --bundled shows the expected GPT-5.6 variants:
  • gpt-5.6-sol
  • gpt-5.6-terra
  • gpt-5.6-luna
  • gpt-5.5

This looks like the interactive /model picker may be using ~/.codex/models_cache.json, while codex debug models --bundled or the bundled catalog includes GPT-5.6. The result is that the user cannot select GPT-5.6 from /model on this machine despite the model being available on another machine under the same login.

Environment

  • OS: Ubuntu 26.4.0, linux-x86_64
  • Codex CLI: 0.144.4
  • Install method: standalone
  • Auth mode: ChatGPT sign-in
  • Config default model: gpt-5.5
  • Network in the inspected Codex session was restricted, so codex doctor reported provider reachability failures from that sandboxed diagnostic context.

Evidence

codex --version:

codex-cli 0.144.4

codex doctor --json reports:

codexVersion: 0.144.4
auth mode: chatgpt
config model: gpt-5.5
runtime platform: linux-x86_64

jq -r '.client_version, .fetched_at, (.models|length), (.models[].slug)' ~/.codex/models_cache.json:

0.142.3
2026-07-14T20:10:25.510056173Z
5
gpt-5.5
gpt-5.4
gpt-5.4-mini
gpt-5.3-codex-spark
codex-auto-review

codex debug models --bundled | jq -r '.models[] | select(.slug | test("gpt-5\\.6|gpt-5\\.5")) | [.slug, .display_name, .visibility] | @tsv':

gpt-5.6-sol	GPT-5.6-Sol	list
gpt-5.6-terra	GPT-5.6-Terra	list
gpt-5.6-luna	GPT-5.6-Luna	list
gpt-5.5	GPT-5.5	list

Expected behavior

/model should show the same GPT-5.6 options available to the account and supported by the installed CLI, or it should invalidate/refresh an older model cache when the CLI version changes.

Actual behavior

/model does not show GPT-5.6 options on this machine, despite another laptop with the same login showing them.

Suspected cause

The persisted ~/.codex/models_cache.json appears to be refreshed with an old client_version value and an older model list, and the TUI picker appears to use that stale cache instead of the bundled/current model list.

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

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

  • #32482
  • #33023
  • #32034

Powered by Codex Action

ulgerang · 1 month ago

Confirmed on Linux with ChatGPT auth. This reproduces even after terminating the existing app-server proxy and rebuilding the cache.

Environment:

  • /usr/bin/codex --version = 0.144.4
  • ~/.local/bin/codex --version = 0.144.4 (standalone current release)
  • codex debug models --bundled lists gpt-5.6-sol, gpt-5.6-terra, and gpt-5.6-luna with visibility: list.

Reproduction and observation:

  1. Stop the pre-existing codex app-server proxy process.
  2. Rebuild ~/.codex/models_cache.json using /usr/bin/codex debug models. The resulting cache is stamped client_version: "0.144.4" and contains all three GPT-5.6 variants.
  3. Start a fresh interactive /usr/bin/codex session and run /model.
  4. The picker still only shows gpt-5.5, gpt-5.4, gpt-5.4-mini, and gpt-5.3-codex-spark.
  5. That session starts a new codex app-server proxy from the standalone 0.144.4 release. Immediately afterwards, the shared cache is rewritten as client_version: "0.142.5" with only those five older entries.

So a stale pre-existing process can trigger the issue, but it is not required here: the newly started proxy reports an older model-manager cache version despite its executable reporting 0.144.4. The single shared cache is then poisoned for the TUI picker.

models-manager/src/cache.rs only accepts a cache whose client_version exactly matches the current process, and models-manager/src/manager.rs uses one global models_cache.json. This makes a proxy with an older effective client version able to replace a newer catalog.

Suggested regression coverage: launch the CLI and app-server/proxy versions against the same CODEX_HOME, verify the proxy does not rewrite a newer cache with a lower client version or a smaller picker-visible catalog, and verify /model still lists all three GPT-5.6 variants. A durable fix could align the proxy's reported client version with the executable version, or namespace the cache by producer version so mixed runtimes cannot clobber one another.

Showing cached comments. Read the full discussion on GitHub ↗