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

Summary

In Codex Desktop on macOS, automatic context compaction consistently fails whenever it is triggered. The task runs normally before compaction, but once the UI enters Context automatically compacting, it reconnects and then reports a remote compact transport/decode failure.

This is not an isolated one-off failure: in my sessions, it happens every time context compaction is triggered, making long-running conversations unreliable and difficult to continue.

Error

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

The UI shows:

Context automatically compacting
Reconnecting 2/2

and then the error above.

Environment

Product: Codex Desktop
Platform: macOS
Subscription: ChatGPT Pro
Model shown in the affected session: GPT-5.6 Sol Ultra
App version: not visible in the captured screen; diagnostics were submitted from the affected session

Steps to reproduce

Open or continue a long-running Codex Desktop conversation.
Let Codex work normally until automatic context compaction is triggered.
Observe Context automatically compacting.
The compact operation enters a reconnect cycle (Reconnecting 2/2).
It fails with:

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

Continue using other sessions until compaction is triggered; the same failure recurs.

Actual behavior

The remote compact task disconnects before completion.
The response body cannot be decoded.
The current task is interrupted during compaction.
Long-running conversations become unreliable because the failure occurs at the exact point where compaction is required to continue safely.

Expected behavior

Automatic compaction should complete successfully and preserve enough task state for the agent to continue.
A transient transport failure should retry robustly or use a safe fallback.
The thread should not become blocked or unreliable merely because it reached the compaction stage.

Diagnostics

Feedback was submitted from the affected session with diagnostics enabled.

Feedback ID: 01a00ebf-d399-7373-975c-c359138dd909

Related reports

Similar symptoms appear in #31375, #32545, #38434, and #38861. This report adds a current macOS Codex Desktop reproduction using GPT-5.6 Sol Ultra, with a fresh Feedback ID tied to the affected session and the observation that the failure occurs every time automatic compaction is triggered.

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

Codex App reports “Context compacted” after remote compaction failed, then remains stuck reconnecting #38861
Remote compaction and long-running tasks consistently fail across Codex Desktop/Work, VS Code, and WSL CLI #38434

Powered by Codex Action

Read through the remote-compaction failure handling on main @ 1f41cc5 — 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:

codex/codex-rs/core/src/compact_model_fallback.rs

Lines 9 to 20 in 1f41cc5

    
           pub(crate) fn should_retry_with_current_model(error: &CodexErr) -> bool { 
        
               matches!( 
        
                   error.details(), 
        
                   CodexErrorDetails::InvalidRequest(_) 
        
                       | CodexErrorDetails::UnexpectedStatus(_) 
        
                       | CodexErrorDetails::ContextWindowExceeded 
        
                       | CodexErrorDetails::UsageLimitReached(_) 
        
                       | CodexErrorDetails::ServerOverloaded 
        
                       | CodexErrorDetails::InternalServerError 
        
                       | CodexErrorDetails::RetryLimit(_) 
        
               ) 
        
           }

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:

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.
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 response.incomplete is treated as a retryable stream failure, causing unnecessary retries and transport fallback #38831/Long CLI threads exceed Responses WebSocket message limit before auto-compaction (close code 1009) #38846; a deterministic decode failure needs a different action, not the same request again.
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.

I'm seeing the same issue. Auto-compaction starts, then Codex shows "Reconnecting..." and the session gets stuck or becomes unusable. Other chats work normally, so it seems specific to that session/compaction flow. I'm using GPT-6 Astra with Extra High reasoning, macOS Desktop client, latest version available.

I am experiencing the same issue on Codex Desktop for macOS.

The affected existing thread consistently fails with:

Error running remote compact task: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses)

Important detail: a new Codex conversation in the same project works normally, while the affected existing thread cannot continue. Updating ChatGPT Desktop to the latest available version did not resolve it.

I specifically need to recover and continue the existing thread rather than migrate the project to a new conversation.

I submitted diagnostics from the affected thread.

Feedback ID: 01a071ac-19be-7401-ae4e-326cc4b7a9fb

Please investigate whether this affected thread can be recovered and whether failed remote compaction can retry/fallback without leaving the existing thread unusable.

Additional verified recurrence on 2026-09-07 in Codex Desktop on macOS: the two most recent consecutive turns of the same existing task both failed during remote compaction.

The stored task state is systemError; both turns are failed with this identical error:

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

Observations from the affected task's turn records

Attempt	Started (UTC)	Failed (UTC)	Whole-turn duration
Earlier failure	2026-09-07 08:08:15	2026-09-07 08:23:34	919.232 seconds
Next failure	2026-09-07 08:38:27	2026-09-07 08:43:57	330.295 seconds

These durations cover the complete turns, not a measured compaction request or network retry.

The earlier failed turn produced task commentary and local tool activity before the compaction error. The next turn failed with the same error and has zero recorded task items. An earlier turn in this task had completed successfully. Continuing the existing task has therefore resulted in repeated failures, leaving the work unable to proceed in that task. A separate task can still read the affected task's status and use tools.

Environment and limits of this report

Product: Codex Desktop, local task.
Current host: macOS 26.5.2, arm64.
Exact app/runtime version and affected model were not independently captured for this report.
The error records contain no additional details, HTTP status, or request ID.
No deterministic minimal reproduction or failure rate across all compaction attempts has been established.
The error identifies the remote-compaction/transport path, but the root cause has not been isolated to the backend, client, or network.

Impact and requested investigation

Repeated compaction failure interrupts an ongoing task even when prior work has already been performed. Please investigate recovery of affected existing tasks and a reliable retry/recovery path that preserves task state instead of repeatedly failing on continuation. More actionable compaction request/error diagnostics would also help distinguish backend failures from client or network transport problems.

This is a sanitized public recurrence report. Project names, source code, local paths, task/turn IDs, and raw task/log files are omitted. No new in-app diagnostics upload was performed for these two failures.

Additional macOS reproduction on September 8–9, 2026, with correlated terminal turn states and transport retry logs. Posting the evidence here after checking existing reports, rather than opening another issue with the same error.

Environment

Codex Desktop, local tasks on macOS 26.1 (25B78), arm64.
Affected session metadata reports Codex runtime 0.153.4. The Desktop UI package version was not captured.
ChatGPT authentication, built-in OpenAI provider; Responses endpoint chatgpt.com/backend-api/codex/responses.
Affected models include gpt-6-astra, gpt-5.6-sol, and gpt-5.6-luna.

Measured impact

The review covers retained local records from 2026-09-08 00:00:00 through 2026-09-09 23:56:54, UTC+08:00, across 27 user-facing tasks and 41 subagent tasks.

There were 11 terminal transport failures with this exact error:

stream disconnected before completion: Transport error: network error: error decoding response body

Failure stage	Terminal failed turns
Remote context compaction, with the `Error running remote compact task:` prefix	7
Ordinary response generation	4

Eight of these failures occurred across seven user-facing tasks; three occurred in subagents. A separate model-capacity failure is excluded from these 11.

The same window contains 1,042 retry log records from codex_core::responses_retry, including internal calls. These are not 1,042 failed tasks: 90 turns with retry records ultimately completed successfully. Interrupted turns were also kept separate from terminal failures.

The retry records break down as:

501: peer closed the TLS connection without close_notify
213: tls handshake eof
179: sending a WebSocket request failed because the connection was already closed
89: error decoding response body
40: connection/request-send failures
16: connection refused
3: WebSocket reset without a closing handshake
1: HTTP 503 with an upstream connection failure

Correlated compaction failure

The repeated sequence is:

TLS/WebSocket failure → retries → falling back to HTTP → response-body decode failures → terminal failed turn.

Eight of the 11 failed turns have an explicit HTTP fallback entry within that same turn. The other three belong to tasks that had already fallen back in an earlier turn.

One concrete example on 2026-09-09, with all times below in UTC:

08:03:55  remote compaction v2 stream failed; retries=1 max_retries=2
          compact_error=stream disconnected before completion:
          IO error: peer closed connection without sending TLS close_notify

08:05:02  remote compaction v2 stream failed; retries=2 max_retries=2
          same TLS close_notify error

08:06:10  falling back to HTTP

08:07:21  remote compaction v2 stream failed; retries=1 max_retries=2
          compact_error=stream disconnected before completion:
          Transport error: network error: error decoding response body

08:08:38  remote compaction v2 stream failed; retries=2 max_retries=2
          same response-body decode error

08:09:39  turn status=failed
          Error running remote compact task: stream disconnected before completion:
          Transport error: network error: error decoding response body

There is also a repeat-failure example on September 8: continuing an affected task at 06:23:01 UTC led to another failure at 06:25:46 UTC, with Failed to run pre-sampling compact. This can prevent the next turn from reaching normal generation.

Reproduction and evidence limits

Observed workflow: perform a multi-step coding task, allow automatic compaction, encounter the reconnect/fallback sequence, then attempt to continue the task. The issue recurred across several tasks. This is an observational reproduction, not a deterministic minimal test or a measured failure rate over all compaction attempts.

The records establish the transport/fallback sequence and the failed turns. They do not establish whether the initiating cause is a proxy/VPN, network path, server/edge behavior, response encoding, or client implementation. There has been no controlled comparison using an alternate network route. Ordinary generation also failed, so this is not exclusively a compaction failure.

Expected behavior: preserve completed work and provide a usable retry/resume path after compaction transport failure; retain the initiating transport error and operation stage in diagnostics instead of exposing only the final generic decode error.

Related current reports: #44128 has the exact decode error on September 9, and #43517 describes WebSocket failures followed by HTTP fallback on runtime 0.153.4. #36059 also tracks the broader WebSocket-to-HTTPS failure sequence. These are symptom overlaps, not a claim of an identical root cause.

The evidence above was checked against local turn records and timestamped logs. Raw prompts, source code, local project paths, account details, and full logs are omitted. No diagnostic upload is implied by this comment.

Additional Windows reproduction with an in-app feedback ID:

I am seeing the same visible compaction error on Windows x64 across multiple long conversations. I cannot yet confirm whether the underlying cause is the same as this macOS report.

Environment:

Windows x64; exact OS build not collected.
Desktop app package version: 26.928.1915.0, obtained using Get-AppxPackage.
Bundled codex-cli: 0.159.0.

In-app feedback ID:
01a0bf58-efbe-7811-8197-adc1a8e9e884

Observed reproduction:

Open an existing long conversation in the desktop app.
Send a message, including a minimal prompt requesting only a short reply without file access or tool execution.
Automatic conversation optimization/compaction starts.
The UI displays "Reconnecting 2/2".
Compaction fails with the following error:

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

This has occurred in at least three different long conversations. Retrying in an affected conversation reproduces the failure.

Control test:
A newly created short conversation successfully answered:
请只回复“测试正常”，不要访问文件，也不要执行工具或命令。

The same prompt failed during compaction in an affected long conversation. This does not rule out a connectivity problem affecting compaction requests.

Relevant local history:
One affected conversation previously required local file recovery and a stored-path change. Its history can now be read and the conversation can be loaded. Other affected conversations did not undergo that recovery procedure but show the same compaction error.

Expected behavior:
Compaction should complete and allow the existing conversation to continue. A recoverable transport failure should not leave the conversation repeatedly blocked at compaction.

The conversations contain unpublished research. I am not attaching complete transcripts, databases, or manuscript files to this public comment. Please advise what minimal, redacted diagnostic information would help investigate this Windows reproduction.

Additional verified macOS recurrence on 2026-10-03 with codex-cli 0.160.0, including both mid-turn and pre-turn compaction. This adds current-version evidence and correlated retry timings to this existing report.

Environment

Local Codex task in the macOS desktop app; macOS 26.2 (25C56), arm64.
Bundled runtime: codex-cli 0.160.0, also recorded in the affected session metadata. This matches the latest non-prerelease GitHub release at the time of reporting.
The currently installed desktop host reports 26.930.31730; its exact build at the failure time was not independently captured.
Model recorded in the retry log spans: gpt-6-astra.
ChatGPT sign-in with the built-in OpenAI provider.

Observed workflow and impact

Work on an existing, long-running local coding task until automatic compaction is required.
Mid-turn remote compaction fails after its automatic retries, interrupting the task.
A subsequent attempt to continue the same task reaches pre-turn compaction and fails with the same error.

The work cannot reliably continue in the affected turn. Previously written project files remain available, and we were able to recover work from saved project notes in another conversation. This is an observational reproduction; I do not have a deterministic minimal transcript or a measured failure rate across all compaction attempts.

The terminal error is:

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

Correlated retries

Retries do happen. The retained codex_core::responses_retry records show two automatic retries for each compaction operation (max_retries=2), followed by terminal failure.

All times below are UTC on 2026-10-03:

Compaction stage	Operation start	Retry 1 logged	Retry 2 logged	Failed turn ended	Start-to-turn-end interval
MidTurn	13:05:52	13:07:58	13:10:02	13:12:11	~379 seconds
PreTurn	13:13:48	13:15:28	13:17:33	13:19:41	~353 seconds

These intervals run from the first compaction request to the enclosing turn ending; they are not measurements of server processing time.

Sanitized log excerpts, with context spans/identifiers omitted and timestamps normalized to second precision:

13:07:58Z WARN codex_core::responses_retry remote compaction v2 stream failed; retrying request after delay retries=1 max_retries=2 compact_error=stream disconnected before completion: Transport error: network error: error decoding response body
13:10:02Z WARN codex_core::responses_retry remote compaction v2 stream failed; retrying request after delay retries=2 max_retries=2 compact_error=stream disconnected before completion: Transport error: network error: error decoding response body
13:15:28Z WARN codex_core::responses_retry remote compaction v2 stream failed; retrying request after delay retries=1 max_retries=2 compact_error=stream disconnected before completion: Transport error: network error: error decoding response body
13:17:33Z WARN codex_core::responses_retry remote compaction v2 stream failed; retrying request after delay retries=2 max_retries=2 compact_error=stream disconnected before completion: Transport error: network error: error decoding response body

All six correlated requests logged HTTP 200 response status before the response-body stream failed. Receiving headers did not imply successful compaction. Request compression instrumentation reported approximately 1.84 MB before / 955 KB after compression, with local request compression taking only 3–5 ms. No request body was inspected or included here.

Mitigation and evidence limits

After these failures, we added project-scoped model_auto_compact_token_limit = 160000 and tool_output_token_limit = 6000 to reduce accumulated context/output size. A read-only strict-config check confirms those values can load; it does not establish hot reload in an already-running task or prove that the transport failure is fixed. We did not increase the actual context window or override the built-in provider as part of that mitigation.

A model_catalog_json configuration was present, and its file changed after the two failure intervals. Its current contents therefore should not be treated as the incident-time model/context settings.

The same response-body decode error also appears in ordinary generation logs on this host, so the underlying fault is not proven to be exclusive to compaction. We have not isolated client behavior, proxy/network path, or server/edge behavior with a controlled alternate-network test.

Requested recovery improvements

Preserve a usable continuation path after compaction retries are exhausted, with a clear bounded Retry / Resume from saved state option when safe.
Make the retry count, compaction stage, and final failure visible/actionable, so users can tell that retries already occurred.
Avoid repeatedly trapping continuation behind the same failing pre-turn compaction without a supported recovery route. Any fallback should preserve required instructions and disclose context loss; it should not silently discard history or retry indefinitely.

