Compact command not auto-running in Codex v0.42.0

Please add an option to turn off auto-compact if the auto-compact aspect of this issue is addressed. I believe quite a few users do not wish to have auto-compact enabled (and are happy this version does not have it).

I've never hit auto-compact (am not on 0.42 yet), so I didn't even know it was a thing. I didn't see it surfaced anywhere, but this should be fully configurable as the previous poster suggested. Apologies if some form of this already exists, but in my ignorant state I'd ask for this at a minimum:
/autocompact <1-100> -> auto-compact after exceeding "n% context left"
/autocompact [off/on] -> turn off or on
/compact <compact guidance> -> manual compacting

Please add an option to turn off auto-compact if the auto-compact aspect of this issue is addressed. I believe quite a few users do not wish to have auto-compact enabled (and are happy this version does not have it).

Why would you want auto-compact off? That makes no sense. Maybe change the auto-compact prompt would be useful, maybe change the threshold, maybe prompt user manually. Maybe compact a part of the context. But OFF?! What are you going to do with a full context? Close the program? Cause you certainly won't be asking more questions. I see no use case for OFF!

> Please add an option to turn off auto-compact if the auto-compact aspect of this issue is addressed. I believe quite a few users do not wish to have auto-compact enabled (and are happy this version does not have it). Why would you want auto-compact off? That makes no sense. Maybe change the auto-compact prompt would be useful, maybe change the threshold, maybe prompt user manually. Maybe compact a part of the context. But OFF?! What are you going to do with a full context? Close the program? Cause you certainly won't be asking more questions. I see no use case for OFF!

Auto-compact locks you into a single compaction prompt/method dictated by codex's system prompt. Some users might have their own custom compaction procedures and don't wish to use the default /compact compaction method. Even for users that do always use /compact, they might prefer to simply always call the /compact method manually as it's a very destructive/invasive process and don't want it done silently in the background.

There are also users who use different compaction methods tailored towards the specific conversation they're working on. For instance, the typical compaction method summarizes the entire conversation. However, if only the recent part of the history is relevant for future work, you might want to simply take the last N messages (without using a summarization prompt at all). There are also use cases for the opposite- taking only the first N messages (this is essentially the same as forking a conversation).

Also, some users never use compact. They prioritize clean and immutable conversation histories that they can refer back to. For these users, it is important at least that auto-compact creates a new conversation and doesn't mangle the current one. Perhaps this is already currently done, but it needs to be documented clearly in that case.

You already touched on a lot of this, i.e. changing the prompt, changing the threshold, prompting the user manually, or compacting a part of the context which are all useful. But for instance compacting a part of the context would be incompatible with a forced single auto-compact method on all users.

