Skip to content

Remote compact can create huge compacted records and make session unrecoverable #24191

Closed
Closed
Remote compact can create huge compacted records and make session unrecoverable#24191
Labels
CLIIssues related to the Codex CLIbugSomething isn't workingcontextIssues related to context management (including compaction)sessionIssues involving session (thread) management, resuming, forking, naming, archiving

Description

@huzp611
huzp611
opened on May 23, 2026

Summary

A long-running Codex CLI session became unusable because remote compaction persisted very large compacted records. Future resume/compact attempts exceeded the model context window even though normal user/assistant messages were not the main source of size.

Environment

  • Package: @openai/codex
  • Codex CLI version: 0.133.0
  • Install path: /opt/homebrew/lib/node_modules/@openai/codex
  • Repository metadata: github.com/openai/codex, directory codex-cli
  • Platform: macOS
  • Model shown in CLI: gpt-5.5, reasoning high, summaries auto
  • Session cwd: /Volumes/T7/3333_Deveploment/12_MonetizingYourKnowledge

Error messages

Your input exceeds the context window of this model. Please adjust your input and try again.

Later, after trying to resume:

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

What I found

The session JSONL had grown to 892 MB. Size by record type showed that compacted records dominated the file:

783.6 MB    62      compacted//
 38.9 MB    4591    turn_context//
 19.0 MB     707    response_item/message/user
 18.3 MB    5412    response_item/function_call_output/
 11.3 MB    3648    response_item/reasoning/
  9.3 MB   13437    event_msg/token_count/

Largest lines were all compacted records:

19.3 MB line=42045 compacted//
19.3 MB line=41903 compacted//
19.3 MB line=42190 compacted//
18.9 MB line=41358 compacted//
18.9 MB line=41590 compacted//

Removing compacted, tool outputs, token counts, reasoning records, and binary image/attachment metadata made the session usable again. A recent-context slimmed file was about 22 KB and could show the recent history again.

Expected behavior

Compaction should produce a bounded summary and should never make a session unrecoverable.

Actual behavior

Repeated/remote compaction produced or retained huge compacted records. These records appear to be recursively included or otherwise unbounded, eventually making resume/compact impossible.

Suggested fixes

  • Enforce a hard byte/token limit on each compacted record.
  • Avoid including previous compacted payloads in future compact input.
  • If remote compact fails, do not persist partial or oversized compact data.
  • Add a repair/prune command, e.g. codex debug prune-session <id> --drop compacted,function_call_output,token_count,reasoning.
  • Ensure resume can fall back to recent user/assistant/event messages when compacted state is corrupt.

Activity

  1. github-actions
    added
    bugSomething isn't working
    CLIIssues related to the Codex CLI
    contextIssues related to context management (including compaction)
    sessionIssues involving session (thread) management, resuming, forking, naming, archiving
    on May 23, 2026

  2. github-actions commented on May 23, 2026

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

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

    Powered by Codex Action

  3. Osanosa commented on May 23, 2026

    @Osanosa
    Osanosa
    on May 23, 2026

    +1
    had to perform lobotomy and strip everything i could

  4. huzp611 commented on May 23, 2026

    @huzp611
    huzp611
    on May 23, 2026
    Author

    Thanks. I reviewed the linked issues.

    I agree this is related to #23257, #23589, #24014, #24002, and #24100, but I do not think #24191 is a full duplicate.

    The main difference in this report is that the session became unrecoverable because persisted compacted records themselves grew without a safe bound. In my affected CLI session, the rollout JSONL was 892 MB and compacted records accounted for about 783 MB. This was not only an image-base64 issue; the recovery also required removing stale compacted, tool outputs, token_count, reasoning records, and attachment/media metadata.

    So I think #24191 should either stay open as the broader persisted-session corruption / repair issue, or be explicitly linked to the canonical issue that will cover:

    • bounded compacted records
    • avoiding recursive inclusion of prior compacted payloads
    • not persisting failed/oversized compact output
    • safe resume fallback when compacted state is corrupt
    • a built-in repair/prune command for affected sessions

    #23257 is very close for the image/base64 part, but #24191 covers the broader CLI/session recovery failure mode.

  5. jshaofa-ui commented on May 23, 2026

    @jshaofa-ui
    jshaofa-ui
    on May 23, 2026

    Solution: Codex #24191 — Remote Compact Creates Huge Unrecoverable Records

    Issue Summary

    GitHub: openai/codex #24191
    Title: Remote compact can create huge compacted records and make session unrecoverable
    Labels: bug, CLI, context, session
    Competition: Low (2 comments)
    Quote: $2,000-$3,000

    Root Cause Analysis

    Primary Root Cause: Remote Compaction Lacks Size Bounds

    The remote compaction process generates a compacted session record that can exceed the model's context window. Unlike local compaction (which has built-in size limits), remote compaction has no size guard, allowing it to produce records that are too large for future resume/compact operations.

    Failure Chain

    Long session (100K+ tokens)
  → Remote compact triggered
  → Compaction generates summary
  → Summary is too large (exceeds context window)
  → Compacted record persisted
  → Future resume: record exceeds context → unrecoverable

    Root Cause Details

    1. No Size Budget: Remote compaction does not enforce a maximum output size. The compaction LLM can generate arbitrarily large summaries.

    2. Recursive Compaction Failure: When a user tries to compact an already-compacted session, the compacted record itself is included in the compaction input, making the output even larger.

    3. No Recovery Path: Once the compacted record exceeds the context window, the session cannot be resumed or compacted further — it's permanently stuck.

    Proposed Fix

    Fix 1: Compaction Output Size Limit

    File: codex-rs/core/src/session/compaction.rs

    const MAX_COMPACTED_RECORD_SIZE: usize = 32_000; // tokens