This is a sanitized public diagnostic summary. Project names/code, private prompts, transcripts, local account paths, credentials, and task/turn/request identifiers are omitted. No complete log archive or in-app feedback upload accompanies this comment.

I have a related Windows/corporate-network datapoint for this compaction failure.

On codex-cli 0.160.0, codex doctor showed the Responses WebSocket failing TLS with UnknownIssuer, while HTTPS remained usable. After switching to a custom provider with supports_websockets = false, the remote-compaction failure stopped occurring on that machine.

I posted the configuration and A/B results in #46489, which is a closer match for the TLS/WebSocket side of the problem.

This does not imply that every error decoding response body reported here has the same cause. It does show one case where forcing the Responses API to HTTPS is an effective workaround.

Additional verified recurrence on 2026-10-04 on macOS. An existing local coding conversation has two consecutive failed turns with the exact error tracked here:

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

Environment captured from the current installation and affected session metadata:

Running desktop host package: 26.930.21537, build 12776 (ChatGPT.app hosting the Codex local conversation; installed package version at reporting time).
Affected session runtime metadata: 0.159.0-alpha.12.1.
Model: gpt-6.1-sol, reasoning high.
Platform: macOS 26.5, arm64.

The latest continuation was a short question about project progress. It failed before normal response generation, during PreTurn auto-compaction with reason ContextLimit. Correlated local records show the following times, all UTC on 2026-10-04:

06:13:41: latest turn started.
06:15:50: remote compaction v2 stream failed; retry 1/2, response-body decode error.
06:17:59: remote compaction v2 stream failed; retry 2/2, same error.
06:20:08: Failed to run pre-sampling compact; turn failed.

The stored whole-turn duration is 387.472 seconds (~6 min 27 sec); this is not a measurement of server processing time. The preceding turn also failed with the same terminal error after having performed local project work. The conversation state is systemError. Another local conversation can read the affected conversation's records and execute tools, but that does not establish that the compaction network path is healthy.

Please investigate a supported recovery path for the existing conversation when compaction retries are exhausted, and make the operation stage/retry/failure details actionable. The work should be able to resume from preserved state rather than remain blocked behind repeated pre-turn compaction.

This is an observational recurrence, not a deterministic minimal reproduction. The root cause has not been isolated to client, backend, or network. This public report omits private prompts, project names/code, local paths, credentials, thread/turn identifiers, and raw logs. No new in-app diagnostic upload is implied.

Same-history image/no-image experiment on runtime 0.160.0

Following up on my earlier report: a small A/B experiment reproduced the original response-body decode error with historical screenshots retained, while removing only image blocks allowed two compactions to complete without retries. This is a useful mitigation lead, not proof of a general failure rate or a confirmed root cause.

Environment and method (October 6, 2026, UTC+8):

macOS 26.5, arm64; the actual running desktop runtime and experimental executable both report codex-cli 0.160.0.
Model: gpt-6.1-sol, high reasoning, built-in OpenAI provider, existing ChatGPT authentication.
Two agents tested separate arms derived from forks of the same affected conversation. The immutable history contained 72 model-visible image blocks.
A retained those blocks. B removed only typed image blocks, also removing their duplicate event-log representations. All 3,294 non-image strings, tool-call/return identifiers, and the canonical non-image Responses history were verified identical between arms.
Each trial started from the same original baseline in a fresh ephemeral fork, using thread/compact/start; subsequent trials did not compact an already-shortened result.
The desktop forks use paginated history references. To control the input, we expanded the same referenced source prefix into isolated copies, replaced only identity/pagination metadata, and loaded them through the runtime's path-fork API. The original conversation was not rewritten. These were separate app-server connections, not the desktop's existing connection.
Same host, account, model and global configuration; no network/proxy switch or provider/retry changes. The agents ran concurrently. model_auto_compact_token_limit was 219640, but these trials explicitly triggered manual compaction.

Observed results:

