Skip to content

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

Closed
Closed
Old Desktop rollouts resume into impossible context usage and remote compact fails with context_length_exceeded#24089
Labels
appIssues related to the Codex desktop appbugSomething isn't workingcontextIssues related to context management (including compaction)sessionIssues involving session (thread) management, resuming, forking, naming, archivingwindows-osIssues related to Codex on Windows systems

Description

@hik20
hik20
opened on May 22, 2026

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

Activity

  1. hik20
    added
    appIssues related to the Codex desktop app
    on May 22, 2026
  2. github-actions
    added
    bugSomething isn't working
    windows-osIssues related to Codex on Windows systems
    contextIssues related to context management (including compaction)
    sessionIssues involving session (thread) management, resuming, forking, naming, archiving
    on May 22, 2026

  3. github-actions commented on May 22, 2026

    @github-actions
    github-actionsbot
    on May 22, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  4. RASPIAUDIOadmin commented on May 23, 2026

    @RASPIAUDIOadmin
    RASPIAUDIOadmin
    on May 23, 2026

    Proposed comment for #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.

    2. 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.

  5. etraut-openai commented on Jun 29, 2026

    @etraut-openai
    etraut-openai
    on Jun 29, 2026
    Contributor

    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.

  6. etraut-openai
    closed this as completedon Jun 29, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingcontextIssues related to context management (including compaction)sessionIssues involving session (thread) management, resuming, forking, naming, archivingwindows-osIssues related to Codex on Windows systems

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions