{"detail":"Bad Request"} on every turn + failed remote compact for one thread; other threads unaffected

Environment

• Codex version: 0.162.0 (x86_64-pc-windows-msvc), desktop app
• OS: Windows 11 (10.0.26100)
• Auth: ChatGPT (plan: prolite), model gpt-6.1-sol, effort low
• Failures observed: 2026-10-08, 22:49–23:08 local (UTC-7) / 2026-10-09 05:49–06:08 UTC

Thread

01a11278-17bd-78f2-9e63-f1a7eb66450d — started 2026-10-06, ~6,066 rollout records, ~54 user turns, 54.3 MB rollout file. Thread token usage at failure: ~217k of a 760k context window (not near the limit).

Symptoms

1. Normal turns: websocket stream closes 5/5 (stream disconnected before completion: websocket closed by server before response.completed), then HTTP fallback returns POST https://chatgpt.com/backend-api/codex/responses → status=400 Bad Request with body {"detail":"Bad Request"} (content-length 24).
2. UI shows Reconnecting 5/5 then {"detail":"Bad Request"}.
3. /compact also fails: Compaction interrupted — Error running remote compact task: {"detail":"Bad Request"}.

Key observations (from local logs and rollout file)

• Only this thread fails. Two other threads were actively completing turns on the same account/client during the failure window (22:55–23:10). No other thread has ever logged a 400 in logs_2.sqlite.
• All three request paths for this thread are rejected: websocket sampling, HTTP fallback, and remote compact. Retries are irrelevant — the 400 is deterministic.
• Last successful turn in the thread: 22:39 local (normal completion). First failure: 22:49 local. Nothing unusual happened between; the user was idle.
• Auth is healthy: GET /backend-api/codex/models returned 200 between failures.
• Context window is not the cause: 217k / 760k used.
• Model/settings are ordinary for this thread: gpt-6.1-sol, effort low.
• This looks like server-side rejection of the thread's stored history (state/compaction record the backend won't parse). Local /compact cannot repair it because compact itself is rejected.

Similar existing reports (possible duplicates)

• "Bad request" error #10571 — "Bad request" error after resume
• CLI intermittently halts with {"detail":"Bad Request"} and requires manual resume #34899 — CLI intermittently halts with {"detail":"Bad Request"} and requires manual resume
• Desktop threads can be poisoned by inline base64 tool images, leading to {"detail":"Bad Request"} on resume and likely inflated token usage #18629 — desktop threads affected by inline base64 tool images, leading to {"detail":"Bad Request"} on resume

This thread used custom_tool_call/custom_tool_call_output items and had one earlier successful session in the same rollout — possibly relevant to the history-rejection theories in the above issues.

What a fix needs

A way to recover or skip the poisoned history (e.g. client-side re-compaction that doesn't hit the rejected remote path, or server-side history repair), or at minimum a clearer error body than a 24-byte {"detail":"Bad Request"}.

Local evidence available on request

• ~/.codex/logs_2.sqlite entries: 5× status=400 Bad Request on /backend-api/codex/responses, all thread_id=01a11278-17bd-..., plus 5× responses_retry (n/5) websocket-close warnings per failed turn.
• Rollout file: ~/.codex/sessions/2026/10/06/rollout-2026-10-06T11-27-02-01a11278-17bd-78f2-9e63-f1a7eb66450d.jsonl