Codex Desktop: repeated /responses/compact 404 causes loss of usable session continuity

Resolved 💬 6 comments Opened Aug 16, 2026 by ianpurves Closed Aug 16, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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:

  1. stop development;
  2. create a ~1.4 GB external recovery snapshot;
  3. reconstruct durable project context from filesystem artefacts;
  4. inspect and classify the outstanding working tree;
  5. create several narrow preservation commits;
  6. 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:

  1. the 404 is caused by account/session routing, client state, model routing, or the compaction service itself;
  2. the failures are associated with session/context size;
  3. this account/client is encountering the failure unusually frequently;
  4. any logs or diagnostics from Codex Desktop would help identify the cause; and
  5. there is a recommended workaround while the issue is being investigated?

I can provide further request IDs/logs if required.

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 12 days ago

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

  • #38370
  • #38706
  • #38323
  • #38513
  • #38525

Powered by Codex Action

ianpurves · 12 days ago

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 codex command is not on PATH; these versions came from:
~/Library/Caches/JetBrains/PyCharm2026.1/aia/codex/bin/

etraut-openai contributor · 11 days ago

@ianpurves, Make sure you're using the latest Jetbrains extension. The Codex harness stopped using the responses/compact endpoint 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.

ianpurves · 11 days ago

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.

shleder · 11 days ago

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/compact 404, 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:

pipx install codex-rescue
codex-rescue sessions
codex-rescue doctor --latest

If doctor finds an interrupted/damaged state and you want to test the recovery path:

codex-rescue salvage --latest --fork
codex-rescue verify <rescue-id>

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

ianpurves · 11 days ago

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

This 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/compact 404.

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:

  • Request ID 970861c3-74b9-4c07-9219-bacd62fb9fd4
  • Request ID 8cde8caa-6b53-4f2e-90d8-9ef9854b65ac

I'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.