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

Open 💬 4 comments Opened Jun 22, 2026 by MeteorsFist

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?

Start a Codex Desktop thread on Windows.
Complete a short task.
Restart Codex Desktop and/or switch account.
Resume the same session.
Send a new prompt.
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:

#25394: resume compression drops recent context
#26783: small sessions repeatedly compact due to incorrect 2432-token window
#21931: Desktop hangs on "Automatically compacting context" even for no-op prompt

View original on GitHub ↗

4 Comments

1Humza · 2 months ago

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

i4w7w4a · 1 month ago

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

Confirm you are actually on gpt-5.5, not gpt-5.4.
Run codex debug models and check the gpt-5.5 entry.
If gpt-5.5 shows context_window: 272000, the client/catalog is in the reduced state.
Create a local catalog file, for example:

C:\Users\<USER>\.codex\models_cache.local.json

Add model_catalog_json to config.toml with the absolute path to that file.
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

Restart Codex Desktop / VS Code extension.
Select gpt-5.5.
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?

i4w7w4a · 1 month ago

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.

shleder · 11 days ago

The resume-time compaction sequence here is a useful persisted compaction-state field case. I’m testing codex-rescue==0.1.0a4 against rollouts where compaction happens unexpectedly around resume.

If you still have the affected rollout, could you run a read-only check:

pipx install codex-rescue==0.1.0a4
codex-rescue doctor --json "/path/to/the-affected-rollout.jsonl"

It won’t change Codex’s compaction policy, but it can independently report the durable compaction/turn structure and whether there are persisted anomalies around the resume boundary.

Please share only sanitized status/findings/aggregate counts—no raw rollout, DBs, prompts, tool output, account metadata, credentials, session IDs, repository data, or private paths.