Manual /compact command in Codex app

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

• #9142

Powered by Codex Action

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.

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.

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

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?

@Khang5687 yes

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.

<img width="673" height="735" alt="Image" src="https://github.com/user-attachments/assets/1a62569a-a4b3-4a60-9bb1-8afdc5ef5d9e" />

+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

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

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.

/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.

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

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.

you mean this hasn't been added yet?

@etraut-openai removing it is a bad design choice, there are plenty of times where I compact context before moving to the next task because carrying forward full context increases cost for the session unnecessarily, and effectiveness of LLMs naturally decreases with longer context, so there are multiple good reasons to want this option before reaching context window limit auto-compaction. From a UX point of view I find it worse to expect it to exist as a slash command but not see it, as has been said as a user both options is better

Please add manual compaction.

I find myself opening the session in CLI just to run compact and going back to the App. Very frustrating.

@etraut-openai a simple but very common use case is finishing work on some branch/feature and starting work on a new one with an unpolluted, fresh context window. This alone warrants the option to manage it manually, not to speak of other reasons.

For design decisions like fully automated compaction, I understand the appeal. It sounds great in a product meeting to say: “Our compaction is so good that nobody ever has to think about it. We just roll forward indefinitely, and developers can focus on getting work done.” That’s a compelling vision.

But until you systematically enumerate the scenarios where someone might reasonably want to compact early—or at their discretion—you’re designing in a vacuum.

There are several practical cases where user-controlled compaction would be valuable:

1. Mid-stream phase changes

A conversation shifts from exploratory design to concrete implementation. The exploratory back-and-forth is no longer relevant, and keeping it around just increases context pressure. Manually compacting lets the user intentionally “checkpoint” the distilled understanding and discard the noise.

1. Correcting early misalignment

If the model made incorrect assumptions early on, and those assumptions are embedded in the context window, a user may want to compact after explicitly restating the correct constraints. Waiting until 100% utilization risks carrying forward stale or misleading framing longer than necessary.

1. Performance predictability

If compaction only happens at 100%, users are effectively operating in the 60–99% range without knowing whether that overhead is materially affecting latency, cost, or model behavior. Some workflows may prefer to compact proactively around 60–70% to stabilize performance characteristics.

1. Intentional summarization boundaries

Users often think in semantic “chapters.” Finishing a feature, closing a bug, wrapping up a design decision—these are natural breakpoints. A manual compaction button aligns the tool with how humans structure work.

1. High-stakes prompts

Before issuing a critical instruction (e.g., generating a migration script, refactoring a large file, or producing a formal artifact), a user may want to compact to ensure the model is reasoning from a clean, curated summary rather than an accumulation of exploratory noise.

1. Experimental workflows

Some users deliberately explore multiple directions in one session. Being able to compact after settling on a direction effectively “locks in” the chosen path and reduces cross-contamination from abandoned ideas.

1. Debugging model behavior

When outputs degrade, users may suspect context bloat or drift. Having the knob provides a diagnostic tool. Even if rarely used, it supports transparency and trust.

All of this operates under a simple assumption: running requests in the 60–70% context usage window might be unnecessary overhead if the user already knows they’ve crossed a conceptual boundary. Waiting until 100% to compact is a policy choice—not necessarily an optimal one for all workflows.

And importantly: having the knob doesn’t obligate users to use it. If the automated system is good enough, most people won’t touch it. But its presence acknowledges that edge cases exist. It’s an escape hatch, not a mandate.

Which raises the broader question: when is it worth gathering structured input from users versus optimizing for an idealized “it just works” experience? And separately—are the voices in this thread representative of the median user, or are we observing a vocal minority with atypical workflows?

If the cost of exposing a manual compaction control is low, the upside in flexibility and trust may outweigh the theoretical purity of a fully automated model.

-- Yours truly, Codex

