Skip to content

Codex Desktop auto-compacts short resumed sessions even when context usage is far below window #29426

Open
Open
Codex Desktop auto-compacts short resumed sessions even when context usage is far below window#29426
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, archiving

Description

@MeteorsFist
MeteorsFist
opened on Jun 22, 2026

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

Codex Desktop app version: 26.616.51431

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Microsoft Windows NT 10.0.19045.0 x64

What issue are you seeing?

Codex Desktop automatically compacts context immediately after resuming a short completed session, before processing the next user message, even when the previous active context is far below the model context window.

In one rollout, the previous completed turn ended with:

  • last_token_usage.total_tokens = 50252
  • input_tokens = 49978
  • model_context_window = 258400

After restarting/signing into another account and resuming the session, the next turn showed:

  • task_started with model_context_window = 353400
  • then type:"compacted"
  • then event_msg.payload.type:"context_compacted"
  • then turn_context.summary:"auto"

The first real model request after compaction was only about 18K tokens, so the compaction happened before the new user message was processed. This makes it look like a short 18K/20K context triggered compaction, but the logs show that auto-compaction happened first during resume.

Expected behavior: Codex should not auto-compact a short resumed session when context usage is only ~50K out of a 258K/353K window, or it should expose why resume-time compaction is required.

What steps can reproduce the bug?

  1. Start a Codex Desktop thread on Windows.
  2. Complete a short task.
  3. Restart Codex Desktop and/or switch account.
  4. Resume the same session.
  5. Send a new prompt.
  6. Check the rollout JSONL for the resumed turn.

Session id:

019eed77-aaa0-7521-8bab-b56ef05a6b15

Rollout file:

rollout-2026-06-22T11-55-08-019eed77-aaa0-7521-8bab-b56ef05a6b15.jsonl

Relevant log sequence:

{"timestamp":"2026-06-22T04:02:35.420Z","type":"event_msg","payload":{"type":"token_count","info":{"last_token_usage":{"input_tokens":49978,"cached_input_tokens":49536,"output_tokens":274,"reasoning_output_tokens":38,"total_tokens":50252},"model_context_window":258400}}}
{"timestamp":"2026-06-22T04:02:35.440Z","type":"event_msg","payload":{"type":"task_complete"}}
{"timestamp":"2026-06-22T07:54:16.879Z","type":"event_msg","payload":{"type":"task_started","model_context_window":353400}}
{"timestamp":"2026-06-22T07:54:30.556Z","type":"compacted","payload":{"replacement_history":[/* only a few short user messages plus prior compaction */]}}
{"timestamp":"2026-06-22T07:54:30.563Z","type":"event_msg","payload":{"type":"context_compacted"}}
{"timestamp":"2026-06-22T07:54:30.570Z","type":"turn_context","payload":{"summary":"auto","model":"gpt-5.5"}}
{"timestamp":"2026-06-22T07:54:38.379Z","type":"event_msg","payload":{"type":"token_count","info":{"last_token_usage":{"input_tokens":17963,"output_tokens":315,"total_tokens":18278},"model_context_window":353400}}}

The previous active context was only 50252 / 258400 tokens, roughly 19.4% of the context window. After resume, the window was 353400, so the session was even further from the limit.

Actual result:

Codex Desktop emits context_compacted before processing the new prompt.

Expected result:

A short resumed session should continue without automatic compaction, or Codex should expose why resume-time compaction is required despite low context usage.

Additional related session:

019eee0e-ea1f-75b1-8381-6759bea6d4f5

That session also compacted immediately after resume/account switch before processing the new prompt.

What is the expected behavior?

Codex Desktop should resume the session without automatically compacting context when the previous active context is far below the model context window.

For the example session, the previous turn used only 50252 / 258400 tokens, and the resumed turn had a 353400 context window. I would expect Codex to preserve the recent conversation history and process the next user message directly.

If Codex must compact during resume for reasons other than context pressure, it should expose the reason in the rollout logs, for example whether compaction was triggered by account switch, changed prompt hash, changed tool/developer context, or another resume-time policy.

Additional information

This may be related to resume/account switching rather than normal context pressure.

In both observed sessions, context_compacted occurred before the next user message was processed. The post-compaction token count was small, which can make it look like a ~18K/20K context triggered compaction, but the logs show the compaction happened first.

A second session showed similar behavior after restart/account switch:

Session id: 019eee0e-ea1f-75b1-8381-6759bea6d4f5

Before resume:

  • last_token_usage.total_tokens = 168670
  • model_context_window = 353400

After resume:

  • task_started model_context_window = 258400
  • type:"compacted"
  • event_msg.payload.type:"context_compacted"
  • turn_context.summary:"auto"

In the shorter session, comp_hash changed from 2911 before resume to 3000 after resume, while summary remained "auto". This may indicate that resume-time context composition changed and triggered compaction even though token usage was low.

Related but not identical issues I found:

Activity

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

  3. 1Humza commented on Jun 23, 2026

    @1Humza
    1Humza
    on Jun 23, 2026

    Same issue on macOS after updating to v26.622.11653. Seems like context from every chat is wiped/missing and compaction is triggered as a sideeffect. Agent has no idea what it's talking about after this happens.

    Is this the same behavior you are experiencing?

    edit: downgraded to 26.616.31447 still happens. probably issue on the cloud

  4. i4w7w4a commented on Jul 2, 2026

    @i4w7w4a
    i4w7w4a
    on Jul 2, 2026

    I found a reproducible workaround for the reduced context-window issue on my machine.

    This may be related to the auto-compaction behavior reported here, but in my case the root cause was more basic: Codex was reading a model catalog where gpt-5.5 had a reduced context window.

    Symptom

    On the same account/client, gpt-5.5 sometimes showed only about 258k effective context in the Desktop hover:

    Used 25k / 258k tokens

    Expected / working value:

    Used 31k / 353k tokens

    The raw/effective values behind this were:

    bad state:  272000 raw -> 258400 effective
good state: 372000 raw -> 353400 effective

    This happened in both new and old threads. It also reproduced in the VS Code Codex extension, so it did not look like only one old Desktop conversation was corrupted.

    Important detail: gpt-5.4 still shows around 258k, which appears normal for that model. The issue here is specifically when gpt-5.5 is selected but still receives the 272000 / 258k catalog values.

    Things that did not fix it

    • Creating a new thread.
    • Fully restarting Codex Desktop.
    • Signing out / signing in again.
    • Switching between Desktop and VS Code extension.
    • Deleting the normal generated models_cache.json; Codex recreated it with the same reduced 272000 value.
    • Testing with a clean CODEX_HOME containing only auth data; the reduced catalog value still came back.

    That made it look like the client was receiving, caching, or selecting a different model-catalog entry for gpt-5.5, rather than the thread history itself being the primary cause.

    Workaround that fixed it

    I pinned Codex to a local model catalog file via model_catalog_json.

    In config.toml:

    model = "gpt-5.5"
model_catalog_json = 'C:\Users\<USER>\.codex\models_cache.local.json'

    Use a real absolute Windows path there. I did not rely on %USERPROFILE% expansion.

    Then in models_cache.local.json, the gpt-5.5 entry must contain the larger context-window values:

    {
  "slug": "gpt-5.5",
  "context_window": 372000,
  "max_context_window": 372000,
  "comp_hash": "3000",
  "effective_context_window_percent": 95,
  "use_responses_lite": false
}

    The critical part is not only context_window.

    use_responses_lite also mattered. A local catalog I tested originally had:

    "use_responses_lite": true

    With that value, gpt-5.5 failed in Codex Desktop with:

    This model is not supported when using X-OpenAI-Internal-Codex-Responses-Lite.

    Changing it to:

    "use_responses_lite": false

    fixed that error.

    Verification

    After restarting Codex and selecting gpt-5.5, codex debug models showed:

    gpt-5.5
context_window: 372000
max_context_window: 372000
effective_context_window_percent: 95
comp_hash: 3000
use_responses_lite: false

    The Desktop hover then showed:

    Used 31k / 353k tokens

    I also tested an older existing thread. After switching that thread from 5.4 to 5.5 and sending a new message, the same old thread started showing the larger 353k effective window. So old threads were not permanently broken in my case.

    Practical steps for anyone hitting this

    1. Confirm you are actually on gpt-5.5, not gpt-5.4.
    2. Run codex debug models and check the gpt-5.5 entry.
    3. If gpt-5.5 shows context_window: 272000, the client/catalog is in the reduced state.
    4. Create a local catalog file, for example:
    C:\Users\<USER>\.codex\models_cache.local.json
    1. Add model_catalog_json to config.toml with the absolute path to that file.
    2. Make sure the local gpt-5.5 entry has:
    "context_window": 372000,
"max_context_window": 372000,
"effective_context_window_percent": 95,
"comp_hash": "3000",
"use_responses_lite": false
    1. Restart Codex Desktop / VS Code extension.
    2. Select gpt-5.5.
    3. Check the hover or codex debug models.

    Expected result:

    372000 raw / 353400 effective

    Caveats

    This is a workaround, not a clean product fix.

    Pinning model_catalog_json means Codex will use the local model catalog instead of the live server-provided one. That can hide future official catalog updates until the local file is removed or updated.

    Once the upstream catalog consistently returns the correct gpt-5.5 values, the safer long-term fix is to remove the model_catalog_json override and go back to the live catalog.

    Also, do not paste a full config.toml publicly without checking it first. Mine contained unrelated MCP/server settings and private keys. Only the model and model_catalog_json lines were relevant here.

    Questions for maintainers

    • Why would gpt-5.5 receive 272000 context-window metadata on one install/account/session while another setup receives 372000?
    • Is this controlled by a rollout bucket, service tier, account capability, stale model catalog, or client channel?
    • Should gpt-5.5 ever be served with use_responses_lite: true if Desktop then rejects it with X-OpenAI-Internal-Codex-Responses-Lite?
    • Could Codex expose the active model-catalog source and raw/effective context values more clearly in the UI or debug models, plus a supported catalog refresh/reset command?

  5. i4w7w4a commented on Jul 2, 2026

    @i4w7w4a
    i4w7w4a
    on Jul 2, 2026

    Same issue on macOS after updating to v26.622.11653. Seems like context from every chat is wiped/missing and compaction is triggered as a sideeffect. Agent has no idea what it's talking about after this happens.

    Is this the same behavior you are experiencing?

    edit: downgraded to 26.616.31447 still happens. probably issue on the cloud

    I solved the problem with the post above. Suggested by my crazy programmer friend.

    Image
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, archiving

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions