Context compression disconnects ~85% of the time; loses pre-compression reasoning and diverts to unrelated plans

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

• #30958
• #30596
• #31099
• #30859
• #31351

Powered by Codex Action

Recently the codex-team seems to make a lot of changes to the Codex App, (which I bless and praise)
but a lot of users seems to have issues with it (which is fair - we should moderanize things)

the codex app is massive a whopping 1.6gb -- almost as big as Android or IOS --- and a lot of great software , that was made 20 years ago - is perfectally good and used today (modernizing , and refining and adding --- keeping inmind people who are customers know how to use it too)

second my point is
I ask you a request

can this be replicated on the codex-cli - codex-ide (within the Codex extension , in your VS CODE), please report if you are able to replicate it there, this seems to be a consistant thing
I personally dont recomend you using x-high or high - because it seems to get people more auto-compacted -- which actually degrades the usage expirences (and overall its a bit slower, despite that I cant really tell the different when i try it at all)
to better rootcause if its something with the App , but maybe its a core issue in the app - or something server sided changed
(and if its within a Chat you resumed ,,, or does it get fixed if you start a new "chat/thread" i suspiect this being an issue where people give it 90 prompts ) [b. a project size issue -- maybe it insert some kind of text, it views like "instruction" and then (thinks and thinks and thinks) causing it to (compact and compact and compact ) ]

(Unrelated ideas about compacting - and if it has to do with too much thinking resulting in higher compaction time -- and issues overall)
I start with what I think for last, I think maybe its something internal with the core functions of the app , or something server sided has changed( in prepartion of launching 5.6 on the roadmap)

I cant wait for 5.6 - which seems to be just as good as 5.5 - and the smaller models deliver - what we just happy as of now- and some of us dont want more than we already got as its a very refined product
(I recently tried Claude Sonnet 5 , its really bad --- but honestly when I use 5.4mini its still a better model for me -- and I manage 8 big projects -- I argue 5.4 is a bit smarter than the non-mini but still) (that being said what Anthropic does they try to plan within their reasoning and it doesnt skips things in a sense - so I think thats what their relization was --- its likely in their post-training that they are able to score high) (its like a 10 bullet points , but actually have plans --- not write a 9000 ai slop doesnt doesnt have soul or context --- codex has a soul , codex doesnt talk more than it needs --- perhaps its so good - some of the benchmark people use it for arent too good---- but still its not perfect per say ---- claude-code sonnet 5 is kindda stupid it talks a lot and doesnt meet its goals --- I personally even like Codex generated code much more than ones made by Claude Code , much more pleasing much more clean -- more truthful to real terms you and I would have use)

I guess as a consumer, I think its very nice being able to use everything-- xhigh-high , I think the rebranding to things like ultra or whatever --- but I think people still going to want to use it... as things stands out now open source models are next to unusable for certain coding tasks , if you wanted for example to make sense out of a .exe analyze it , what it does what it do - which is an insanely hard task for the bigger models (understanding binaries, executing the right tools in your debugger) you know in a sense us people - dont need to take this massive context window -- we are just better in terms of tool usage --- think of debugging or reversing some insanely big binary -- thats some very tiresom for a human even a multimonth project for a group of people
! ! !
yet you assume if you had something like what we know as LLM today - this would be a bit easier -- executing the various functions in already known softwares --- as things stands out - it figures a different pathway to achieve things -- I kindda wish it could compress and generalize just like humans -- the compaction thing is one of the biggest issues the they AI LABS now face, we compact faster and better -- even if we need 8 hours of sleep and do it just before we sleep

<img width="1024" height="576" alt="Image" src="https://github.com/user-attachments/assets/38e62bb6-9ba6-4381-b22c-fbc0d12277a7" />

Reproducing this on two unrelated Codex Desktop tasks at the same time.

Environment

• Codex App: 26.715.10079.0
• OS: Windows 11 x64 (10.0.26200)
• Model: gpt-5.6-sol, reasoning high
• Summary mode: auto
• Observed: 2026-07-23

Exact error

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

Correlated multi-thread evidence

Two tasks in different local workspaces both ended with systemError. Their persisted rollout events recorded six consecutive task_complete failures per thread with the exact error above and codex_error_info: "other".

1. Thread 019f8d75-1350-78e3-b749-3e16392fda1d

• first failure: 2026-07-23T06:32:18.734Z
• last failure: 2026-07-23T06:55:54.043Z
• matching failures: 6

1. Thread 019f8d9a-8f4a-72b1-91f3-77872316b5ab

• first failure: 2026-07-23T06:29:51.796Z
• last failure: 2026-07-23T06:55:55.483Z
• matching failures: 6

The later retry failures were closely synchronized across the two tasks (around 06:37, 06:43, 06:49, 06:53, and 06:55 UTC). This makes a repository-specific prompt or a single corrupted thread less likely; it looks like a shared app/service transport or remote-compaction path failure.

This is also notable because the maintainer update in #15046 said the newer local-compaction flow should eliminate remote-compaction errors. The current App build is still surfacing Error running remote compact task and terminalizing both tasks after repeated retries.

Expected behavior

A transient compact-stream decode failure should recover with bounded retry/backoff or a safe fallback. It should not repeatedly terminalize multiple independent tasks as systemError.

The two thread IDs are included above for correlation. I can provide additional sanitized rollout timing metadata if needed.

I thikn this ticket shoukd be closed. ak this point of time.

Still reproducible in Codex App 26.803.41515 (released Aug 7, 2026) on macOS with a ChatGPT Pro subscription, using 5.6 Sol Ultra in a long-running /goal task.

After approximately 56 minutes, automatic context compaction was triggered and the task stalled at about 38% progress. The app showed:

Context automatically compacted
Reconnecting 2/2
Error running remote compact task: stream disconnected before completion: Transport error: network error: error decoding response body

The task did not recover or continue after the compaction failure.

Feedback ID: 019fe9fa-4525-70a0-88e3-de39c6dd6ff2

Expected behavior: automatic compaction should retry or fall back safely without stalling the active task.

Still reproducible in Codex App 26.803.41515 (released Aug 7, 2026) on macOS with a ChatGPT Pro subscription, using 5.6 Sol Ultra in a long-running /goal task. After approximately 56 minutes, automatic context compaction was triggered and the task stalled at about 38% progress. The app showed: `` Context automatically compacted Reconnecting 2/2 Error running remote compact task: stream disconnected before completion: Transport error: network error: error decoding response body ` The task did not recover or continue after the compaction failure. Feedback ID: 019fe9fa-4525-70a0-88e3-de39c6dd6ff2` Expected behavior: automatic compaction should retry or fall back safely without stalling the active task.

Just make a new thread. the New-Chat and New-Thread changes very often. best just to make a new thread from time to time /new

Repeated compact disconnects are relevant to codex-rescue, but Rescue does not fix the remote compaction transport itself. I’m field-testing whether an affected local rollout remains structurally recoverable after the failed compact or actually ends in an interrupted persisted state.

If you still have one affected local session, could you start with the read-only path?

pipx install codex-rescue
codex-rescue sessions
codex-rescue doctor --latest

If doctor identifies a genuinely unfinished state and you need recovery, the optional path is salvage --latest --fork followed by verify <rescue-id>. Otherwise a healthy/no-damage result is useful too.

Please share only sanitized diagnostics, versions and exit codes—no raw rollout/SQLite, prompts, credentials, or private paths. Repo: https://github.com/shleder/codex-rescue