Manual /compact command in Codex app

[Khang5687]

What variant of Codex are you using?

260208.1016

What feature would you like to see?

We need manual /compact command. On Codex CLI we can do that, on the app, well...

Additional information

No response

[github-actions]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• [App Server / API]: No RPC to trigger compaction when auto-compact fails (context window exceeded) #9142

Powered by Codex Action

[etraut-openai]

Can you say more about why you want a manual compact command? We've implemented a robust auto compaction mechanism, so there should no longer be a need for developers to manage context windows manually. We've left manual compaction in the CLI for now, but our goal is to eventually remove it.

[Khang5687]

Can you say more about why you want a manual compact command? We've implemented a robust auto compaction mechanism, so there should no longer be a need for developers to manage context windows manually. We've left manual compaction in the CLI for now, but our goal is to eventually remove it.

Normally, I do not create a new chat sessions, so my Codex chat history is just compactions after compactions.
Codex's compaction mechanism is very good! Plus, Codex does not need to re-read all the files.

The problem I usually run into without manual /compact: I may approve Codex's plan when it is at 70% of its context window, making Codex auto compact while it is in the middle of its work.

With manual /compact however, I will do /compact -> Context window is now only 10% full -> Codex has more context window to work on my task without auto compacting mid-work.

[miraclebakelaser]

Can you say more about why you want a manual compact command? We've implemented a robust auto compaction mechanism, so there should no longer be a need for developers to manage context windows manually. We've left manual compaction in the CLI for now, but our goal is to eventually remove it.

Here's my workflow for long-running tasks which works well:

1. Generate an ExecPlan
2. Compact the conversation
3. In the new conversation, mention the plan and prompt codex to "Execute the plan. Update Progress, Surprises, Decision Log, and Outcomes as you work"
4. After each milestone, I compact the conversation, provide the codex with the updated plan, and then ask it to continue on to the next milestone
5. Repeat until completion

[Khang5687]

Thanks @miraclebakelaser, this is a useful knowledge to me.

4. After each milestone, I compact the conversation, provide the codex with the updated plan, and then ask it to continue on to the next milestone

So you do manual compaction right?

[miraclebakelaser]

@Khang5687 yes

[MrRobot701]

Well, the "robust auto compaction mechanism" doesn’t work for me. When the context gets close to 258k but not close enough the auto compaction fails with this error. And you have to salvage the context by asking gpt to parse the session in another session.

[ignatremizov]

+1, having control over compaction and context management (as well as more transparency into what is the prompt after compaction) is invaluable to proper workflows

[thisIsLoading]

yes, same. i do lots of spec work before letting it lose and need lots of context at times. so i find myself opening new sessions so that i dont suffer a compaction event in the middle of the spec work, which needs as many details as it gets and compaction obviously loses lots of details

[Undiluted7027]

Manual context compaction will enable us to control the timing of compaction and ideate our workflows based on when we want the context to be compacted rather than relying solely on auto-compaction. The developer's experience becomes more predictable with the models when context compaction can be manually controlled which is in case much valuable when the user only uses a single chat session for their work. Also, a question I could not get answer to from the docs: does context get shared between threads of a project? My understanding is that as of right now, it doesn't get shared across threads.

[jadentripp]

/compact is an essential part of my workflow. Just like with the model picker, I need control over my setup. I don't trust automatic mechanisms for this kind of thing(yet). I regularly see performance degradation when I approach 20% context left and when I use /plan on xhigh, often the context window will only have 10% left. I understand GPT-5.3-Codex performs better than other frontier models even at high context usage and that context is lost in compaction, but I want to completely avoid any performance degradation. Basically, the problem is Codex is entering the dumb zone(https://youtu.be/rmvDxxNubIg?t=355&si=aSHUwLLoTa05e1yF) in the app and the user has no way to manually compact to avoid it. If users had the ability to configure a compaction threshold, this dumb zone could be completely avoided.

[NightMachinery]

Giving users options never hurts. Auto-compaction is great, auto-compaction plus manual option is even better.

[ignatremizov]

does context get shared between threads of a project?

@Undiluted7027 not really. the maintainers are working on a SQL-backed memory system, still under development. Best sharing of context cross-thread is via AGENTS.md and SKILL.md files, or my preferred method recently, spec-kit files.