[macOS desktop] Recurrent HTTP 400 {"detail":"Bad Request"} during normal turns and remote compaction below context limit #52406

What happens

Codex desktop repeatedly interrupts long-running local chats with HTTP 400 and only {"detail":"Bad Request"} in the response. This has affected more than one chat. Both ordinary model requests and remote compaction have failed, so compaction is not a reliable recovery path.

This is intermittent: an ordinary continuation later succeeded with the same active image history and without a new compaction. I do not have a deterministic minimal reproduction yet.

Environment

• macOS, Codex desktop 26.1002.52244, build 13536, prod release channel.
• Bundled codex-cli: 0.162.0-alpha.2.
• Model: GPT-6.1 Sol; reasoning: high; service tier: priority.
• ChatGPT authentication; no custom model provider.
• The app updater reports up_to_date for the configured channel.
• Endpoint: https://chatgpt.com/backend-api/codex/responses.

Failure and successful controls

All timestamps below are UTC on 2026-10-09. Sizes are reconstructed request-body sizes from the local diagnostic investigation, not server-side measurements.

At the latest failure, client logs reported:

• auto_compact_scope_tokens=88921.
• Auto-compaction threshold: 100000.
• full_context_window_limit=258400.
• Both token-limit-reached flags were false.

The larger successful request means a simple fixed 8 MiB request-size cutoff does not explain these observations.

Additional failures in the same chat occurred at 2026-10-08T21:03:20Z, 2026-10-09T02:09:24Z, and 02:09:58Z. At 02:25:37Z, the log specifically recorded Error running remote compact task: {"detail":"Bad Request"}. Successful compactions also occurred between these failures. Another local chat had HTTP 400 failures on October 7.

Local checks and recovery observations

• The session JSONL parsed successfully.
• Checks of the five failure boundaries found correctly paired tool call/output IDs and no duplicate IDs.
• Relevant image encodings and image integrity checks passed.
• The latest failing active history contained 16 PNG images. The last addition before failure was approximately 8,145 characters of text, with no new image.
• An ordinary continuation between 04:02:30Z and 04:04:54Z succeeded without another compaction, while those 16 images remained in the active history.
• No environment HTTP/HTTPS/ALL proxy or enabled system HTTP proxy was found. A VPN extension is present; no VPN on/off comparison was performed.

Separate explanation for apparently early compaction

A local troubleshooting workaround had explicitly set model_auto_compact_token_limit=100000. That explains compaction at approximately 39% of the 258400-token window. It did not prevent HTTP 400 and has been removed from the configuration. Existing running chats still showed the cached 100000 threshold; reload verification remains pending. I am not presenting that configured threshold as evidence of a default context-window defect.

Expected behavior / requested investigation

Please correlate the failed and successful request IDs to identify the precise backend validation failure, including why a remote compaction can also receive the same generic 400. An actionable error and a supported recovery path would help avoid repeatedly interrupting long-running work.

The request-size and token observations above are evidence, not a confirmed root cause. No account credentials, raw request bodies, screenshots, project source, or complete session transcripts are included in this public report.

Related: #52320 and #43711. This report adds macOS evidence and intermittent failure/success controls.