Codex Desktop 26.903.9818: context limit leaves long Windows task unrecoverable and hides intact history

What version of the Codex App are you using (From “About Codex” dialog)?

Codex Desktop 26.903.9818.0
Bundled/local CLI: codex-cli 0.153.4

What subscription do you have?

Pro

What platform is your computer?

Microsoft Windows 11 Pro, version 10.0.26200, build 26200, 64-bit

What issue are you seeing?

A long-running Codex Desktop task has become inaccessible after reaching the model context limit. An ordinary follow-up runs for about 80–90 seconds and then fails with:

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

The serious additional regression is that the desktop UI now displays only the most recent failed user message. All earlier conversation history appears to be gone. The thread-reading API also returns only that failed turn with hasMore: false.

The on-disk rollout is still present and structurally readable, so this appears to be a history projection/loading failure rather than deletion:

• Rollout size: 59,183,127 bytes
• 99 user messages and 231 assistant messages
• 74 turn-context records
• One earlier successful top-level compaction record
• Zero JSON parse errors in a full line-by-line structural scan
• The last recorded token count is exactly 570,000, matching the effective reported model context window of 570,000

The task used gpt-5.6-sol at medium reasoning. At the time of failure the normal configuration was:

model_context_window = 600000
model_auto_compact_token_limit = 350000

The original transcript and logs are preserved privately, but are not attached because they contain project and customer information.

What steps can reproduce the bug?

This is the observed sequence rather than a synthetic minimal reproduction:

1. Use a long-running Codex Desktop task over many turns. The affected task had previously compacted successfully.
2. Update Codex Desktop to the current build.
3. Reopen the task and send a short, ordinary follow-up.
4. Wait about 80–90 seconds.
5. The turn fails with the context-window error above.
6. Reopen or inspect the task. The UI shows only the latest failed prompt instead of the previous history.
7. Inspect the task through the thread-reading API. It likewise reports only the final failed turn and hasMore: false, despite the intact 59 MB rollout containing the full conversation.
8. Create a non-destructive fork and try manual /compact. In this case the fork inherited the same unusable context state, ran for about 80 seconds, and failed with the same context-window error.

A separate attempt to resume/compact the original transcript through the local app-server was also blocked because the desktop process still owned the active writer. No transcript files were edited or deleted.

What is the expected behavior?

• Automatic compaction should run before the task reaches a permanently unrecoverable context state.
• Manual compaction should provide a safe recovery path when automatic compaction fails.
• A failed turn or compaction must not make the existing conversation history disappear from the desktop UI.
• If the local rollout is intact, the desktop history projection should rebuild from it rather than report only the final failed turn with no older pages.
• Forking an affected task should either produce a recoverable compacted copy or clearly offer a supported recovery option.

Additional information

This began after a recent Codex Desktop update. Other long-running tasks are important, so a supported recovery path that preserves history is urgently needed.

The full private transcript has been backed up byte-for-byte. I can provide a feedback/session ID or a sanitized diagnostic extract privately if a maintainer requests it.

Related reports with overlapping symptoms:

• #43963: Windows task remains blocked after repeated context-window failures
• #44363: compaction associated with missing conversation transcript
• #42311: desktop UI history disappears after compaction
• #41986: Windows app history projection disappears while JSONL remains intact
• #24230: earlier context-window/compaction regression

Start with the desktop thread-reading API and local app-server behavior, then compare their history projection with the intact rollout described in the issue. Reproduce the context-limit failure on Windows if possible; done means failed turns no longer hide intact history and a supported automatic, manual, or fork-based recovery path works.