/compact does not work.

Also compact make codex lose context. It does not remember the latest discussion but instead it remember the middle of the previous context/discussion. Needs some improvement in how to compact efficiently without losing what was done and where it stopped before compact.

The following features would be ideal:

1. When less than 5% remains, prompt the user to perform /compact or perform it automatically (having this as a selectable option would be ideal).
2. In addition to /compact, enable saving a work log to a file. It would be even better if the user could define the quality of the log.

Currently, /compact alone is not sufficient, and although instructions for work logging are given in prompts and AGENTS.md, some information is missed.

If this functionality were implemented as a feature, it would greatly improve continuity.

As an urgent measure for now, I’d like the remaining percentage to be displayed as before.
That alone would be enough to handle the situation for the time being.

The main issue at the moment is that the remaining context is displayed during inference, but not when waiting for a prompt.

The following features would be ideal: 1. When less than 5% remains, prompt the user to perform /compact or perform it automatically (having this as a selectable option would be ideal). 2. In addition to /compact, enable saving a work log to a file. It would be even better if the user could define the quality of the log. Currently, /compact alone is not sufficient, and although instructions for work logging are given in prompts and AGENTS.md, some information is missed. If this functionality were implemented as a feature, it would greatly improve continuity. As an urgent measure for now, I’d like the remaining percentage to be displayed as before. That alone would be enough to handle the situation for the time being. The main issue at the moment is that the remaining context is displayed during inference, but not when waiting for a prompt.

That's on our roadmap. As a work around you can edit the previous messages (using esc esc) to gain back some context then compact.

> The following features would be ideal: > > 1. When less than 5% remains, prompt the user to perform /compact or perform it automatically (having this as a selectable option would be ideal). > 2. In addition to /compact, enable saving a work log to a file. It would be even better if the user could define the quality of the log. > > Currently, /compact alone is not sufficient, and although instructions for work logging are given in prompts and AGENTS.md, some information is missed. > If this functionality were implemented as a feature, it would greatly improve continuity. > As an urgent measure for now, I’d like the remaining percentage to be displayed as before. That alone would be enough to handle the situation for the time being. > The main issue at the moment is that the remaining context is displayed during inference, but not when waiting for a prompt. That's on our roadmap. As a work around you can edit the previous messages (using esc esc) to gain back some context then compact.

Excellent looking forward to that

.45 same thing, /compact name loses all context, /compact alone, 0 percent context left, even after a compact.

In the end, the best solution is to proceed with the work while keeping a work log.
Thank you👍

With Codex 0.45 I am getting a stream error when calling /compact. Other prompts like "hello" are working as expected. I am using gpt-5-codex on Azure AI Foundry using the responses API.

Thank you for the report.
For the time being, I’ll operate under the policy of not using /compact and instead clearing the context with esc -> esc -> enter to continue in a new session.
By the way, I experienced a memory error that caused Codex to crash while using 0.45, but since I can’t reproduce it, I’ll monitor the situation for now.

@EnterOgawa could you share some logs on this memory error?
You can find internal logs in ~/.codex/log/codex-tui.log

Came across this issue and just wanted to chime in on what my experience has been. I am noticing that i need to run /compact with some minimum percentage left so that it can work. If its below a certain percentage it will fail with the stream error messages. It needs this minimum percentage because it seems to add to the context the first time /compact is run as the context % left value always decreases further on the first run. If I then run /compact again it works as expected. Maybe its doing the compact the first time and adding the compacted context to the current context before using it when compact is run again? Not sure, but this is how its working for me after the update.

on .46:

stream error: unexpected status 400 Bad Request: {
"error": {
"message": "No tool call found for function call output with call_id call_aWKmTzyNSS5A7142Mq2TMXvt.",
"type": "invalid_request_error",
"param": "input",
"code": null
}
}; retrying 5/5 in 3.464s…

during compact, and compact fails

