Windows Codex Desktop: consecutive remote compaction decode failures prevent continuing a local task #50843

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   contextIssues related to context management (including compaction)Issues related to context management (including compaction)

   connectivityIssues involving networking or endpoint connectivity problems (disconnections)Issues involving networking or endpoint connectivity problems (disconnections)

   on Oct 4, 2026
2. github-actions commented on Oct 4, 2026

   

   github-actionsbot

   on Oct 4, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Windows desktop and CLI repeatedly disconnect HTTP/SSE streams with "error decoding response body" even with WebSockets disabled #49540

   Powered by Codex Action
3. EdwinZDZ commented on Oct 6, 2026

   

   EdwinZDZ

   on Oct 6, 2026 – with ChatGPT Codex Connector

   More actions

   I can reproduce a very similar failure on macOS, and I have a bit more context-state data that may help narrow this down.

   Environment

   • Codex Desktop on macOS.
   • The separately installed CLI on the same machine reports codex-cli 0.159.0.
   • Desktop build number was not captured.
   • No custom values were present for:
     • remote_compaction_v2
     • model_context_window
     • model_auto_compact_token_limit
     • model_post_turn_compact_threshold_percent

   What happened

   Two separate long-running Codex sessions independently became unusable with the exact same error:

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

   In both sessions, the failure happened when context usage was almost exactly ~95%:

   • Session A: 245,772 / 258,400 tokens = ~95.11%
   • Session B: 245,117 / 258,400 tokens = ~94.86%

   After the first compact failure, sending a normal continuation caused the session to hit compaction again and fail again, so the existing thread could no longer make progress.

   Local session-file checks

   I inspected the rollout JSONL files rather than assuming corruption:

   • bad_json = 0 for both affected sessions.
   • image_lines = 0; there are no embedded input_image / data:image payloads.
   • Mature rollout sizes were only about 4.14 MB and 3.59 MB.
   • Largest individual lines were about 617.7 KB and 182.2 KB respectively, not giant multi-MB/GB payloads.
   • So this does not look like the previously reported “session JSONL exploded because of image/base64 payloads” failure mode.

   Why this seems notable

   The two independent sessions failing at nearly the same ~95% context level strongly suggests the auto-compaction boundary is involved. Once remote compaction fails, the session appears trapped: every continuation still requires compaction, but there is no successful retry/fallback path that restores usability.

   Expected behavior would be one of:

   1. remote compaction retries successfully,
   2. Codex falls back to a safe local compaction path, or
   3. the thread can otherwise recover without forcing the user to abandon the session.

   I have intentionally not edited the JSONL files or forced a migration to a new thread, so the affected sessions remain available for further diagnostics if maintainers need specific sanitized fields or logs.
4. damaokuer commented on Oct 8, 2026

   

   damaokuer

   on Oct 8, 2026

   More actions

   Windows Codex Desktop 26.1007.11041

   Normal short conversations work consistently.

   All models fail when context compaction starts.

   Core logs:
   remote compaction v2 stream failed
   stream closed before response.completed
   timeout
   Failed to run pre-sampling compact

   The issue reproduces across multiple long threads.
