Codex Desktop: repeated /responses/compact 404 causes loss of usable session continuity
Codex Desktop: repeated /responses/compact 404 causes loss of usable session continuity
Summary
Codex Desktop is repeatedly failing during remote context compaction with:
Error running remote compact task: unexpected status 404 Not Found: {"detail":"Not Found"}
Endpoint:
https://chatgpt.com/backend-api/codex/responses/compact
This has now reproduced across restarted work and is materially affecting the ability to continue long-running development/research sessions.
Environment
- macOS
- Codex Desktop
- ChatGPT Pro account
- UK/London region
- Long-running local software/research projects
Recent reproduced failures
Failure 1
Endpoint:
https://chatgpt.com/backend-api/codex/responses/compact
Response:
404 Not Found: {"detail":"Not Found"}
Request ID:
970861c3-74b9-4c07-9219-bacd62fb9fd4
Cloudflare ray:
a2be91475832eefb-LHR
Failure 2
After restarting and re-establishing the project context, Codex again failed during a relatively bounded repository inspection task.
Response:
404 Not Found: {"detail":"Not Found"}
Request ID:
8cde8caa-6b53-4f2e-90d8-9ef9854b65ac
Cloudflare ray:
a2bf3c69aa133eca-LHR
Endpoint was again:
https://chatgpt.com/backend-api/codex/responses/compact
User-visible consequence
The main problem is not simply that compaction reports an error.
After a compaction failure, the agent can lose enough effective conversational/task context that continuing the existing session is unsafe or impractical.
In one case I restarted the session and the agent reported a very large dirty Git working tree. A subsequent forensic inspection showed that the tree was predominantly legitimate accumulated WIP and generated analytical outputs rather than corruption.
We therefore had to:
- stop development;
- create a ~1.4 GB external recovery snapshot;
- reconstruct durable project context from filesystem artefacts;
- inspect and classify the outstanding working tree;
- create several narrow preservation commits;
- restart the agent from explicit filesystem handoffs.
The compaction failure did not appear to corrupt the repository, but loss of reliable agent context made it necessary to treat the repository as potentially unsafe until independently verified.
Important reproduction observation
The second 404 occurred after restart while Codex was performing a relatively modest preservation/triage task.
It had begun:
- checking preservation of one staged file;
- searching a large JavaScript file for Health/CTS/UI-related areas;
- inspecting dependencies between UI, dataset construction and SQLite export.
Before substantive modification or commit, remote compaction failed again with the second 404 above.
This makes it less likely that a single malformed repository operation explains the failure.
Expected behaviour
When the context requires compaction, Codex should successfully compact the session and continue with sufficient task state to preserve reliable agent continuity.
If compaction itself cannot complete, the existing session should fail safely without leaving the user uncertain about which task context the agent still retains.
Actual behaviour
Remote compaction intermittently/repeatedly returns HTTP 404 from:
/backend-api/codex/responses/compact
The resulting session can no longer be trusted to retain the working context required for continued development.
Severity
For short disposable tasks this would be inconvenient.
For long-running agentic development it is significantly more serious because conversational state includes:
- task intent;
- decisions already made;
- safety constraints;
- interpretation of existing WIP;
- files deliberately preserved or excluded;
- pending work;
- provenance of uncommitted changes.
Repeated failure therefore makes long-running Codex sessions difficult to use safely even when the underlying repository remains intact.
Questions
Could you determine from the request IDs whether:
- the 404 is caused by account/session routing, client state, model routing, or the compaction service itself;
- the failures are associated with session/context size;
- this account/client is encountering the failure unusually frequently;
- any logs or diagnostics from Codex Desktop would help identify the cause; and
- there is a recommended workaround while the issue is being investigated?
I can provide further request IDs/logs if required.
6 Comments
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
I cannot open the About Codex dialog from the terminal, but the Codex binary bundled with PyCharm reports:
codex-cli 0.137.0
@agentclientprotocol/codex-acp 0.0.46
Environment: PyCharm 2026.1 on macOS, using Codex through the JetBrains/PyCharm integration. The
codexcommand is not on PATH; these versions came from:~/Library/Caches/JetBrains/PyCharm2026.1/aia/codex/bin/
@ianpurves, Make sure you're using the latest Jetbrains extension. The Codex harness stopped using the
responses/compactendpoint months ago, so you are using an out-of-date harness. If you're using the latest Jetbrains extension, report the issue to Jetbrains so they are encouraged to release an update.Thanks — that appears to have been the issue. I updated PyCharm and the AI Chat/JetBrains integration after reporting this. Since the update I have restarted the same repository work and completed several previously failing Codex tasks without another /responses/compact 404.
Before updating, the failure reproduced repeatedly, including immediately after restarting a session. I'll continue testing and report back if it recurs. If useful I can provide the previous and current JetBrains/AI Chat version details once I locate them.
This looks like a useful real-world persisted-session case for
codex-rescue, an experimental local-first recovery/diagnostic tool I’m field-testing. It won’t fix the upstream/responses/compact404, but it can test whether the local rollout remains structurally recoverable and whether repository state can be verified without guessing.If you’re willing, please start with the read-only path:
If
doctorfinds an interrupted/damaged state and you want to test the recovery path:Please share only sanitized command output, versions, and exit codes. No raw rollout/SQLite files, private prompts, credentials, or unredacted home paths. Repo: https://github.com/shleder/codex-rescue
Closing as resolved after updating the JetBrains/PyCharm AI Chat integration.
Thanks @etraut-openai — your explanation appears to fit what I was seeing.
Before the update I repeatedly received:
404 Not Found {"detail":"Not Found"}from:
https://chatgpt.com/backend-api/codex/responses/compactThis reproduced across restarted sessions and made longer-running Codex work effectively unusable when compaction was attempted.
After updating PyCharm and the AI Chat/JetBrains integration, I restarted the same substantial WhitebredRecords recovery work. Codex has since completed a long sequence of increasingly substantial tasks, including repository analysis, selective Git recovery, test execution, deterministic builds and deployment preparation, without another
/responses/compact404.So the evidence is consistent with the JetBrains integration having been using an outdated Codex harness that still called the obsolete compaction endpoint, rather than a problem with the repository or my account.
I can't prove the client update was causal, but the before/after behaviour is quite striking.
For reference, two failures before updating were:
970861c3-74b9-4c07-9219-bacd62fb9fd48cde8caa-6b53-4f2e-90d8-9ef9854b65acI'll close this issue as resolved. If the same endpoint error recurs on the updated JetBrains integration, I'll reopen/report it with the new request details.
Thanks for pointing me in the right direction.