A, images retained: one compaction started. WebSocket attempts disconnected, followed by HTTPS fallback. HTTPS attempts then reproduced the exact original error:
```
stream disconnected before completion: Transport error: network error: error decoding response body
```
It was still unfinished after more than six minutes and was stopped at the user's request. No terminal completion/failure was received, so this is an interrupted trial with observed stream failures, not a measured terminal failure or confirmed timeout.
B, images removed: two independent trials completed successfully in 174.686 s and 201.063 s, each with contextCompaction item completion and turn/completed status completed, error=null. Neither had error/retry notifications or transport fallback. The third trial was stopped shortly after starting.

Selected retained A-arm event times (UTC, October 5; October 6 locally):

16:59:25  remote compaction v2 stream failed; retry 1/2;
          websocket closed by server before response.completed
16:59:38  retry 2/2; same WebSocket error
17:00:02  Falling back from WebSockets to HTTPS transport
17:02:14  retry 1/2; Transport error: network error: error decoding response body
17:04:32  retry 2/2; same response-body decode error

Interpretation / requested investigation: removing historical images is a promising workaround for this particular history. Two successful controls do not establish long-term stability, and the interrupted A arm cannot yield a terminal failure-rate comparison. Payload size, image handling, current network/edge behavior and their interaction remain possible explanations. The runtime also reports compaction_image_budget enabled, so the baseline count should not be treated as a measured server-side image count or request-token budget.

Please investigate image-bearing tool outputs in remote compaction, preserve actionable transport/encoding diagnostics, and consider a supported option to omit historical screenshots at compaction time while preserving text and tool-call integrity. Ordinary forks still inherit old images; merely forbidding new screenshots does not clean an existing history.

Raw transcripts, screenshots/Base64, project code, local paths, account details and thread/request identifiers are omitted from this public comment. The experiment was stopped; no additional trials or alternate-network tests are implied.

Navigation Menu

Repository navigation

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

Summary

Error

Environment

Steps to reproduce

Actual behavior

Expected behavior

Diagnostics

Related reports

Verified environment

Observed behavior

Impact and expected behavior

Observations from the affected task's turn records

Environment and limits of this report

Impact and requested investigation

Environment

Measured impact

Correlated compaction failure

Reproduction and evidence limits

Environment

Observed workflow and impact

Correlated retries

Mitigation and evidence limits

Requested recovery improvements

Same-history image/no-image experiment on runtime 0.160.0

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	pub(crate) fn should_retry_with_current_model(error: &CodexErr) -> bool {
	matches!(
	error.details(),
	CodexErrorDetails::InvalidRequest(_)
	\| CodexErrorDetails::UnexpectedStatus(_)
	\| CodexErrorDetails::ContextWindowExceeded
	\| CodexErrorDetails::UsageLimitReached(_)
	\| CodexErrorDetails::ServerOverloaded
	\| CodexErrorDetails::InternalServerError
	\| CodexErrorDetails::RetryLimit(_)
	)
	}

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

Description

Summary

Error

Environment

Steps to reproduce

Actual behavior

Expected behavior

Diagnostics

Related reports

Activity

github-actions commented on Aug 17, 2026

jdcodes1 commented on Aug 17, 2026

vforsh commented on Aug 27, 2026

Verified environment

Observed behavior

Impact and expected behavior

misiektoja commented on Sep 5, 2026

chenweizhong-web commented on Sep 7, 2026

sharpkorn1993-ui commented on Sep 7, 2026

Observations from the affected task's turn records

Environment and limits of this report

Impact and requested investigation

Yukioa2z commented on Sep 9, 2026

Environment

Measured impact

Correlated compaction failure

Reproduction and evidence limits

wuxinxing5201314 commented on Oct 1, 2026

wzxsph commented on Oct 3, 2026

Environment

Observed workflow and impact

Correlated retries

Mitigation and evidence limits

Requested recovery improvements

VonC commented on Oct 3, 2026

1129678576 commented on Oct 4, 2026

1129678576 commented on Oct 5, 2026

Same-history image/no-image experiment on runtime 0.160.0

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions