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.