Windows Desktop: saved thread remains blocked after repeated context_window_exceeded during remote compaction

Summary

A long-lived Codex Desktop thread on Windows can no longer continue: a short follow-up fails with context_window_exceeded, then two subsequent attempts fail inside remote compaction with the same error. No assistant response is produced. This report concerns recovery from the failed compaction state; the root cause is not established.

Environment

• Windows, OS version 10.0.26200.0.
• Surface: Codex Desktop app.
• Locally installed CLI reports codex-cli 0.153.4. This is not a verified Desktop app/backend version; the Desktop About version was not available from the inspected executable metadata.
• Subscription: not included in this public report.
• Observed on September 9, 2026. Times below are UTC.

Steps observed

1. Continue an existing, long-running Desktop coding thread containing tool calls and file changes.
2. Send the short message 继续 (continue), rather than a large pasted input.
3. The turn terminates with context_window_exceeded and no assistant message.
4. Retry continuation. Two subsequent attempts terminate with Error running remote compact task and the same context-window error.

This reproduces repeatedly on the affected saved thread. A minimal synthetic reproduction has not been established.

Actual behavior and sanitized log evidence

Extracted from local rollout task_complete events; project text, local paths, account details, and session identifiers are omitted.

First error:

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

Next two errors:

Error running remote compact task: Codex ran out of room in the model's context window. Start a new thread or clear earlier history before retrying.

All three completion records have codex_error_info: context_window_exceeded and last_agent_message: null.

The first failing attempt reports model_context_window: 258400. Its final token-count record reports total_tokens: 258400, while input/output/reasoning counters are zero. These are the recorded values, not an independently measured request token count; they may reflect error bookkeeping.

Desktop task status subsequently reports systemError.

Expected behavior

Compaction should recover the saved thread, or provide a working bounded recovery path that preserves its history. Retrying a short continuation should not remain stuck in repeated context-window errors inside the recovery/compaction operation itself.

Additional context and evidence limits

• Another substantially larger saved conversation on the same machine remained active. On-disk history size is not model-visible context size and is not offered as proof of a cause.
• The triggering request payload and compaction payload were not inspected, so this report does not claim premature/late compaction, inflated history reconstruction, or a particular model mismatch as the cause.
• A fresh task in the same workspace can run normally; this is a workaround, not proof the original thread is repaired.
• No raw conversation archive or screenshot is attached because it contains unrelated private project content.
• No in-app /feedback upload was performed, and no feedback ID is claimed.

Related: #28937 and #29041. In https://github.com/openai/codex/issues/28937#issuecomment-4835188252 a maintainer requested a new bug report if compaction problems persist after the compaction changes. This is a newly observed failure with the literal remote-compaction error still present; the installed CLI version alone does not establish which backend build the Desktop app used.

Start by examining the saved-thread recovery path and the task_complete events for context_window_exceeded and Error running remote compact task. Reproduce the repeated failure if possible and compare the initial continuation with subsequent remote compaction attempts. Done means the affected thread can recover or receives a working bounded recovery path without repeating the context-window error.