We increased the threshold significantly in CLI v0.42.0, so this is expected, but we are working on improvements to compaction and auto-compaction that we hope will strike a better balance (and we'll also make it so that you can completely disable it).

> > Please add an option to turn off auto-compact if the auto-compact aspect of this issue is addressed. I believe quite a few users do not wish to have auto-compact enabled (and are happy this version does not have it). > > > Why would you want auto-compact off? That makes no sense. Maybe change the auto-compact prompt would be useful, maybe change the threshold, maybe prompt user manually. Maybe compact a part of the context. But OFF?! What are you going to do with a full context? Close the program? Cause you certainly won't be asking more questions. I see no use case for OFF! Auto-compact locks you into a single compaction prompt/method dictated by codex's system prompt. Some users might have their own custom compaction procedures and don't wish to use the default /compact compaction method. Even for users that do always use /compact, they might prefer to simply always call the /compact method manually as it's a very destructive/invasive process and don't want it done silently in the background. There are also users who use different compaction methods tailored towards the specific conversation they're working on. For instance, the typical compaction method summarizes the entire conversation. However, if only the recent part of the history is relevant for future work, you might want to simply take the last N messages (without using a summarization prompt at all). There are also use cases for the opposite- taking only the first N messages (this is essentially the same as forking a conversation). Also, some users never use compact. They prioritize clean and immutable conversation histories that they can refer back to. For these users, it is important at least that auto-compact creates a new conversation and doesn't mangle the current one. Perhaps this is already currently done, but it needs to be documented clearly in that case. You already touched on a lot of this, i.e. changing the prompt, changing the threshold, prompting the user manually, or compacting a part of the context which are all useful. But for instance compacting a part of the context would be incompatible with a forced single auto-compact method on all users.

Part of this makes no sense and seems to be written without even attempting to define what would be off or manual. You cannot continue with a full context. If you repeatedly ignore warnings of context near the edge and never compact you are going to hit a fundamental wall. So no, nobody is working without compact. They are hitting a wall and starting a new session. Manual != Off (and it is important the definition of OFF vs Manual since they should not be the same thing and become duplicated functionality).

None of us like to compact, as quality of responses get reduced. But context size is an inherent limitation. You cannot avoid it as you won't avoid death. Either you run it manually or run it automatically at the edge where you have little room. The only other choice it to start from scratch. So. No, nobody is working without compact, they are starting from scratch.

There is a PR already that addresses this (we are testing https://github.com/openai/codex/pull/4553 ) where manual is well defined. Manual is not completely disabled, it gives you 2 choices, run compact manually or cancel it. Then you can just start a new session (and that would cover your definition of OFF). At least for the definition I can infer from your words. But not giving the choice to even manually compact to the user (completely OFF) is pointless. You can even checkout, build and test the PR yourself. It is working, includes test suite, documentation and configuration for triggering manual compact/autocompact. It could need more testing but is looking very good and has no duplicate functionality with well-defined behavior.

Yeah currently I really regret updating codex, before it was not auto compacting and I was very glad about it. I carefully engineer the context each time and if it runs out of context, I want to know and manually craft a new context. This forced auto compacting is terrible, I cannot let codex run in the background anymore for fear that it compacts and then continues outside of the exact directions of my context.

No I'm also not starting from scratch, I engineer the context and then insert the latest diffs and conversation with the llm so it knows where it ended. I just want the buggy version back where it says it ran out of context and then... does nothing

Yeah currently I really regret updating codex, before it was not auto compacting and I was very glad about it. I carefully engineer the context each time and if it runs out of context, I want to know and manually craft a new context. This forced auto compacting is terrible, I cannot let codex run in the background anymore for fear that it compacts and then continues outside of the exact directions of my context. No I'm also not starting from scratch, I engineer the context and then insert the latest diffs and conversation with the llm so it knows where it ended. I just want the buggy version back where it says it ran out of context and then... does nothing

I prefer decisions grounded in reasons and facts, not hot takes. After years shipping software across a dozen languages, one principle keeps paying off: consistency. Flaky options confuse users and increase support load. Today I solved a problem from a customer that deployed a wrong setting, got confused, and required three days of support. I’ve now added server-side constraints to block bad input. Features are fine, but not at the cost of reliability.

About the behavior you want: pressing a single Esc already does exactly that in the mentioned PR (https://github.com/openai/codex/pull/4553). It’s implemented today.

If you want to verify, pull the PR, install Rust, build with cargo, and run it. Simple as that.

I repeat IT ONLY TAKES A SINGLE ESC KEY PRESS (did you even tried to read and understand?)

For context: I ship production systems and use multiple LLMs in parallel (I do pay enterprise and max accounts that I constantly deplete, more than one), plus tooling and services around them. The point isn’t résumé padding. It’s that I optimize for maintainable features that reduce user error.

If the current release isn’t for you, you can downgrade to an older version. (any professional knows this option is available). And github has ALL versions. All STOA LLMs are quite good at handling git, even small ones. They even sometimes checkout old sources test and restore while tracking a bug. I do not use rewind (useless).

I prefer decisions grounded in reasons and facts, not hot takes

To be honest I feel like your ignorance about why you should NOT give users the option to disable autocompact is a hot take, you seem to try to defend over and over again. It just doesn't make sense to not give the users this option.
Autocompact OFF -> Don't autocompact until the user does /compact
That would make it consistent with Claude Code as that does let you disable auto summarization.

About the behavior you want: pressing a single Esc already does exactly that in the mentioned PR

A single ESC is NOT the same, I don't want to have codex do something while I go on a Coffee Break only to see when I come back that it did great work, then autocompacted and went totally of the rails.
I want it to stop at this point and not worry about any auto compacting happening while I'm away.

If the current release isn’t for you, you can downgrade to an older version. (any professional knows > this option is available). And github has ALL versions. All STOA LLMs are quite good at handling git, even small ones.

Also I mean really? trying to explain the concept downgrading and telling people that you can do it using git for which of course you would have to use LLMs to do it for you? is that how far the discussion has sunken?
I mean obviously there are good reasons for not downgrading permanently for one feature which SHOULD be an option anyways

> I prefer decisions grounded in reasons and facts, not hot takes To be honest I feel like your ignorance about why you should NOT give users the option to disable autocompact is a hot take, you seem to try to defend over and over again. It just doesn't make sense to not give the users this option. Autocompact OFF -> Don't autocompact until the user does /compact That would make it consistent with Claude Code as that does let you disable auto summarization. > About the behavior you want: pressing a single Esc already does exactly that in the mentioned PR A single ESC is NOT the same, I don't want to have codex do something while I go on a Coffee Break only to see when I come back that it did great work, then autocompacted and went totally of the rails. I want it to stop at this point and not worry about any auto compacting happening while I'm away. > If the current release isn’t for you, you can downgrade to an older version. (any professional knows > this option is available). And github has ALL versions. All STOA LLMs are quite good at handling > git, even small ones. Also I mean really? trying to explain the concept downgrading and telling people that you can do it using git for which of course you would have to use LLMs to do it for you? is that how far the discussion has sunken? I mean obviously there are good reasons for not downgrading permanently for one feature which SHOULD be an option anyways

MANUAL OPTION DOES NOT AUTOCOMPACT!!. Read the sources instead of talking without knowing what you are talking about. No, a "feature" that jams a system is a completely STUPID option.

We appreciate you sharing your opinions, but please be respectful of others when posting.

We do have all of this working already. With features no other CLI has. Fine grained manual compact that can postpone several times (currently testing). Even part of what they are requesting is a state that is reachable configuring at the edge. No escape key? Fine press ctrl + c and there you have the OFF. Except that user still get the option to compact if needed. Some of us prefer to have last compact option on the edge if postponed as is better than new session. If they want, they can ctrl+c at that extreme edge. Simple. No zombie state.

If someone is going to discuss something, at least should make the minimal effort to read what is being discussed about. None of them tried as can be inferred from their comments. I provided a link that even includes documentation (https://github.com/openai/codex/blob/6860ddb2cc02a69fb8d75c31412dc3dc82b22937/docs/config.md). Even if they cannot code could have informed themselves that way instead of all those bad vibes. Sounded to me like "bring 4o back" tantrum. If they really wanted no autocompact they would have downloaded already the PR. Is as simple as asking some LLM to tell it to download the PR with the link, ask it to install rust and ask it to build. Did I type all those git commands? No. I did it even with free Grok code fast 1 using opencode. No api, no login, no nothing. They are all good dealing with git (the most complex part). Cause building is a single command.

Here is Manual compact that can be cancelled several times:

<img width="2064" height="1028" alt="Image" src="https://github.com/user-attachments/assets/74274870-4a31-4457-8284-e6efa1b378f2" />

And the selectable limit (if taken to the edge would become the OFF they talk about, except that without becoming a zombie):

<img width="2069" height="1030" alt="Image" src="https://github.com/user-attachments/assets/2685ec14-56b9-4790-8bd5-d3d324a80f93" />

Do they want the feature? I don't think they really do. I think is more about arrogance. Not recognizing they are wrong. He want to temporarily solve by downgrading.? Not really given the response. Obviously was just an excuse. I do have downgraded versions. In fact, I just downgraded my Python today to be able to run CUDA library. Perfectly valid option to be able to run Gymnasium reinforcement learning.

Yes, autocompact can be improved. Is not good in Codex. I proposed some possible fixes already in another thread related to compact. I proposed to compact partial context (example compact only initial part and leaving untouched the part closest to the end). Be able to change the size of that partial compact. No idea if that would work. But could be worth testing it. Is compact going to be improved in Codex? Could be. But in the meantime we need to work with what is here and not what could be. We need things working now. Robust. I already finished 2 massive projects (you can see one completed in the shots showing full regressions passing). And a smaller one.

I am thinking to leave the projects I am working for a moment (2) to get this PR in 100% full shape. In the same way I stopped to build MCP proxy for context engineering. I am not a Rust developer but won't be the first language I learn in days. I had to learn Eiffel in one week for university test once. And with the help of AI... should be easier.

PD: How would you call freezing your phone of freezing your laptop to try to fix something? What are the words to describe it? Disabling autocompact is NOT what they are asking (since we have this working 100%). They are asking to FREEZE codex when there is no more context. And freeze ours too. Really?

If someone is going to discuss something, at least should make the minimal effort to read what is being discussed about. None of them tried as can be inferred from their comments. I provided a link that even includes documentation (https://github.com/openai/codex/blob/6860ddb2cc02a69fb8d75c31412dc3dc82b22937/docs/config.md).

Thank you for sending this
I didn't expect the documentation to have been updated as well in the PR and as I'm not a Rust Developer I didn't attempt to read the sources.

About the behavior you want: pressing a single Esc already does exactly that in the mentioned PR

Manual is not completely disabled, it gives you 2 choices, run compact manually or cancel it.

This made it sound like the behavior is like the current one where you can abort a starting autocompact using Esc, which clearly is not a solution for the users that want the manual solution.

I was also a bit frustrated by you dismissing so easily that some users really don't want to autocompact AT ALL even if it worked fine.

But now I get your frustration too, you sent us a PR with the manual function working exactly like we wanted it to, but as we continued demanding that feature, you were lead to believe that we want even the option for autocomplete gone completely for everyone. That's kind of funny.

> If someone is going to discuss something, at least should make the minimal effort to read what is being discussed about. None of them tried as can be inferred from their comments. I provided a link that even includes documentation (https://github.com/openai/codex/blob/6860ddb2cc02a69fb8d75c31412dc3dc82b22937/docs/config.md). Thank you for sending this I didn't expect the documentation to have been updated as well in the PR and as I'm not a Rust Developer I didn't attempt to read the sources. > About the behavior you want: pressing a single Esc already does exactly that in the mentioned PR > Manual is not completely disabled, it gives you 2 choices, run compact manually or cancel it. This made it sound like the behavior is like the current one where you can abort a starting autocompact using Esc, which clearly is not a solution for the users that want the manual solution. I was also a bit frustrated by you dismissing so easily that some users really don't want to autocompact AT ALL even if it worked fine. But now I get your frustration too, you sent us a PR with the manual function working exactly like we wanted it to, but as we continued demanding that feature, you were lead to believe that we want even the option for autocomplete gone completely for everyone. That's kind of funny.

Ok, sorry about being rude. But sometimes you have to "shake" people so they exit a denial position. It was also very late at night after working the whole day. I even considered was someone sent by a jealous competitor trying to sabotage/troll or something since the mod is so good.

Yes, it can be configured exactly as some are requesting here. Except that you just get a final prompt to manually compact (I am still testing on my side). You can opt not to do it and start a new session if you set the limit to the very extreme. Identical to the OFF except it doesn't becomes zombie (that is the only difference).

Compact is never triggered automatically in manual mode. It can autocompact too if configured for autcompact. Therefore, the PR covers ALL use cases. It could need some more testing and polishing (some tests still failing that need to be adjusted). But it is mostly there.

Yes, the PR includes documentation. You are welcome. Non developers can easily read it. I am no rust developer either. I understand it to some extent because I work with other languages, but Rust is newer. Hint, you can ask copilot here at github to explain you some of the changes if you don't understand something. Regards.