So I have been dealing with his problem as well (similar Azure deployed gpt-5-codex model gets the exact result listed here when trying to use /compact.

I finally became fed up after the issue persisted for so many release tags unresolved and decided to take a crack at fixing it myself in a fork. I love working with Codex interactively and its killing me not being able to compact in long running interactive sessions.

The approach I took was capturing the exact prompt that CodexCLI is sending during the /compact event and then looking at the API's refusal. Turns out - it's Azure's own content violation system. There is something about the way that the prompt is written that causes Azure's filtering mechanism to flag it as a content rejection (most likely a system that looks for malicious prompt injection is misbehaving).

Azure Block Diagnosis

• Directly hitting the Responses endpoint with the original compact prompt (codex-rs/core/templates/compact/prompt.md) produced an immediate response.incomplete with incomplete_details.reason =

"content_filter", proving the refusal comes from Azure’s policy layer—not the CLI.

• The old wording (“You have exceeded the maximum number of tokens…” + “write a short memento…”) strongly resembles instructions about prompt‐state limits; Azure likely classifies it as a

jailbreak/prompt-injection pattern and blocks it.

• Rephrasing the request to a neutral handoff summary (“The conversation history is about to roll off. Draft a concise handoff note…”) let Azure stream a full response and emit

response.completed, confirming the filter is triggered by specific language rather than the task itself.

I literally just changed the /compact prompt in a fork to:

  The conversation history is about to roll off. Draft a concise handoff note for the next engineer that covers:
  - What was completed during this session.
  - What still needs work, including file paths or line numbers where possible.
  - Tests that should be added or rerun (edge cases, perf, integration, etc.).
  - Any setup tips, open bugs, or quirks the next engineer should know before resuming.

Based on the direct SSE traces, the only thing triggering Azure’s filter was the wording of the original compact handoff prompt:

You have exceeded the maximum number of tokens, please stop coding and instead write a short memento message for the next agent. Your note should…

That language closely mirrors common prompt-injection patterns (“you have exceeded…”, “stop coding”, “write a note”), which adversaries often use to convince a model to drop guardrails. Azure’s content-moderation heuristics appear to treat it as a jailbreak attempt and immediately emit response.incomplete / content_filter, even though the rest of the instructions are benign.

Once I rephrased the request to a neutral, status-report framing (“The conversation history is about to roll off. Draft a concise handoff note…”), Azure streamed a full response and ended with response.completed. So the functionality is unchanged; I simply avoided trigger phrases that look like injection or policy-evasion attempts.

@jif-oai edited to tag jif on this since their name is on the prompt file I had to adjust in my fork

I was late in noticing the message 💦
Thank you, everyone.

@jif-oai
I’ve understood the location of the logs. I’ll make sure to attach them next time an issue occurs.

@bradvb1234
@deksden
@tylerstraub
Thank you for the information.
I’ll refer to this information to ensure proper usage.

I look forward to your continued support.

It's worth noting for Azure that in my branch of CodeCLI I propigated the content filter refusal error up to the client so I can see whenever it happens - and it's not just rejecting this one prompt. Sometimes random instructions will just be refused by Azure because of its overly agressive prompt injection detection system. I don't even think we can bypass it as customers which sucks.

update I am silly:

sooo it turns out Azure does allow you to define your own adjustments to their filtering in "Guardrails + controls" with Azure AI Foundry.

completely hacked around the problem when I could have just read the manual ¯\_(ツ)_/¯

maybe this is just a documentation item rather than a bug

There is still something going on with the /compact command for Codex with this build. I have to run it twice before the session runs out of context to get it to reset the context. If I run i with minimal or 0 context left, it will error as shown in @EnterOgawa's initial post. In previous build, I only had to run it once and could run it with 0% context remaining.

Thank you, @brad-worksafely .
We are currently operating by resetting the session before it reaches 0%, and this approach has been functioning without any particular issues.

By the way, regarding the next issue, it seems to be automatically excluded, so could you consider reviewing and possibly fixing it?
#5274

on .46: stream error: unexpected status 400 Bad Request: { "error": { "message": "No tool call found for function call output with call_id call_aWKmTzyNSS5A7142Mq2TMXvt.", "type": "invalid_request_error", "param": "input", "code": null } }; retrying 5/5 in 3.464s… during compact, and compact fails

I'm getting the same error 😢

Came across this issue and just wanted to chime in on what my experience has been. I am noticing that i need to run /compact with some minimum percentage left so that it can work. If its below a certain percentage it will fail with the stream error messages. It needs this minimum percentage because it seems to add to the context the first time /compact is run as the context % left value always decreases further on the first run. If I then run /compact again it works as expected. Maybe its doing the compact the first time and adding the compacted context to the current context before using it when compact is run again? Not sure, but this is how its working for me after the update.

And if you have already lost all %, you can use the esc esc to go back a few messages to get somewhat around 15% (or more) context back and edit one of those previous messages to then run /compact twice, and you should get the 100% back

I think this bug has been fixed since the bug report was filed. If you see this problem again, please use the /feedback slash command to upload the session and provide a thread ID.