5. a-day-old-bagel commented on Oct 8, 2026

   

   a-day-old-bagel

   on Oct 8, 2026

   More actions

   I am seeing this same failure mode repeatedly on current ChatGPT/Codex Desktop for Windows, and I can now reproduce it across independent sessions.

   The important additional observation is that this is not confined to one corrupted or unusually large thread.

   Reproduction/history:

   • A long-running Codex session works normally until context compaction becomes necessary.
   • Automatic compaction then fails, initially with errors such as:
     stream disconnected before completion
     followed by Reconnecting 1/5 through 5/5.
   • At other times the same failure instead reports:
     We’re currently experiencing high demand, which may cause temporary errors.
   • Once this happens, the thread becomes effectively unusable: every new turn immediately attempts compaction again and fails.
   • Running /compact manually fails the same way.
   • Switching between Standard and Fast does not resolve it.
   • Fully restarting the desktop app does not resolve the affected session.
   • Forking the thread does not help, because the fork inherits enough context to immediately trigger the same failed compaction.
   • I created a fresh replacement session, recovered the previous task from local rollout/session data, and continued working. That entirely new session subsequently reached its own compaction point and failed in the same way.
   • I then repeated the replacement/handoff strategy. Another session stalled at only about 65% displayed context usage, at less than 600k tokens.
   • Because of this I am currently forced to hand active work to a new session manually at approximately 50% context usage to avoid losing the session when compaction fires.

   Local configuration/data checks:

   • %USERPROFILE%\.codex\config.toml does NOT contain remote_compaction_v2 = false.
   • The relevant rollout JSONL files under %USERPROFILE%\.codex\sessions\... are all under approximately 10 MB, so this does not appear to be an extreme hundreds-of-MB rollout/image-payload case.
   • Increasing the configured context window and restarting the app does not make an already affected session recover.
   • Normal work can function correctly for a substantial period before compaction is required, which makes a general local network failure unlikely.

   This has now reproduced across multiple newly created sessions. The common trigger is the context-management/compaction boundary, not a particular conversation.

   Expected behavior:
   Transient failure of compaction should not permanently strand the thread. Ideally Codex should retry/fall back to a local or normal-turn compaction path and allow the conversation to continue.

   Actual behavior:
   A failed compaction effectively bricks the conversation, forcing me to reconstruct the task in a fresh session. The replacement eventually hits the same failure.

   This is particularly costly because the repeated recovery sessions consume paid usage and require re-reading/reconstructing substantial local task context.

   Environment:

   • Windows x64
   • ChatGPT/Codex Desktop
   • Sol 6.1
   • Reproduced in both Standard and Fast speed modes
   • App version: [insert version shown in About Codex]

   I can provide additional redacted diagnostics/session IDs if useful, but I do not want to publicly upload complete rollout JSONL files because they contain private prompts, local paths, tool output, and project information.
6. v-49 commented on Oct 9, 2026

   

   v-49

   on Oct 9, 2026

   Last edited by v-49

   More actions

   Just to confirm — did you change the context length (or max context window) in this version? the config
   i wright ： model_context_window = 872000
   model_auto_compact_token_limit = 697600 now i delete it
