macOS CLI/App: gpt-5.5 reports 950k context but fails around 260k input

What version of Codex CLI is running?

Terminal CLI: codex-cli 0.141.0

Codex app bundled CLI: codex-cli 0.142.0-alpha.1

Codex app version: 26.616.32156

What subscription do you have?

Pro

Which model were you using?

gpt-5.5, reasoning effort xhigh

What platform is your computer?

macOS 26.5 (25F71), Apple Silicon / arm64

What issue are you seeing?

Both Codex CLI-origin sessions and Codex app/Desktop-origin sessions are becoming unrecoverable with:

Codex ran out of room in the model's context window. Start a new thread or clear earlier history before retrying.

The suspicious part is that the active model metadata reports a 950k effective context window, but the session fails when an individual turn reaches roughly the old 258k-264k active input range.

Current local model metadata:

{
  "slug": "gpt-5.5",
  "context_window": 1000000,
  "max_context_window": 1000000,
  "effective_context_window_percent": 95,
  "effective_input_budget": 950000
}

I verified this from both the terminal CLI and the app-bundled CLI.

Local evidence

CLI-origin failure

Thread id: 019ee16d-dcdd-74c2-b695-ebb84c28b728

Last token-count events before the failure:

timestamp                         model_context_window  last_input_tokens  cumulative_input_tokens  cumulative_total_tokens
2026-06-19T20:25:47.589Z          950000                259628             9095382                  9134877
2026-06-19T20:26:00.225Z          950000                263127             9358509                  9398884
2026-06-19T20:26:09.437Z          950000                264113             9622622                  9663574
2026-06-19T20:26:12.355Z          950000                264113             9622622                  9663574
2026-06-19T20:26:12.358Z          950000                0                  0                        950000

The log DB records a codex_core::session::turn turn error for that thread at 2026-06-19 20:26:12 with the context-window error.

Codex app/Desktop-origin failure

Thread id: 019edca6-fe7d-7d90-a366-685b13a74419

Last token-count events before the failure:

timestamp                         model_context_window  last_input_tokens  cumulative_input_tokens  cumulative_total_tokens
2026-06-18T23:04:10.358Z          950000                223393             5825605                  5849870
2026-06-18T23:04:23.405Z          950000                227859             6053464                  6078348
2026-06-18T23:04:39.783Z          950000                259390             6312854                  6338392
2026-06-18T23:04:40.351Z          950000                259390             6312854                  6338392
2026-06-18T23:04:40.353Z          950000                0                  0                        950000

The log DB records a codex_core::session::turn turn error for that thread at 2026-06-18 23:04:40 with the same context-window error.

Why this looks like a bug

This does not look like a stale local catalog at process start. Both currently installed CLI paths report gpt-5.5 as 1,000,000 context / 950,000 effective input.

It looks more like one of these:

• the visible/session metadata path reports 950k, but a backend or remote-compaction path still enforces the old ~258k effective limit;
• remote compaction is not triggering early enough before that old boundary;
• or the turn is reset/null-completed after a failed compaction/context guard.

Related reports

This seems closely related to:

• https://github.com/openai/codex/issues/29080 (950k context but compacts/fails around 260k-270k)
• https://github.com/openai/codex/issues/29039 (Context window changes from 1M to 258K mid-thread)
• https://github.com/openai/codex/issues/28937 (exact app error on macOS)
• https://github.com/openai/codex/issues/23643 (context fills unusually fast / unrecoverable long sessions)

What steps can reproduce the bug?

I do not have a minimal deterministic reproduction yet. In practice it occurs during reasonably long gpt-5.5 xhigh sessions through both CLI and Codex app/Desktop. The failure appears when the last active turn input reaches roughly 259k-264k, despite model_context_window reporting 950000.

What is the expected behavior?

If the active session reports a 950k effective context window, it should not become unrecoverable around 260k active input. Codex should either:

• honor the 950k effective budget consistently across request, compaction, and backend paths; or
• display the true active enforced budget; and
• compact safely before the hard limit, without leaving the thread in a null/finished unrecoverable state.

Additional information

I can provide more local log snippets or upload feedback for the affected thread IDs if that is useful.