pub fn compact_session(
    session: &Session,
    compaction_model: &Model,
) -> Result<CompactedRecord> {
    let compacted = compaction_model.generate(&session.to_compaction_prompt())?;
    
    // FIX: Enforce size limit
    let token_count = compaction_model.count_tokens(&compacted);
    if token_count > MAX_COMPACTED_RECORD_SIZE {
        // Truncate to fit
        let truncated = compaction_model.truncate_to_budget(
            &compacted,
            MAX_COMPACTED_RECORD_SIZE,
        );
        warn!(
            "Compaction output {} tokens exceeded limit, truncated to {}",
            token_count,
            compaction_model.count_tokens(&truncated)
        );
        return Ok(CompactedRecord::new(truncated));
    }
    
    Ok(CompactedRecord::new(compacted))
}

    Fix 2: Recursive Compaction Guard

    pub fn resume_session(path: &Path) -> Result<Session> {
    let record = load_compacted_record(path)?;
    
    // FIX: Check if compacted record is too large to resume
    if record.token_count > MAX_RESUMABLE_SIZE {
        return Err(SessionError::CompactedRecordTooLarge {
            size: record.token_count,
            max: MAX_RESUMABLE_SIZE,

  6. zgl-gits commented on May 23, 2026

    @zgl-gits
    zgl-gits
    on May 23, 2026

    Solution: Codex #24191 — Remote Compact Creates Huge Unrecoverable Records

    Issue Summary

    GitHub: openai/codex #24191 Title: Remote compact can create huge compacted records and make session unrecoverable Labels: bug, CLI, context, session Competition: Low (2 comments) Quote: $2,000-$3,000

    Root Cause Analysis

    Primary Root Cause: Remote Compaction Lacks Size Bounds

    The remote compaction process generates a compacted session record that can exceed the model's context window. Unlike local compaction (which has built-in size limits), remote compaction has no size guard, allowing it to produce records that are too large for future resume/compact operations.

    Failure Chain

    Long session (100K+ tokens)
  → Remote compact triggered
  → Compaction generates summary
  → Summary is too large (exceeds context window)
  → Compacted record persisted
  → Future resume: record exceeds context → unrecoverable

    Root Cause Details

    1. No Size Budget: Remote compaction does not enforce a maximum output size. The compaction LLM can generate arbitrarily large summaries.
    2. Recursive Compaction Failure: When a user tries to compact an already-compacted session, the compacted record itself is included in the compaction input, making the output even larger.
    3. No Recovery Path: Once the compacted record exceeds the context window, the session cannot be resumed or compacted further — it's permanently stuck.

    Proposed Fix

    Fix 1: Compaction Output Size Limit

    File: codex-rs/core/src/session/compaction.rs

    const MAX_COMPACTED_RECORD_SIZE: usize = 32_000; // tokens

    pub fn compact_session(
    session: &Session,
    compaction_model: &Model,
    ) -> Result {
    let compacted = compaction_model.generate(&session.to_compaction_prompt())?;

    // FIX: Enforce size limit
let token_count = compaction_model.count_tokens(&compacted);
if token_count > MAX_COMPACTED_RECORD_SIZE {
    // Truncate to fit
    let truncated = compaction_model.truncate_to_budget(
        &compacted,
        MAX_COMPACTED_RECORD_SIZE,
    );
    warn!(
        "Compaction output {} tokens exceeded limit, truncated to {}",
        token_count,
        compaction_model.count_tokens(&truncated)
    );
    return Ok(CompactedRecord::new(truncated));
}

Ok(CompactedRecord::new(compacted))

    }

    Fix 2: Recursive Compaction Guard

    pub fn resume_session(path: &Path) -> Result {
    let record = load_compacted_record(path)?;

    // FIX: Check if compacted record is too large to resume
if record.token_count > MAX_RESUMABLE_SIZE {
    return Err(SessionError::CompactedRecordTooLarge {
        size: record.token_count,
        max: MAX_RESUMABLE_SIZE,

    Thanks

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

  8. etraut-openai
    closed this as completedon Jun 29, 2026

  9. mekineer-com commented on Sep 22, 2026

    @mekineer-com
    mekineer-com
    on Sep 22, 2026

    We ran into this too: old compacted records kept piling up long after the thread had moved on. We made Session Survivor to shrink a closed Codex session into a copy you can resume, keeping the useful chat and recent state without dragging all that old tool and reasoning bulk along. https://github.com/mekineer-com/session-survivor

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

    CLIIssues related to the Codex CLIbugSomething isn't workingcontextIssues related to context management (including compaction)sessionIssues involving session (thread) management, resuming, forking, naming, archiving

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions