Codex Desktop crash: codex_models_manager failed to renew cache TTL after EOF parsing model cache

What version of Codex is running?

Codex Desktop app on Windows:

• OpenAI.Codex app package version: 26.623.11225.0
• Package full name: OpenAI.Codex_26.623.11225.0_x64__2p2nqsd0c76g0
• codex --version: codex-cli 0.142.3
• The recovered model cache currently reports client_version: "0.142.5"

What subscription do you have?

Paid ChatGPT Pro workflow, using Codex Desktop for long-running local engineering sessions.

What platform is your computer?

Windows 11 x64. User paths are under C:\Users\adpen\....

What terminal/surface are you using?

Codex Desktop app on Windows. This was the full Desktop crash page, not only CLI stderr.

What issue are you seeing?

Codex Desktop crashed with:

code=3221225786, signal=null

Most recent error from the crash page:

{"timestamp":"2026-07-01T19:45:00.081098Z","level":"ERROR","fields":{"message":"failed to renew cache TTL. EOF while parsing a value at line 1 column 0"},"target":"codex_models_manager::manager"}

This appears to be in the model catalog/cache refresh path. A stale, missing, empty, truncated, or temporarily malformed model cache/refresh payload should not crash the Desktop control plane. It should fail soft to the last-known-good cache, a bundled catalog, or a background retry.

What steps can reproduce the bug?

I do not have a deterministic minimal reproducer yet, but the observed conditions are:

1. Run a long-lived Codex Desktop session on Windows doing real repo work with repeated tool calls and long-running state.
2. Let the model cache TTL expire or otherwise cause model-cache renewal to happen while the Desktop session is active.
3. Codex Desktop crashes during TTL renewal with codex_models_manager::manager: failed to renew cache TTL. EOF while parsing a value at line 1 column 0.

Local evidence:

• Cache path: %USERPROFILE%\.codex\models_cache.json
• The cache was valid after reload, not permanently corrupt.
• After recovery, the cache file was 178074 bytes and started with:

{
  "fetched_at": "2026-07-01T19:54:06.185500700Z",
  "etag": "W/\"d5ec51c0d218e9a0503ff4bd047d253b\"",
  "client_version": "0.142.5",
  "models": [

That makes this look like a transient empty/truncated read or response during renewal, not a user-maintained bad JSON file.

Suggested maintainer repro attempt:

1. On Windows Codex Desktop, start a normal authenticated session.
2. Move %USERPROFILE%\.codex\models_cache.json aside or wait for the cache TTL to expire.
3. Trigger whatever Desktop/app-server path refreshes the model catalog while a thread is active.
4. Simulate or observe an empty/truncated model refresh payload/cache file.
5. Verify whether codex_models_manager::manager handles EOF while parsing a value at line 1 column 0 as a non-fatal stale-cache miss or whether the Desktop crash page appears.

What is the expected behavior?

The model-cache TTL renewal path should be atomic and fail-soft:

• Never crash Desktop because a model catalog refresh produced EOF, empty JSON, invalid JSON, timeout, partial write, or truncated read.
• Prefer the current in-memory catalog, last-known-good models_cache.json, or bundled catalog when refresh fails.
• Refresh in the background with backoff instead of destabilizing an active session.
• Write refreshed cache atomically: validate JSON in memory/temp file first, then rename.
• Do not expose empty or partially written cache files to concurrent readers.
• Surface a bounded warning/log entry instead of ending the session.

Why this matters

This is not cosmetic. In a mission-critical long-running engineering session, I have hit roughly a dozen distinct Codex crash/error modes across Desktop/Windows/tooling paths. Each one costs recovery time, lost work, context rebuild, and tokens, and those tokens and time are real money in a paid $200/month workflow.

Bluntly: a model-cache TTL renewal should be one of the most boring, recoverable paths in the product. Crashing the entire Desktop session on EOF parsing makes Codex on Windows feel unsafe for serious extended work. The product is otherwise powerful enough that people want to trust it for large engineering arcs, but these control-plane crashes make that trust expensive.

Related issues

This appears related to the model-manager/cache family but distinct from the exact issues I found:

• https://github.com/openai/codex/issues/23119: same codex_models_manager::manager model cache/TTL area, but reported as child-process timeout/stderr noise on cold or stale cache.
• https://github.com/openai/codex/issues/28877: asks for using cached/bundled catalog immediately and refreshing in the background instead of blocking startup-like paths.
• https://github.com/openai/codex/issues/24286: model catalog parsing failure path for a custom provider response shape.

I searched for the exact failed to renew cache TTL. EOF while parsing a value string and did not find an existing public issue.

Temporary workaround tested locally

As a local mitigation, I copied the current valid %USERPROFILE%\.codex\models_cache.json to %USERPROFILE%\.codex\model_catalog.local.json and set:

model_catalog_json = "C:\\Users\\adpen\\.codex\\model_catalog.local.json"

codex debug models then returned successfully in about 0.56s, suggesting the static local catalog path can avoid the foreground TTL-renewal path for this environment. This is only a workaround: it can drift stale and should not be required for Desktop stability.

Additional context

The crash screenshot showed the Desktop overlay metrics at the time:

• FPS N/A
• GPU 22%
• CPU 14%
• LAT N/A

The visible crash text was:

An error has occurred
Codex crashed with the following error:

  (code=3221225786, signal=null).
Most recent error: {"timestamp":"2026-07-01T19:45:00.081098Z","level":"ERROR","fields":{"message":"failed to renew cache TTL. EOF while parsing a value at line 1 column 0"},"target":"codex_models_manager::manager"}