CLI remote compaction repeatedly fails and leaves resumed threads without task continuity

[darkhipo]

What version of Codex CLI is running?

codex-cli 0.130.0

What subscription do you have?

Pro

Which model were you using?

Mostly gpt-5.5 with high / xhigh reasoning. Older log history also shows the same remote compact failure shape with gpt-5.4.

What platform is your computer?

macOS 26.3.1 (a), Darwin 25.3.0, arm64, MacBook Air.

What issue are you seeing?

Remote context compaction repeatedly fails in the CLI with:

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

This has happened continuously across several days and multiple long-lived CLI sessions. The main user-visible problem is not only the error itself: once it happens, the session can become effectively wedged. codex resume <thread_id> may start a responsive-looking session, but it often does not naturally resume the active task state. I have had to manually back up and rewrite local rollout JSONL files with task-state summaries to recover work.

Affected thread IDs observed locally

These are local thread/session IDs from the Codex rollout/log files:

• 019e0fab-3f43-7c61-b34a-5a37373f5c9b
• 019e132c-0d1f-7700-addc-396fc383089f
• dfb1b3b9-e2ba-44be-96ed-d79f18a3e355

The local log also shows the same compact failure pattern on older threads:

• 019d8749-0408-7013-adfa-b0bbe5813e2e
• 019dfd8b-84b7-70a2-b8cc-6602a3b870cc

Frequency / scale from local logs

I counted structured codex_core::compact_remote: remote compaction failed entries in ~/.codex/log/codex-tui.log.

Sanitized counts:

remote compact failures: 50+ genuine failures in the log
by_thread:
  019d8749-0408-7013-adfa-b0bbe5813e2e: 10
  019dfd8b-84b7-70a2-b8cc-6602a3b870cc: 17
  019e0fab-3f43-7c61-b34a-5a37373f5c9b: 15
  019e132c-0d1f-7700-addc-396fc383089f: 8

Recent examples, copied from structured log fields and with transcript content omitted:

2026-05-11T21:23:52Z thread=019e132c-0d1f-7700-addc-396fc383089f turn=019e18ce-aa4f-7823-8f4a-6a49db51a810 model=gpt-5.5 effort=xhigh last_api_response_total_tokens=213012 all_history_items_model_visible_bytes=938543 added_tokens_since_success=863 added_bytes_since_success=3450 context_window=258400 failing_compaction_request_model_visible_bytes=950257 error="stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)"

2026-05-12T00:39:33Z thread=019e132c-0d1f-7700-addc-396fc383089f turn=019e1941-69fc-7211-8753-51875647b929 model=gpt-5.5 effort=high last_api_response_total_tokens=224168 all_history_items_model_visible_bytes=958884 added_tokens_since_success=602 added_bytes_since_success=2408 context_window=258400 failing_compaction_request_model_visible_bytes=980231 same error

2026-05-12T05:50:08Z thread=019e132c-0d1f-7700-addc-396fc383089f turn=019e1a73-50db-7931-a7c3-b47ca69b703d model=gpt-5.5 effort=high last_api_response_total_tokens=232155 all_history_items_model_visible_bytes=952169 added_tokens_since_success=2213 added_bytes_since_success=8849 context_window=258400 failing_compaction_request_model_visible_bytes=973516 same error

2026-05-12T06:45:03Z thread=019e132c-0d1f-7700-addc-396fc383089f turn=019e1ae7-38fb-7141-935e-a7f1f875c2dc model=gpt-5.5 effort=high last_api_response_total_tokens=238502 all_history_items_model_visible_bytes=901340 added_tokens_since_success=7629 added_bytes_since_success=30516 context_window=258400 failing_compaction_request_model_visible_bytes=922687 same error

2026-05-12T14:24:11Z thread=019e132c-0d1f-7700-addc-396fc383089f turn=019e1c5d-d2a8-7290-aff0-ff4323e6c01a model=gpt-5.5 effort=high last_api_response_total_tokens=223323 all_history_items_model_visible_bytes=952328 added_tokens_since_success=3616 added_bytes_since_success=14461 context_window=258400 failing_compaction_request_model_visible_bytes=973675 same error

