CLI startup path blocks ~5s on model catalog refresh even when cache exists

What version of Codex CLI is running?

codex-cli 0.141.0

What subscription do you have?

ChatGPT auth

Which model were you using?

gpt-5.5

What platform is your computer?

macOS 26.5.0 arm64

What terminal emulator and version are you using?

Ghostty 1.3.2

Request

Please make normal CLI startup/session initialization avoid waiting synchronously on a remote model catalog refresh when a usable cached or bundled catalog is already available.

A good outcome would be one of:

1. Use the existing models_cache.json immediately and refresh it in the background.
2. Add a config option to skip foreground remote model catalog refresh on startup.
3. Add a configurable TTL/stale-cache policy for the model catalog.
4. Fall back to the bundled catalog on slow refresh, similar to codex debug models --bundled.

What issue are you seeing?

Codex startup-like paths appear to block on a remote model catalog refresh for about 5 seconds, even when the refresh succeeds and the local model cache already exists.

This makes simple startup feel slow. The delay does not appear to come from local repo size, Git status, MCP startup, plugins, update checks, proxy settings, DNS, TCP, or TLS.

The clearest repro is:

time codex debug models
# observed: ~5.1s

time codex debug models --bundled
# observed: ~0.06-0.08s

codex debug prompt-input 'ping' also consistently takes about 5.3s, which makes this look relevant to normal startup/session initialization, not only the debug command.

What steps can reproduce the bug?

From a normal trusted Git repo:

time codex debug models >/tmp/codex-models.json
time codex debug models --bundled >/tmp/codex-models-bundled.json
time codex debug prompt-input 'ping' >/tmp/codex-prompt.json

Observed locally:

codex debug models                         ~5.1s
codex debug models --bundled               ~0.06-0.08s
codex debug prompt-input 'ping'             ~5.3s

What I tried

These did not remove the ~5s delay:

codex debug prompt-input -c 'check_for_update_on_startup=false' 'ping'
codex debug prompt-input -c 'model_catalog_json="/path/to/local/catalog.json"' 'ping'
codex debug models --disable remote_models
codex debug models --disable responses_websockets --disable responses_websockets_v2
env -u SSL_CERT_FILE -u NODE_EXTRA_CA_CERTS -u REQUESTS_CA_BUNDLE codex debug models

MCP and plugins also do not appear to be the cause:

codex debug prompt-input -c 'mcp_servers.node_repl.enabled=false' 'ping'
# still ~5.3s

Network/proxy checks

No proxy appears to be configured:

HTTP_PROXY/HTTPS_PROXY/ALL_PROXY: unset
scutil --proxy: empty
codex doctor: proxy env vars: none

Direct curl timing to ChatGPT is fast:

curl -sS -o /dev/null \
  -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} starttransfer=%{time_starttransfer} total=%{time_total} http=%{http_code}\n' \
  https://chatgpt.com/backend-api/

Observed:

dns≈0.002s connect≈0.008s tls≈0.019s total≈0.03-0.04s

--noproxy '*', HTTP/1.1, HTTP/2, and disabling custom CA env vars showed no meaningful difference.

Codex doctor

codex doctor --summary --ascii succeeds, but takes about 6s wall time. Individual reported durations are much smaller, for example:

network.websocket_reachability ~0.5s
network.provider_reachability  ~0.1s
updates.status                 ~0.3s

Expected behavior

Codex should not block normal startup-like paths on a foreground remote model catalog refresh when a usable cache or bundled catalog is available.

Related issues / PRs

This seems related but not identical to:

• #23119: model refresh child-process timeout / stderr spam
• #22205: features.remote_models=false does not suppress refresh for Azure custom provider
• #24286: OpenRouter catalog parsing fails during startup
• #27208: serialize model catalog refreshes
• #28699: app-server keeps model cache warm

The difference here is that the default OpenAI/ChatGPT-auth path succeeds, but still adds a repeatable ~5s foreground delay.