7. v-49 commented on Oct 9, 2026

   

   v-49

   on Oct 9, 2026

   More actions

   I can reproduce a very similar failure on macOS, and I have a bit more context-state data that may help narrow this down.我在 macOS 上也能重现类似的故障现象。此外，我还掌握了一些额外的上下文数据，这些数据或许有助于进一步确定故障的原因。

   Environment

   • Codex Desktop on macOS.macOS 系统上的 Codex Desktop 版本。
   • The separately installed CLI on the same machine reports codex-cli 0.159.0.在同一台机器上单独安装的 CLI 工具也报告了 codex-cli 0.159.0 的值。
   • Desktop build number was not captured.桌面版的构建编号未被记录下来。
   • No custom values were present for:
     以下各项没有自定义值：
     • remote_compaction_v2
     • model_context_window
     • model_auto_compact_token_limit
     • model_post_turn_compact_threshold_percent

   What happened

   Two separate long-running Codex sessions independently became unusable with the exact same error:两次独立的、持续时间较长的 Codex 会话都因为完全相同的错误而无法正常使用：

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

   In both sessions, the failure happened when context usage was almost exactly ~95%:在这两次测试中，当上下文使用率几乎达到 1001#95%时，系统都出现了故障：

   • Session A: 245,772 / 258,400 tokens = ~95.11%会议 A： 245,772 / 258,400 个代币 = ~，占比 95.11%
   • Session B: 245,117 / 258,400 tokens = ~94.86%B 组： 245,117 / 258,400 个代币 = ~94.86%

   After the first compact failure, sending a normal continuation caused the session to hit compaction again and fail again, so the existing thread could no longer make progress.在第一次压缩失败后，如果试图继续进行正常的操作，会导致会话再次进入压缩状态并再次失败。这样一来，现有的线程就再也无法继续执行下去了。

   Local session-file checks

   I inspected the rollout JSONL files rather than assuming corruption:我没有想当然地认为这些 JSONL 文件已经损坏，而是亲自检查了这些文件的内容。

   • bad_json = 0 for both affected sessions. bad_json = 0 适用于所有受影响的会话。
   • image_lines = 0; there are no embedded input_image / data:image payloads. image_lines = 0 ；其中不包含任何 input_image / data:image 类型的有效载荷。
   • Mature rollout sizes were only about 4.14 MB and 3.59 MB.在正式发布时，其大小分别仅为 4.14 MB 和 3.59 MB 而已。
   • Largest individual lines were about 617.7 KB and 182.2 KB respectively, not giant multi-MB/GB payloads.最大的单个数据块大小分别为 617.7 KB 和 182.2 KB，并不属于那种高达数 MB/GB 的巨大数据块。
   • So this does not look like the previously reported “session JSONL exploded because of image/base64 payloads” failure mode.因此，这并不像是之前所报告的“由于图像/Base64 编码数据导致 JSONL 格式出错”这种故障模式。

   Why this seems notable

   The two independent sessions failing at nearly the same ~95% context level strongly suggests the auto-compaction boundary is involved. Once remote compaction fails, the session appears trapped: every continuation still requires compaction, but there is no successful retry/fallback path that restores usability.这两次独立的会话都在几乎相同的 1001#95%的错误率下失败了，这一现象强烈表明，自动压缩机制出现了问题。一旦远程压缩失败，该会话就会陷入僵局：无论怎样尝试继续操作，都需要再次进行压缩处理，但却没有有效的补救措施来恢复会话的可用性。

   Expected behavior would be one of:预期行为应该是以下几种之一：

   1. remote compaction retries successfully,远程压缩重试成功。
   2. Codex falls back to a safe local compaction path, orCodex 会退回到一个安全的本地存储路径上。/ 或者/
   3. the thread can otherwise recover without forcing the user to abandon the session.否则，该线程可以自行恢复，而无需强制用户退出会话。

   I have intentionally not edited the JSONL files or forced a migration to a new thread, so the affected sessions remain available for further diagnostics if maintainers need specific sanitized fields or logs.我故意没有编辑这些 JSONL 文件，也没有强制将数据迁移到新的线程中。这样一来，受影响的会话数据仍然可以供后续分析使用。如果维护人员需要某些经过处理的字段或日志，这些数据依然可用。

   Is this possibly related to the project in Codex?

   For example, could it be caused by too many conversations accumulating within a single project, leading to context confusion?

   Would creating a separate/independent project folder resolve this issue?