2026-05-12T14:31:23Z thread=019e132c-0d1f-7700-addc-396fc383089f turn=019e1c94-d56f-7060-a971-b63897269a95 model=gpt-5.5 effort=high last_api_response_total_tokens=223323 all_history_items_model_visible_bytes=952328 added_tokens_since_success=3616 added_bytes_since_success=14461 context_window=258400 failing_compaction_request_model_visible_bytes=973675 same error

Older thread example:

2026-05-10T18:24:57Z thread=019e0fab-3f43-7c61-b34a-5a37373f5c9b turn=019e131d-f7b8-7db0-985d-344b6e4ddea8 model=gpt-5.5 effort=xhigh last_api_response_total_tokens=226340 all_history_items_model_visible_bytes=998107 added_tokens_since_success=2130 added_bytes_since_success=8519 context_window=258400 failing_compaction_request_model_visible_bytes=1009821 same error

Across the failures I checked, the failing compaction request visible byte size is usually about ~0.92 MB to ~1.02 MB and the model context window is logged as 258400 tokens.

Local rollout/session state

The failures are associated with long-lived sessions whose rollout JSONL files become large and have many prior compactions. Examples:

019e0fab... backup rollout: ~6.35 MB, 3196 lines, 40 task_started, 21 task_complete, 17 turn_aborted, 3 compacted

019e132c... backup rollout before manual recovery: ~37.19 MB, 18943 lines, 54 task_started, 53 task_complete, 1 turn_aborted, 21 compacted

019e132c... later backup after partial local recovery: ~1.41 MB, 326 lines, 5 task_started, 4 task_complete, 1 turn_aborted, 1 compacted

019e132c... task-state backup before final manual recovery: ~3.26 MB, 1507 lines, 14 task_started, 14 task_complete, 2 compacted

Repro pattern

This is the pattern I can reproduce operationally:

1. Work in a long-lived Codex CLI session for many turns until automatic context compaction is needed.
2. Continue working after prior compactions have already occurred.
3. Eventually the CLI logs codex_core::compact_remote: remote compaction failed with the /backend-api/codex/responses/compact stream disconnected error.
4. The visible UI shows the remote compact error and asks to continue with codex resume <thread_id>.
5. Resuming may open a session that accepts input, but the session is not reliably continuing the active task. In practice I had to manually rewrite the local rollout history with compacted task-state summaries to finish the work.

Actual behavior

• Remote compaction fails repeatedly with stream disconnected before completion.
• The same thread can fail again shortly after a manual local recovery.
• The error can strand active tasks. A resumed thread can be responsive but not have the correct task continuity.
• Manual local compaction/rewrite of rollout JSONL can make the same thread ID usable again, which suggests the local resume mechanism can work if the history sent to the backend is small and task-state preserving.

Expected behavior

• Remote compaction should complete reliably, or retry/fallback locally enough that the thread remains usable.
• If remote compaction fails, codex resume <thread_id> should preserve the active task state or provide a safe recovery path.
• Ideally the CLI should expose a supported local/task-state compaction fallback instead of requiring manual rollout JSONL surgery.

Workaround used locally

I backed up the rollout JSONL, then rewrote the active rollout to keep the original session_meta but replace the history with a compacted task-state packet. A generic liveness probe was not enough; I had to use a continuity probe asking the resumed session to state the active task, last verified result, next action, and key ids/files.

That allowed one stranded task to finish and commit successfully, but it is not a safe or reasonable user workaround.

Related existing issues

This looks related to several existing issues, including #20931, #22031, #18450, #19558, and #21343. I opened this separately because the local log data here includes repeated failures over multiple days, multiple thread IDs, structured compact request sizes, and the task-continuity failure mode after resume.

[InfiniteRandomVariable]

Related to #22309