›_ Codex Issues
Codex Issues / #24089

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

Resolved 💬 3 comments Opened May 22, 2026 by hik20 Closed Jun 29, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 3 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #24002
  • #24078
  • #24014
  • #23589

Powered by Codex Action

RASPIAUDIOadmin · 3 months ago

Proposed comment for openai/codex#24089

I can reproduce a closely related failure on Windows Codex Desktop after upgrading.

Environment

  • Codex Desktop package: OpenAI.Codex_26.519.5221.0_x64__2p2nqsd0c76g0
  • Codex Desktop app version: 26.519.5221.0
  • Active bundled CLI: codex-cli 0.133.0-alpha.1
  • Older still-installed CLI: codex-cli 0.130.0-alpha.5
  • OS: Windows 11 Pro, Microsoft Windows NT 10.0.26200.0, x64
  • Auth mode: ChatGPT / Codex OAuth

Problem

After updating Codex Desktop, old long-running Desktop threads can no longer be resumed reliably. When the app tries to auto-compact, the thread fails with:

Context automatically compacted
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"
  }
}

This is high impact because the local session store still contains many historical conversations, but the new Desktop agent cannot resume some of them anymore after the upgrade.

Additional evidence

On this machine there are roughly:

  • 160 thread records in state_5.sqlite
  • 102 rollout JSONL files under .codex/sessions
  • about 1.36 GB of rollout data

So the data is still present locally, but some upgraded sessions become unusable from the Desktop UI.

I tested two affected threads:

  1. Thread 019d684f-bc27-7eb2-812b-63e45d378a0f
  • New active CLI 0.133.0-alpha.1 fails with remote compaction / context_length_exceeded.
  • Older CLI 0.130.0-alpha.5 can still resume the same thread successfully.
  1. Thread 019e51a4-6d9c-7af2-a464-34247456623a
  • Even the older CLI cannot recover it because the reconstructed visible history is already far above the effective model window.
  • Observed diagnostics from the failing compaction path:
all_history_items_model_visible_bytes=9028200
failing_compaction_request_model_visible_bytes=9042893

This suggests two related failure modes:

  • A regression between 0.130.0-alpha.5 and 0.133.0-alpha.1 where some old rollouts that were resumable now fail during compaction.
  • Very large old Desktop rollouts can be reconstructed into an oversized state where remote compaction is invoked only after the request is already too large to compact.

Expected behavior

Codex Desktop should provide a safe migration/recovery path for old local Desktop rollouts after an update:

  • resume from the newest valid compacted checkpoint where possible;
  • avoid sending a compact request that already exceeds the model context window;
  • ignore or recompute invalid persisted token/context state after rollout replay;
  • expose a user-facing recovery action instead of making old threads unrecoverable;
  • ideally preserve access to historical conversations even if they must be opened in a read-only/recovered mode.

Partial workaround found locally

For moderately large old threads, launching the older 0.130.0-alpha.5 CLI against the same session can still recover/resume them.

BUT for very large threads, local rollout surgery can make the thread usable again only by backing up the full original rollout and rewriting the active rollout to a much smaller recovered suffix. This is risky and should ideally not be necessary for users.

etraut-openai contributor · 1 month ago

Thanks for reporting this problem. Until recently, Codex used a separate endpoint and server-side logic for compaction. We recently switched to a more robust approach where the compaction logic is moved locally using the same endpoint as normal turns. This eliminates "remote compaction" errors and increases the stability and reliability of compaction operations. If you see further problems with compaction, please use /feedback and open a new bug report.