Control over auto-compaction parameters

Codex CLI 0.40.0 — Auto‑compaction controls

Auto-compaction controls proposal

As a Pro subscriber who depends on long, code-heavy sessions, the hardcoded ~220k auto-compaction threshold is disruptive and should be fully optional (including a hard OFF). It collapses earlier context/code into summaries mid-task and degrades model performance.

Problem

Auto-compaction is an uncontrolled process: once ~220k is reached, the CLI compacts without consent, causing loss of working context and producing worse results than the model could otherwise deliver. This feels chaotic and effectively shortens the usable window.

Minimum (must-have)

Add a hard OFF switch that restores previous behavior: no automatic compaction at any token count (only on explicit user action).

Maximum (nice-to-have)

Modes and basic controls

off — never compact automatically.
on — compact automatically near the limit.
manual — prompt/compact only when invoked; allow a threshold to trigger a prompt.
smart-auto — adaptive compaction that delays until the end of the current step and preserves pinned blocks; threshold configurable.

Interface examples

CLI:

--autocompact=off|on|manual|auto --autocompact-threshold-tokens=240000

TOML:

[autocompact]
mode = "off" # off|on|manual|auto
threshold_tokens = 240000 # optional per-model override

Expected behavior when OFF

Warn near limits, but never compact unless the user explicitly requests it.

Repro (short)

Codex CLI 0.40.0; grow session to ~220k tokens → auto-compaction fires mid-task → context/code loss and quality drop.

This is an essential action. Hardcoding must be removed so that users can use it in the form they desire.

idk. needs to work more with it to be sure. might consider downgrading version if i notice an issue. i dont see them allowing for more token constantly or else it'll be more expensive for them to run.

I've already rolled back to 0.39.

I didn't roll back.
Looking at the related code change, It says the context window is 272k but iirc, in the docs, Pro users has 192k window? So I was thinking 220k made no sense. Here I think auto-compact at 220k (~81%) is reasonable.
I think context-rot happens at that time and more tokens in context makes the model behave worse.

So idk what will happen for a Plus user with 128k context? they don't get this feature? that's not fair.

But I'm with you on this issue, not only for the behavior but also for the freedom and equity.

gpt5-high doesn't auto compact. use that

Is this auto compaction intelligent?

For example, I could tell I was reaching the context window (showed I had 20% left), so I asked the agent to make a detailed MD file for the next agent about everything we've done and everything we need to do moving forward. Once that document was completed, I mentioned the context was low, I don't know if it was just coincidence, it automatically compacted the conversation and handed that document off as the first function.

Now after a test I think it's better to have it ON. my context were full on 0.39 and when it's full I get this error

⚠️ stream error: stream disconnected before completion: stream closed before response.completed; retrying 1/5 in 215ms…

⚠️ stream error: stream disconnected before completion: stream closed before response.completed; retrying 2/5 in 437ms…

• Analyzing nested conditional directives

⚠️ stream error: stream disconnected before completion: stream closed before response.completed; retrying 3/5 in 857ms…

• Simplifying nested conditional macros

⚠️ stream error: stream disconnected before completion: stream closed before response.completed; retrying 4/5 in 1.441s…

• Tracing conditional compilation blocks

⚠️ stream error: stream disconnected before completion: stream closed before response.completed; retrying 5/5 in 3.031s…

• Adjusting debugLiveActivityPreviewPhase assignment

⚠️ stream error: stream disconnected before completion: stream closed before response.completed; retrying 1/5 in 193ms…

• Considering debug code removal

⚠️ stream error: stream disconnected before completion: stream closed before response.completed; retrying 4/5 in 1.505s…

• Considering debugLiveActivityPreviewPhase assignment

⚠️ stream error: stream disconnected before completion: stream closed before response.completed; retrying 5/5 in 3.354s…

It looks like the auto-compact feature is triggering an infinite loop: the agent keeps running web-search, then auto-compacts, and then re-searches the same information it seems to have forgotten after the compact step. This loop continues until it’s manually cancelled, effectively draining the quota if left unattended.

There also appears to be a problem with retaining recent context after a compact. For example, it sometimes re-attempts tasks that were already completed earlier in the same session.

I will submit a PR for this. stayed tuned

