Old Desktop rollouts resume into impossible context usage and remote compact fails with context_length_exceeded

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

26.519.31651

What subscription do you have?

Plus

What platform is your computer?

Microsoft Windows NT 10.0.22631.0 x64

What issue are you seeing?

After upgrading to Codex CLI/Desktop 0.130.0, multiple old Codex Desktop threads became unusable.

The Codex App automatic compaction fails with this error:

Error running remote compact task: {
"error": {
"message": "Your input exceeds the context window of this model. Please adjust your input and try again.",
"type": "invalid_request_error",
"param": "input",
"code": "context_length_exceeded"
}
}
The same affected threads show impossible current context usage in CLI /status, for example:

Context window: 0% left (4.28M used / 570K)
Context window: 0% left (777K used / 258K)
This does not look like only a display issue. In the local rollout JSONL, the bad value is persisted as event_msg.token_count.info.last_token_usage.total_tokens, and that value is greater than model_context_window.

Two affected old Desktop rollouts were recovered locally by keeping the newest surviving compacted checkpoint with replacement_history, keeping the suffix after it, and dropping impossible token-count events where last_token_usage.total_tokens > model_context_window.

What steps can reproduce the bug?

I can reproduce this with old long-running Codex Desktop rollouts created before the latest update and then resumed in Codex 0.130.0.

Example A:

• Old rollout source: Codex Desktop 0.115.0-alpha.27
• Model: gpt-5.5
• Session id: 019d2495-554f-7ba2-9473-5e057606c933
• Rollout size before recovery: about 29,702 lines / 88 MB
• Last valid token count near the end: 194,175 / 258,400
• After resume/rollback, persisted token counts jumped to 4,284,409 / 258,400 and 4,279,808 / 570,000

Example B:

• Old rollout source: Codex Desktop 0.118.0-alpha.2
• Model: gpt-5.5
• Session id: 019d86ea-26ca-7ad2-82c1-4a0e79d998a2
• Rollout size before recovery: about 7,309 lines / 19.5 MB
• CLI /status: 777K used / 258K
• Persisted bad token count: 776,657 / 258,400

Recovery that worked locally:

1. Locate the newest line where type is "compacted" and payload.replacement_history exists.
2. Preserve the first session_meta line.
3. Preserve the turn start immediately preceding that compaction checkpoint plus all newer lines.
4. Drop any event_msg.token_count where last_token_usage.total_tokens is greater than model_context_window.
5. Replace the rollout after creating a backup.

After this recovery, both old threads became usable again.

What is the expected behavior?

Resume and rollback should not reconstruct active history in a way that ignores or bypasses the latest surviving "CompactedItem.replacement_history" checkpoint.

If a persisted token-count snapshot has "last_token_usage.total_tokens > model_context_window", Codex should not treat that as valid current context usage after resume. It should recompute from reconstructed history, ignore the impossible snapshot, or offer a safe local recovery path.

Remote compact should not be invoked with an input that already exceeds the model context window because of inflated reconstructed rollout history.

Additional information

This may be related to existing reports about /status context display and GPT-5.5 compaction failures, but in this case the local rollout contains persisted impossible last_token_usage values after resume/rollback replay.

The affected rollouts still contained valid compacted checkpoints with replacement_history. Using the newest checkpoint plus suffix was enough to recover them locally.

Codex App version: 26.519.31651
CLI version: 0.130.0
Platform: Microsoft Windows NT 10.0.22631.0 x64
Subscription: Plus