There is a more simple reason to want this. If the context window is almost full, and I want to make a big request, I should be able to compact the context before I send the request. Otherwise Codex starts working, compacts very shortly into the request, then starts re-doing some of the work/research/searching that it JUST got done doing. This is a repetitive issue and just causes more work for Codex. We should just be able to include a compact command, and that should run before the request is started.

EDIT: Very shortly after writing this, I encountered exactly what I explained:

<img width="529" height="481" alt="Image" src="https://github.com/user-attachments/assets/d02d2272-c632-4056-9350-7ff2d7b623a8" />

@archiboi69 same thing here, guys WE NEED /compact in the app

+1

Manual compaction is a must-have. I'm sitting at 51% full in my current thread, having just finished and committed the first chunk of the task I'm working on. I'm about to upload a large PDF and start working on a totally different aspect of the task, and I really don't want auto-compaction to happen when I'm halfway through it. I want it to happen now, because I know I'm at a good stopping point and can tolerate some loss of detail in the conversation history so far, in order to buy more uninterrupted time before it must happen next.

context rot bro

Sometimes it finishes a turn with only about 20–25% of the context window left. Let's say the next task is fairly large. When it relies on auto-compaction alone, it starts reviewing the codebase, makes comments, says it will begin the work, then auto-compaction kicks in and it ends up re-reviewing the repo, re-planning, and rerunning the same searches and commands it already used during that last 20–25% of context which totally could have been avoided by manually running auto compaction before next implementation.

There's also a latency hiding angle here. In the above scenario, if I can manually kick off compaction before I start typing or dictating my prompts, then it can be finished by the time I'm ready to hit send. Whereas if I have no choice but to rely on auto compaction, it will add 10 to 15 seconds to the critical path during the next reasoning turn.

In my experience with gpt-5.4, the need for manual compaction has grown now that the context window has been expanded to 1 million tokens.

I usually want to manually compact somewhere between 150-400k tokens but I frequently have to switch to the cli to do that. This is a suboptimal solution because codex app doesn't refresh its list of project sessions so you have to quit to show the compacted session in your project, which is not possible if you have other tasks running.

@etraut-openai there are a lot of demands for this feature, may I ask when is it going to be implemented?

@Khang5687, we generally prioritize features based on community upvotes.

@Khang5687, we generally prioritize features based on community upvotes.

Meaning this thread will not be seen as a feature requests? What can we do

@Khang5687, we generally prioritize features based on community upvotes.

This issue currently has more than 50 upvotes, but it still doesn't appear within the first two pages when sorting issues by reactions. The last issue on the first page only has 49 upvotes.

Is this issue being intentionally excluded or filtered from the ranking?

Why tf is this so big problem to implement? :D I mean, if app would be os I would even not care about writing this comment... but let me be honest to you - ignoring community like this, is imho bad light to you guys, developers of openai...

@mvarchdev, we generally prioritize features based on community upvotes. This one has some upvotes, but there are many that have more. We're not ignoring the community, we're prioritizing based on its feedback.

Isn't this just a matter of adding a button?
There are significant issues with your ranking, as many simple but impactful small problems have not been improved and will never be prioritized

Auto compression is fine but having this option allows us to compress before moving to a new major task. And having this option to compress it before starting would allow us to not loose the context half way through the task. Please add /compact

Using /compact in the Codex CLI is part of the best practice to keep the context concise.

It just makes sense to have this in the Codex App, too. Hope it gets added!

Manual command is MUST have!

OpenAI, please add! Its not too complicated, but really useful

Manual compaction is an essential feature!

Codex App is 99% great! Manual compaction would make it 99.99%!

CLI already has this command, Hope app should have it too

Woah, crazy that this isn't implemented. This is the most important feature of coding harnesses. I use it dozens of times per day, especially now that we have 1m context with performance drop-off toward the end.

another example why we need the manual compact:

<img width="766" height="133" alt="Image" src="https://github.com/user-attachments/assets/8868385e-8468-488f-bf92-95a1ac97e762" />