8. v-49 commented on Oct 9, 2026

   

   v-49

   on Oct 9, 2026

   More actions

   I am seeing this same failure mode repeatedly on current ChatGPT/Codex Desktop for Windows, and I can now reproduce it across independent sessions.我在当前版本的 ChatGPT/Codex Desktop for Windows 上反复遇到这种故障现象。现在，我可以在不同的会话中重复重现这一故障。

   The important additional observation is that this is not confined to one corrupted or unusually large thread.另一个重要的观察结果是：这种情况并非只发生在某个出错或规模异常大的线程上。

   Reproduction/history:  繁殖/历史记录：

   • A long-running Codex session works normally until context compaction becomes necessary.在需要压缩上下文信息之前，长期运行的 Codex 会正常运行。
   • Automatic compaction then fails, initially with errors such as:自动压实过程会失败，最初会出现诸如以下的错误：
     stream disconnected before completion
     followed by Reconnecting 1/5 through 5/5.接着是 Reconnecting 1/5 到 5/5 。
   • At other times the same failure instead reports:在其他情况下，同样的故障会报告为：
     We’re currently experiencing high demand, which may cause temporary errors.
   • Once this happens, the thread becomes effectively unusable: every new turn immediately attempts compaction again and fails.一旦出现这种情况，该线程就实际上无法再使用了：每次尝试进行新的操作时，都会再次尝试压缩数据，但都会以失败告终。
   • Running /compact manually fails the same way.手动运行 /compact 也会以同样的方式失败。
   • Switching between Standard and Fast does not resolve it.在“标准模式”和“快速模式”之间切换并不能解决这个问题。
   • Fully restarting the desktop app does not resolve the affected session.完全重启桌面应用程序也无法解决该问题。
   • Forking the thread does not help, because the fork inherits enough context to immediately trigger the same failed compaction.分叉该线程没有任何帮助，因为分叉后的线程会继承足够的上下文信息，从而再次引发同样的压缩失败问题。
   • I created a fresh replacement session, recovered the previous task from local rollout/session data, and continued working. That entirely new session subsequently reached its own compaction point and failed in the same way.我创建了一个新的会话，从本地数据中恢复了之前的任务内容，然后继续工作。不过，这个新会话也很快就达到了其自身的“压缩点”，最终也出现了同样的故障。
   • I then repeated the replacement/handoff strategy. Another session stalled at only about 65% displayed context usage, at less than 600k tokens.然后，我再次采用了这种替换/交接策略。另一次测试中，上下文使用率仅达到了 65%左右，使用的标记数量还不到 60 万。
   • Because of this I am currently forced to hand active work to a new session manually at approximately 50% context usage to avoid losing the session when compaction fires.因此，为了避免在数据压缩过程中丢失会话信息，我目前不得不在会话使用率达到约 50%时，手动将正在进行中的工作保存到新的会话中。

   Local configuration/data checks:本地配置/数据检查：

   • %USERPROFILE%\.codex\config.toml does NOT contain remote_compaction_v2 = false. %USERPROFILE%\.codex\config.toml 不包含 remote_compaction_v2 = false 。
   • The relevant rollout JSONL files under %USERPROFILE%\.codex\sessions\... are all under approximately 10 MB, so this does not appear to be an extreme hundreds-of-MB rollout/image-payload case. %USERPROFILE%\.codex\sessions\... 下的相关 JSONL 文件大小都不到 10MB，因此这显然不属于那种需要传输数百 MB 数据的场景。
   • Increasing the configured context window and restarting the app does not make an already affected session recover.增加配置的上下文窗口大小或重新启动应用程序，都无法让那些已经受到影响的会话恢复正常。
   • Normal work can function correctly for a substantial period before compaction is required, which makes a general local network failure unlikely.在需要实施压缩处理之前，系统可以正常运行相当长的时间。因此，整个局域网出现故障的可能性很低。

   This has now reproduced across multiple newly created sessions. The common trigger is the context-management/compaction boundary, not a particular conversation.这一现象在多个新创建的会话中都出现了。其触发因素通常是上下文管理/数据压缩的临界点，而非具体的对话内容。

   Expected behavior:  预期行为： Transient failure of compaction should not permanently strand the thread. Ideally Codex should retry/fall back to a local or normal-turn compaction path and allow the conversation to continue.如果压缩过程出现临时性故障，也不应导致整个对话过程被永久中断。理想情况下，Codex 应尝试重新使用本地或正常的压缩路径来继续处理对话。

   Actual behavior:  实际行为： A failed compaction effectively bricks the conversation, forcing me to reconstruct the task in a fresh session. The replacement eventually hits the same failure.如果压缩失败，那么整个对话过程就会陷入停滞，我不得不在新的会话中重新开始这项任务。而替换后的方案最终也会遭遇同样的失败。

   This is particularly costly because the repeated recovery sessions consume paid usage and require re-reading/reconstructing substantial local task context.这一过程的成本相当高，因为反复的恢复操作会消耗付费流量，同时还需要重新读取或重建大量的本地任务相关数据。

   Environment:  环境：

   • Windows x64  Windows x64 版
   • ChatGPT/Codex Desktop  ChatGPT/Codex 桌面版
   • Sol 6.1  第 6.1 天
   • Reproduced in both Standard and Fast speed modes以标准模式和快速模式两种方式均可再现。
   • App version: [insert version shown in About Codex]应用程序版本：[请填写“关于 Codex”页面中显示的版本号]

   I can provide additional redacted diagnostics/session IDs if useful, but I do not want to publicly upload complete rollout JSONL files because they contain private prompts, local paths, tool output, and project information.如果需要的话，我可以提供经过处理的诊断信息/会话 ID。不过，我不想公开上传完整的 JSONL 文件，因为这些文件包含敏感信息，比如私有提示语、本地路径、工具输出以及项目相关数据。

   Is this possibly related to the project in Codex?

   For example, could it be caused by too many conversations accumulating within a single project, leading to context confusion?

   Would creating a separate/independent project folder resolve this issue?