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

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:

• #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