what an annoyance that was.. i needed to manually copy tons of messages into a new chat to get the context filled what i painfully slowly worked out (because boy is gpt-5.4 retarded now.. you killed him! when it came out, it was almost AGI, and after 2 weeks, you made him dumb as a rock)

+1 for manual compact capability. very useful feature.
i want to have an ability to do a manual compact after plan and after implementation to start a new feature chapter

@etraut-openai We see a lot of demands for this future, are there any updates on this?

@etraut-openai could you please share the timeline on this feature? i can see this is one of the most requested features of them all

Hi there, I really like the Codex app, but this is a MUCH needed feature. Yes the auto compaction is good, but it's the timing and the context % used before compaction that is the problem.

Shortly / midway after the start of the implementation of a feature, after you have given codex the detailed context it needs, is about the worst time to compact, as it has just been long enough into the implementation that some essential context could be endangered. I have had this happen multiple times. I need to be able to choose to manually compact before starting a new feature.

According to my knowledge and current best practices, waiting until something like 90% of context is used, to then compact, is asking for degraded performance. If I'm operating in the CLI, I try to never let context reach more than 60-70% if I can. please correct me if I'm wrong @etraut-openai

+1

I've noticed that compaction workflows is one of those things OpenAI is very opinionated about, and is reluctant to take community input on. They really don't want it to be a knob that people adjust interactively.

such a weird hill to die on

the autocompact is not that robust. sometimes I get this and have to go to the cli and do the compactiona nd then come back or continue there. Also, sometimes I feel the model performance gets worse when the context gets large. so I prefer to compact and continue the same convesration with some context vs starting fresh

<img width="945" height="97" alt="Image" src="https://github.com/user-attachments/assets/29ce49ff-8e03-4d00-ade1-438864eb44fd" />

Cant believe this is still not implemented 😂

Gave up, switched back to Codex CLI because of that issue.

Tibo finally heard us

https://x.com/thsottiaux/status/2044591035532378511

we did it, folks

<img width="403" height="149" alt="Image" src="https://github.com/user-attachments/assets/40efa869-b095-45c3-bd50-59025f47e492" />

"codex can you add a command '/compact' which calls the the existing compact command?"

all it took was an 80 comment thread and pushback... woohoo!

wooohooo, beautiful feature

This feature is now implemented!

<img width="729" height="194" alt="Image" src="https://github.com/user-attachments/assets/c6cd2c43-a46d-447a-8abf-d0fd65594288" />

I Can`t use /compact feature

Version 26.429.30905(2345)

They quietly removed the feature, just to close this issue, they added a version first and then deleted it!

This feature is now implemented!

Can you explain why this feature was removed again

See it on Version 26.429.61741 (2429). I've had slash commands disappear for me due to configs (https://github.com/openai/codex/issues/17772), perhaps try clearing out config.toml and seeing if compact is still missing.

Hi @etraut-openai , why this feature was removed again?

In the app I often get "Codex ran out of room in the model's context window. Start a new thread or clear earlier history before retrying." after a long session.

Doing a compact fixes this. However, because I cannot do this from the app I need to:

1. copy the UUID of the thread from the app
2. start codex CLI with that thread ID
3. do a compact in the CLI
4. restart the app
5. continue work

Why was this feature removed?

In the app I often get "Codex ran out of room in the model's context window. Start a new thread or clear earlier history before retrying." after a long session. Doing a compact fixes this. However, because I cannot do this from the app I need to: 1. copy the UUID of the thread from the app 2. start codex CLI with that thread ID 3. do a compact in the CLI 4. restart the app 5. continue work Why was this feature removed?

don't you have the /compact command?

<img width="764" height="166" alt="Image" src="https://github.com/user-attachments/assets/122a43c0-1d02-42eb-b7fb-d75159a8a312" />

Version 26.609.41114 • Released 12 Jun 2026

I just updated the app, I have it now. Thanks