Codex Desktop on macOS: automatic context compaction fails every time with “error decoding response body”

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

• #38861
• #38434

Powered by Codex Action

Read through the remote-compaction failure handling on main @ 1f41cc5d92 — the reason this is so damaging is structural: when remote compaction fails, there is no fallback to local compaction, and the only fallback that does exist is unreachable for transport errors.

1. The compaction implementation is chosen one-way. run_auto_compact picks remote-v2 / remote-v1 / local once, from the provider's capability (core/src/session/turn.rs#L1183-L1236). OpenAI-backed threads always take the remote path; the local implementation (run_inline_auto_compact_task) exists in the same file but is never used as a fallback when the remote path fails.

2. The only in-path fallback can't trigger on your error. Inside the remote path there is a model fallback (retry the remote compact with the current model), gated by should_retry_with_current_model:

https://github.com/openai/codex/blob/1f41cc5d92722748e45cae9cecc6d883a4e7cbb1/codex-rs/core/src/compact_model_fallback.rs#L9-L20

The accepted list is InvalidRequest / UnexpectedStatus / ContextWindowExceeded / UsageLimitReached / ServerOverloaded / InternalServerError / RetryLimit — transport/stream failures like yours (Transport error: network error: error decoding response body) are not in it. So after the visible Reconnecting 2/2 retries, run_remote_compact_task_inner_impl returns the error hard (compact_remote.rs#L181-L189), the turn is interrupted, and the thread is stuck at exactly the point where compaction is mandatory. There's also no user-facing switch to force local compaction (the only related knob is the remote_compaction_v2 feature flag, which toggles which remote implementation runs).

3. About the error text. "error decoding response body" is the HTTP client's (reqwest's) generic wrapper for a body that ended prematurely or failed content decoding (e.g. truncated chunked/gzip stream) — the status code and headers that would identify the server-side cause are discarded when it's wrapped into TransportError::Network. That your failure is deterministic per compaction attempt (not flaky) suggests something reproducible about these threads' compact responses — but with the current error surface, neither you nor the maintainers can see what. Capturing status + content-encoding/content-length on decode failures would make this class of report diagnosable.

Fix outline:

1. Local fallback: after remote retries exhaust (regardless of error class), run run_inline_auto_compact_task instead of failing the turn. Local compaction is strictly better than a dead thread; the machinery is already present and selected today for providers without remote support.
2. Widen or bypass the model-fallback gate for transport errors — retrying the same request "2/2" and then giving up is the same blind-retry pattern as #38831/#38846; a deterministic decode failure needs a different action, not the same request again.
3. Error detail: include status/headers context on body-decode failures so the server-side trigger can actually be identified.

(1) alone converts this from "long conversations become unusable" into, at worst, "compaction quality falls back to the local summarizer" — and it's the smallest change of the three.

Additional reproduction on 2026-08-27, with the same exact remote-compaction error across three separate development threads.

Verified environment

• Desktop app: 26.820.60940, build 7119.
• Bundled Codex runtime: 0.150.0-alpha.8. This was verified both with the bundled executable's --version output and the affected sessions' metadata.
• Host: macOS 15.7.3, arm64.
• The same error was also visible when viewing an affected desktop-hosted task from the mobile app.

Observed behavior

All three threads ended in systemError, with their latest turns marked failed and the identical error:

Error running remote compact task: stream disconnected before completion: Transport error: network error: error decoding response body

The workflows were different. Ordinary local tool commands completed before the compaction failure, and earlier turns in these threads had completed successfully. This interrupts ongoing work during conversation-history maintenance rather than reporting a project build or command failure.

Observed sequence: work normally in an existing multi-turn thread, send a follow-up, allow local commands to execute, then receive the remote-compaction error and a failed turn. I do not have a minimal deterministic reproduction or a measured failure rate across all compaction attempts.

Impact and expected behavior

Repeated interruptions leave work and verification incomplete. Since earlier actions may already have taken effect, recovery requires checking existing state before rerunning anything. Compaction should complete reliably or provide a safe recovery path instead of repeatedly aborting the active turn.

I have not established whether the root cause is the desktop runtime, the compaction backend, or network transport, and cannot attribute it to a particular update. I have not verified this on runtime 0.150.1.

Project names, source code, local paths, screenshots, thread IDs, and raw session/log files are intentionally omitted from this public report. No in-app diagnostic upload was performed for this reproduction.