Context compact error
What version of the Codex App are you using (From “About Codex” dialog)?
codex app: 26.429.61741 (2429)
codex cli: OpenAI Codex (v0.128.0)
What subscription do you have?
Pro $200
What platform is your computer?
Darwin 24.6.0 arm64 arm
What issue are you seeing?
Error message：
Error running remote compact task: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)
Ever since the release of GPT 5.5, my Codex has frequently encountered this error. This issue persists regardless of the context window size—whether it's the 256k context in GPT 5.4 or GPT 5.5, or even the 1M context in GPT 5.4. It occurs very frequently; essentially, about 80% of all "compact" operations fail.
What steps can reproduce the bug?
Uploaded thread: 019dfb31-0531-73f1-a22d-240b5499cbb1
What is the expected behavior?
This issue is severely impacting my workflow. Many conversations get stuck right when the context is about to be compacted, and restarting the app does not recover them. It has become extremely frustrating, and I hope this problem can be fixed as soon as possible.
At the moment, this effectively makes it impossible for me to reliably use Codex for long-running tasks or autonomous development sessions. Once a conversation enters a broken compaction state, the entire workflow is often lost, including task progress, planning context, and tool state. This significantly reduces the practicality of using Codex for complex engineering work that requires sustained context over extended periods of time.
What concerns me most is that the problem does not appear to correlate with the actual context window size. I have encountered the same failure pattern across 256k and 1M contexts, which suggests the issue may be related to the compaction/runtime pipeline itself rather than raw token limits. Given how frequently this occurs, it would be very helpful to have:
more robust recovery mechanisms after compaction failure,
better visibility into what stage failed,
and ideally a way to manually recover or resume corrupted sessions instead of losing the entire conversation state.
Right now, the instability around compaction is the single biggest blocker preventing me from depending on Codex for serious long-context workflows.
Additional information
_No response_
13 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
It's not just apps, CLIs encounter the exact same issues.
I got the same issue on the Pro plan. Thread id: 019dfa20-79d3-7bf3-8bb5-8b75abd3651b
Also seeing this on Codex Desktop for macOS.
Thread ID:
019e0390-d329-74c3-b8ab-13a32d339c9bCodex App:
26.429.61741 (2429)Error:
This is still happening today (2026-05-07).
just experienced the same thing today twice in a row
codex CLI meet the same issue. VERY VERY FRENQUENCYLY
@JialinLiu-codedance Hey — I felt this issue immediately, and it is very close to the exact pain I’m trying to solve.
I’m building AgaveCore, and I’d like to let a few early people use it for free while I shape it into something stronger.
It helps when a coding agent starts to drift, loses important context, or gives you an output you do not fully trust.
In practice, it works through two habits:
remember-progressorremember-thiswhen something important should not be lostconsult-brainwhen the current task needs more grounded feedback on what to do nextOver time, as useful journals, decisions, and failures pile up, the product should help the agent make sharper decisions and take better actions with less drift.
If this sounds relevant, reply here and I’ll send the exact steps. You can also use the email or Telegram on my profile.
Cheers,
Mads.
same issue for the last 3 days. Location: Germany. Codex: Version 26.506.31421 (2620)
This is a server issue. I feel Codex may start going downhill from here given the Claude exodus.
Same issue it's not possible to work reliably with codex due to this error fd99d561-e4a6-45a4-af9d-25e84805db7b and 5c5da276-22d6-43fa-8aad-9dea78ccd979
same issue, very difficult to work with this
Adding another data point with a more specific trigger and workaround.
I can reproduce the same compact endpoint error in a long Codex (v0.130.0) session when using xhigh reasoning with Fast mode enabled. Once the context usage is above roughly 85%, if I turn Fast mode off and then run
/compact, the compact task consistently fails with:This is repeatable for manual
/compactretries, and the automatic compact operation also fails in the same state.Workaround: if I turn Fast mode back on and then run
/compact, compaction completes successfully.This makes me suspect there may be a difference in the compact request path, timeout behavior, or routing when Fast mode is toggled off after the session is already near the context limit. It would be helpful if
/compactcould recover reliably regardless of the current Fast mode setting, or at least surface a clearer error and recovery path when this specific state is reached.Still a real issue : 019e6351-ce0e-7920-8dbb-f26b4df3bbff
Thanks for reporting this problem. Until recently, Codex used a separate endpoint and server-side logic for compaction. We recently switched to a more robust approach where the compaction logic is moved locally using the same endpoint as normal turns. This eliminates "remote compaction" errors and increases the stability and reliability of compaction operations. If you see further problems with compaction, please use
/feedbackand open a new bug report.