If autocompact is not working properly and damaging the context, then compaction should be fixed. Prompt improved or only compact initial part and leave last part of context untouched. I have no idea on who is going to survive with a full context that the model won't accept, however. Only sane option I see is to trigger a request to compact with manually crafted prompt. But OFF doesn't look like a reasonable option. What are you going to do with OFF? Close the session? Possible improvements I see is to warn the user when getting close to autocompact limit, and another is to ask the user if they want to enter a custom compact prompt for autocompact.

When I encounter the issue, I have to enter /compact which is annoying

When I encounter the issue, I have to enter /compact which is annoying

The only 2 choices when running out of context are:

1 - Compact
2 - Restart a new session

The context is limited at least with current LLMs architecture. And likely in the near future models that could have 1/2 M tokens context will have it limited as well. You just will need to compact less in the future.

Options I see useful:

Autocompact threshold configuration
Configure part of the context to compact (if not 100%), maybe even prompt for this could be useful
Compact prompt configuration/change
Prompt the user to enter compact prompt manually when threshold reached
Postpone compaction a little bit (maybe possible if there is more context beyond threshold, but there will be a point where it won't be possible to postpone)

Again:
OFF <----- What is the use case for this? (Pro doesn't means unlimited context)

I never see auth compact triggered, it always fall in to exceed max context window after a long run and can't recover even use the /compact command.

is there a config key to enable auto compact?

Is this a hallucination? I don't think there is an auto compact setting?

https://chatgpt.com/share/68f22c80-a444-8012-b6b1-239824b67d2b

i want this too

Hello,

In our usage, context compaction does not merely “degrade” the session; it often makes it unusable.

After compaction, the agent loses essential parts of the conversation: instructions, business context, decisions already made, technical constraints, MCP, skills, and sometimes even the exact objective of the task. From that point on, it no longer follows the request properly, produces incorrect, unstable, or even broken code, and the generated changes often have to be discarded entirely.

In practice, whenever compaction occurs, we prefer to stop the session, revert the changes, and start over with the task broken down differently. This costs a great deal of time, but it is still preferable to continuing with a conversation that has become unreliable.

Two options seem essential to us:

the ability to completely disable automatic compaction;

compaction events/hooks that allow the necessary context to be explicitly re-injected.

As things stand, the issue is not a simple drop in quality: compaction makes the results unusable.

Have a good day

I also need the option to disable compaction. This is the most urgent feature missing in codex.

Adding support from the perspective of a long-time Claude Code user who has moved to Codex. The critical part for me is not only an OFF switch, but configurable proactive thresholds per model/project, e.g. compact at 70-85% or prompt before compacting, rather than waiting until the window is effectively exhausted.

When compaction fires too late or mid-flow, the session is more likely to drift or lose task state. A config surface like mode + threshold + prompt/manual would make long sessions safer and more predictable.

@szybnev

This is HUGE. I also recently came from Claude Code. (Now using both.) The inability to turn off autocompact is a really big deal. Please help!

(PS - The configurable proactive thresholds per model/project that @szybnev mentions would be really really nice too.)

[And thank you very much for all the work on Codex! 💯 ]

A hard OFF switch makes sense as an escape hatch, but I think it treats the whole window as if every token in it is worth the same, and that's the part that actually hurts. Most of a long session really is fine to compress. The exploration, the dead ends, the intermediate tool output. What you don't want summarized is the small set of things the rest of the work depends on, like the constraints you set early, the decisions you locked in, the files that matter. Those should come back exactly as written or not at all.

Your smart-auto mode already points at this with "preserves pinned blocks," and I'd argue that's the real lever, more than the threshold number. The questions worth nailing down are what gets pinned, whether the user or the agent decides, and whether pinned content is re-injected verbatim after a compaction instead of being folded into the summary like everything else. Threshold tuning mostly delays the problem. Separating what's safe to lose from what isn't is what actually fixes it.

The other thing I'd want is a signal when it happens. Right now compaction is silent, so the first sign something was dropped is the model doing something that no longer lines up with earlier context. Even a one-line note that it compacted, and whether the pinned set survived, would let you catch a bad compaction before it costs you a step.

+1. Compaction at 90% often fails with the oft discussed Error running remote compact task: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact), so if it must be automatic it needs to be automatic sooner, not at a point where the compaction model runs out of context window because it's already "too late". At that point the codex thread becomes effectively unsalvageable which is very annoying when you're deep into something: you have to manually extract whatever is in the worktree, archive it, start a new thread and ask the AI to try to figure out what was going on based on the markdown copy of the previous surface level convo. This happens multiple times a day. You can't "save" the old thread by say erasing a little bit at the end and then running compaction, the only way to recover once you get into the compaction failure death mode is if you happened to fork the conversation before you started the turn. But that has its own issues with worktree and branch juggling.

All this to say it'd probably be preferable for the context to just scroll out so disabling autocompact or providing an alternative compact that just discards the first 3rd of non-surface level context (e.g. not the user messages but all the items 'collapsed' in the UI) would be superior than this repeated pain-point. If that's not desirable for economics, e.g. you really want short context windows to save money, that's perfectly fair but then let us go the other way: auto-compact sooner, like at 85% since long compacting breaks the compactor so often.

Update: switching between fast and normal mode may also be a culprit.

patches: add session-delete and disable-autocompact

It seems like auto-compaction always happens at the worst time.

What you don't want summarized is the small set of things the rest of the work depends on, like the constraints you set early, the decisions you locked in, the files that matter.

I've had fairly good luck by instructing it to take notes in Markdown files. It's not perfect, and can get out of hand, but at least I can manually review/prune/add to those.

+1. This is a severe limitation for my use case. Automatic compaction typically occurs around 70–75% context usage, so the de facto usable window is only about three quarters of the advertised useful window.

After compaction, the problem is not merely a small quality reduction. I have repeatedly seen important constraints, earlier decisions, and qualifications disappear. The agent then drifts toward positions already rejected, revisits completed work, or produces changes that can no longer be trusted. Recovering often requires rereading substantial material, reverting work, or abandoning the session and starting again.

Claude Code is much more flexible here. I can disable automatic compaction, monitor usage myself, use the full context window, and then either end the session or compact manually at a deliberate boundary. In particular, I can reach 100% and compact there to begin again with a fresh context window. Codex instead takes that decision away from me while a substantial portion of the window still appears available.

I have tried moving model_auto_compact_token_limit to the full model ceiling and using a PreCompact hook. Neither is an adequate substitute for a supported user-facing control: the effective limit can still differ from the configured one, and blocking the event with a hook interrupts the triggering turn rather than providing a clean workflow.

Please add a supported off/manual/auto compaction mode, separate from the threshold, with an explicit warning before automatic compaction. Users who prefer automatic protection can keep it; users who actively manage long sessions should be allowed to use the whole available window and decide when compaction occurs.

I have implemented and tested a prototype of the hard-off workflow requested here. I am sharing its behavior and validation as design input, not proposing the fork as an external pull request.

My workflow ends a long thread by requesting a handoff and then starting a fresh thread. Automatic compaction can occur before that handoff, while blocking automatic compaction with PreCompact prevents subsequent prompts from reaching the model.

Reproduction

I reproduced the blocking-hook problem with Codex CLI 0.154.0 on Ubuntu 24.04 x86-64:

Configure a 200,000-token context window and use total-scope accounting.
Test automatic limits of 180,000 and 9223372036854775807.
Have a loopback Responses fixture report 185,000 input tokens after a tool call.
Return continue: false from a required PreCompact hook.
Submit two subsequent handoff requests.

The model-request counts are 1, 0, 0: both follow-up requests are interrupted before sampling. Codex reports an automatic limit of 180,000, a usable limit of 190,000, and full_context_window_limit_reached=false.

With 175,000 reported input tokens, the same test produces request counts of 2, 1, 1, and both follow-up messages reach the model.

The standalone reproduction and its source observations are recorded in olegus8/codex#2.

Behavior implemented in the prototype

The local configuration names are illustrative; upstream naming can differ.

model_auto_compact_enabled = false disables automatic compaction and automatic context-reset paths. The existing default remains enabled.
Explicit manual compaction remains available.
Guardian and safety-review sessions retain their existing compaction behavior.
With automatic compaction disabled, the thread continues until Codex's usable context limit.
Reaching that limit, including provider-reported context overflow, produces a distinct exhaustion outcome without automatic compaction, history rewriting, or retrying.
Submitted input, completed tool results, and rollout history remain preserved at exhaustion.
model_context_pause_percent optionally pauses autonomous processing once per thread when automatic compaction is disabled. It is unset by default.
At the first safe boundary after the configured percentage—70% in my installation—the pause marker is persisted before delivery. Running tools finish, their results and accepted input remain in history, and no additional model request is made.
A later explicit user message resumes the thread, whether it requests a handoff or ordinary work.
Restarting the process does not re-arm the pause for the same thread. A fresh thread has independent pause state.
Displayed usage, pause decisions, and exhaustion use the same active-context accounting and usable-window denominator.
Pause and exhaustion are represented through typed core, app-server, exec, and TUI outcomes.

The implementation is split across these reference PRs:

Validation

Twenty-two compiled Linux scenarios passed across the TUI, app-server, direct tools, code mode, and MCP. They cover:

Below-threshold operation and a single 70% pause
Multiple completed tool results at the pause boundary
Ordinary continuation and handoff after the pause
Persistence across restart and independence between threads
Context exhaustion and provider-reported overflow
Large tool results and queued input
Manual compaction and the unchanged default automatic behavior
Managed hooks and the existing structured-question guard

The deployed configuration also passed fresh-session authentication, TUI, direct-mode, code-mode, MCP, managed-hook, rollback, and Ansible no-drift checks.

The usage fixtures are synthetic. Token-estimation accuracy, performance, macOS, Windows, mixed-OS connections, and the complete workspace suite were not tested.

Would the Codex team consider implementing the hard-off and clean-exhaustion behavior internally? Should the optional early pause be discussed in a separate issue? I would also appreciate feedback on architectural constraints that this prototype may not account for.

With automatic compaction disabled, the thread continues until Codex's usable context limit.

+1000.

The user can then compact once the context limit is reached (a sub-agent can read the session and start the fork with the compacted context). IIRC that's how it works in claude code.

Personally, I watch the context window usage % via the statusline, and plan my work so I never reach the 100% limit. Although I rarely cross the 50% mark, there are a few legitimate cases where I need to go over 90%. In codex, such sessions are ruined by the auto compaction.

Compaction degrades context, please enable this feature for us that don't want their content less accurate!

Navigation Menu

Repository navigation

Control over auto-compaction parameters #4106

Codex CLI 0.40.0 — Auto‑compaction controls

Auto-compaction controls proposal

Problem

Minimum (must-have)

Maximum (nice-to-have)

Modes and basic controls

Interface examples

Expected behavior when OFF

Repro (short)

5 remaining items

Reproduction

Behavior implemented in the prototype

Validation

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Control over auto-compaction parameters #4106

Description

Codex CLI 0.40.0 — Auto‑compaction controls

Auto-compaction controls proposal

Problem

Minimum (must-have)

Maximum (nice-to-have)

Modes and basic controls

Interface examples

Expected behavior when OFF

Repro (short)

Activity

ginishuh commented on Sep 23, 2025

Aze1338 commented on Sep 23, 2025

ginishuh commented on Sep 24, 2025

PabloLION commented on Sep 24, 2025

AhnDroiid commented on Sep 24, 2025

tekn0x commented on Sep 25, 2025

PabloLION commented on Sep 25, 2025

balboah commented on Sep 30, 2025

JakkuSakura commented on Oct 1, 2025

waldoalvarez00 commented on Oct 1, 2025

JakkuSakura commented on Oct 1, 2025

waldoalvarez00 commented on Oct 4, 2025

sailxjx commented on Oct 13, 2025

atomical commented on Oct 17, 2025

5 remaining items

ronny-rentner commented on Mar 14, 2026

AhNosNimes commented on Mar 19, 2026

andgate commented on Apr 8, 2026

szybnev commented on May 4, 2026

MFRWDesign commented on May 15, 2026

Patdolitse commented on Jun 3, 2026

aljungberg commented on Jun 7, 2026

zeel01 commented on Sep 3, 2026

adereis commented on Sep 8, 2026

olegus8 commented on Sep 15, 2026

Reproduction

Behavior implemented in the prototype

Validation

adereis commented on Sep 15, 2026

rodrigo-barraza commented on Oct 5, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions