›_ Codex Issues
Codex Issues / #22335

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

Resolved 💬 9 comments Opened May 12, 2026 by darkhipo Closed Jun 29, 2026
💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

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.

View original on GitHub ↗

9 Comments

InfiniteRandomVariable · 2 months ago

Related to https://github.com/openai/codex/issues/22309

darkhipo · 1 month ago

Update from June 11, 2026: this is still reproducing for me on a newer CLI, and the main pain remains task-continuity loss after the compact failure.

Environment now:

codex-cli 0.139.0
npm global package: @openai/codex@0.139.0
binary: /opt/homebrew/bin/codex
platform: macOS / Darwin 25.5.0 arm64
model observed in affected wrapper session: gpt-5.5 high

User-visible failure that recurred today:

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

■ Conversation interrupted - tell the model what to do differently. Something went wrong? Hit `/feedback` to report the issue.
To continue this session, run codex resume 019e132c-0d1f-7700-addc-396fc383089f

After sending another prompt to proceed, the same remote compact error printed again. This is the operational wedge: codex resume <thread_id> may produce a responsive surface, but it does not reliably preserve the active task state. I ended up using a separate safety/recovery session again, which creates its own context and can drift away from the original task.

Sanitized local rollout/session evidence, without uploading raw transcripts:

Active thread dfb1b3b9-e2ba-44be-96ed-d79f18a3e355
  rollout size: 52,403,457 bytes
  lines: 31,457
  task_started: 62
  task_complete: 62
  turn_aborted: 0
  top-level compacted records: 37
  latest top-level compacted records on 2026-06-11:
    06:42:35Z, 07:19:50Z, 07:45:23Z, 08:22:54Z,
    09:05:36Z, 09:31:36Z, 10:10:35Z, 11:07:14Z,
    12:01:15Z, 12:20:33Z, 12:52:38Z, 13:28:02Z
  Those latest 12 compacted JSONL records contain all three markers:
    "Error running remote compact task"
    "https://chatgpt.com/backend-api/codex/responses/compact"
    "stream disconnected before completion"

Older primary thread 019e132c-0d1f-7700-addc-396fc383089f
  current rollout size: 176,997,968 bytes
  lines: 113,655
  task_started: 402
  task_complete: 401
  turn_aborted: 1
  top-level compacted records: 111
  recent compacted records continue through 2026-06-11T06:00:18Z and include the backend URL + stream-disconnect markers in their replacement history.

Two additional observations that may help narrow this down:

  1. The failure keeps recurring after manual recovery/backups, so it is not a single corrupted one-off rollout.
  2. The compacted JSONL records themselves can become large. In the current active thread, recent compacted records are roughly 96k-107k chars each; in the older primary thread, recent compacted records are roughly 250k-281k chars each.

What would help users most is a supported recovery path when remote compaction fails: either retry/fallback local compaction, or a resume mode that preserves a compact task-state packet instead of requiring manual rollout surgery / separate safety sessions.

darkhipo · 1 month ago

June 12, 2026 update: this reproduced again after the June 11 report, and it now affected both the older primary session and the dedicated safety/recovery session.

Current environment:

codex-cli 0.139.0
binary: /opt/homebrew/bin/codex
config model: gpt-5.5
config reasoning effort: xhigh (affected wrapper logs also show high)
platform: macOS 26.5 / Darwin 25.5.0 arm64
hardware: Apple M1, 8 GB RAM
project cwd: /Users/dmitri.arkhipov/MultiAgency

User-visible recurrence from local structured logs at 2026-06-12T00:15:49Z and again at 2026-06-12T00:16:32Z:

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

■ Conversation interrupted - tell the model what to do differently. Something went wrong? Hit `/feedback` to report the issue.
To continue this session, run codex resume 019e132c-0d1f-7700-addc-396fc383089f

Operational impact this time:

  • The failed resume target was the old primary session: 019e132c-0d1f-7700-addc-396fc383089f.
  • A separate safety session had to take over because giving the resumed primary a task would stall/wedge again.
  • The key product failure is still not just the compact error. It is that recovery moves work into a different thread, so the latest active task is not naturally resumed and has to be reconstructed manually.

Sanitized local rollout evidence now:

primary session: 019e132c-0d1f-7700-addc-396fc383089f
  rollout path: ~/.codex/sessions/2026/05/10/rollout-2026-05-10T11-35-14-019e132c-0d1f-7700-addc-396fc383089f.jsonl
  bytes: 196,965,966
  lines: 127,660
  first event: 2026-05-10T18:35:18.478Z
  last event: 2026-06-12T06:56:44.150Z
  compact marker mentions: 128
  interruption/stream-disconnect marker mentions: 346
  sha256 prefix: 9c43990b025cb0ab

safety/recovery session: dfb1b3b9-e2ba-44be-96ed-d79f18a3e355
  rollout path: ~/.codex/sessions/2026/05/10/rollout-2026-05-10T18-35-15-dfb1b3b9-e2ba-44be-96ed-d79f18a3e355.jsonl
  bytes: 97,228,803
  lines: 63,493
  first event: 2026-05-10T18:35:15.592Z
  last event: 2026-06-12T08:32:23.121Z
  compact marker mentions: 109
  interruption/stream-disconnect marker mentions: 112
  sha256 prefix: 9c251e0f95d961fe

Structured token/compact-adjacent log samples around the latest primary-session failure show the session approaching the auto-compact threshold:

2026-06-12T06:56:13Z thread=019e132c... auto_compact_scope_tokens=231962 estimated_token_count=251896 auto_compact_scope_limit=244800
2026-06-12T06:56:28Z thread=019e132c... auto_compact_scope_tokens=232394 estimated_token_count=252345 auto_compact_scope_limit=244800
2026-06-12T06:56:38Z thread=019e132c... auto_compact_scope_tokens=233296 estimated_token_count=253309 auto_compact_scope_limit=244800
2026-06-12T06:56:44Z thread=019e132c... auto_compact_scope_tokens=233448 estimated_token_count=253536 auto_compact_scope_limit=244800

The important new signal from this recurrence is continuity drift across recovery sessions: a fresh/safety session can keep working, but that is not equivalent to the wedged thread preserving its active task. A supported recovery mode that emits or accepts a compact task-state packet would be much safer than requiring users to manually salvage/rewrite rollout JSONL or re-brief a new thread.

darkhipo · 1 month ago

June 12, 2026 later update: this reproduced again after my previous update on this issue, still on codex-cli 0.139.0.

Environment remains:

codex-cli 0.139.0
platform: macOS 26.5 / Darwin 25.5.0 arm64
model: gpt-5.5
reasoning effort in affected turns: high

New sanitized evidence from the current SQLite log store (~/.codex/logs_2.sqlite, not raw transcripts):

real compact failure rows in logs_2.sqlite on 2026-06-12: 8
real compact failure rows after my prior 2026-06-12T08:33:24Z comment: 6
affected thread after that comment: dfb1b3b9-e2ba-44be-96ed-d79f18a3e355
error marker in all 6 rows: stream disconnected before completion + /backend-api/codex/responses/compact

Recent rows, with transcript content omitted:

2026-06-12T15:20:23Z target=codex_client::transport thread=dfb1b3b9-e2ba-44be-96ed-d79f18a3e355 turn=cde983bc-8735-485c-bded-e1569b2f815b model=gpt-5.5 effort=high
2026-06-12T15:21:35Z target=codex_client::transport thread=dfb1b3b9-e2ba-44be-96ed-d79f18a3e355 turn=cde983bc-8735-485c-bded-e1569b2f815b model=gpt-5.5 effort=high
2026-06-12T15:23:20Z target=codex_client::transport thread=dfb1b3b9-e2ba-44be-96ed-d79f18a3e355 turn=cde983bc-8735-485c-bded-e1569b2f815b model=gpt-5.5 effort=high
2026-06-12T15:24:52Z target=codex_client::transport thread=dfb1b3b9-e2ba-44be-96ed-d79f18a3e355 turn=cde983bc-8735-485c-bded-e1569b2f815b model=gpt-5.5 effort=high
2026-06-12T20:30:17Z target=codex_core::stream_events_utils thread=dfb1b3b9-e2ba-44be-96ed-d79f18a3e355 turn=112929c7-6c77-4328-8155-5d2367376fa3 model=gpt-5.5 effort=high
2026-06-12T20:30:36Z target=codex_core::stream_events_utils thread=dfb1b3b9-e2ba-44be-96ed-d79f18a3e355 turn=112929c7-6c77-4328-8155-5d2367376fa3 model=gpt-5.5 effort=high

The important new operational signal: the dedicated safety/recovery thread (dfb1b3b9-e2ba-44be-96ed-d79f18a3e355) is now also hitting this failure while being used to recover the older primary thread. So the workaround of moving recovery work into another long-lived Codex thread eventually reproduces the same failure class.

Sanitized history-side count from ~/.codex/history.jsonl:

matching user-visible history records: 10
total user-visible compact error occurrences in those records: 16
affected local session ids in history:
  019d8749-0408-7013-adfa-b0bbe5813e2e
  019dfd8b-84b7-70a2-b8cc-6602a3b870cc
  019e132c-0d1f-7700-addc-396fc383089f
  dfb1b3b9-e2ba-44be-96ed-d79f18a3e355

I also verified that the old text log path no longer exists in this install (~/.codex/log/codex-tui.log is absent); current structured evidence is in ~/.codex/logs_2.sqlite.

Local mitigation I built outside Codex: before ending/recovering a wedged body-owned session, persist a tiny synthetic “continue if you have next steps...” prompt and have the next codex resume <session> consume it exactly once. That reduces task-continuity loss locally, but it does not fix the backend /responses/compact stream disconnect. The product-level fix still needs an official fallback/retry/recovery path when remote compaction fails, preferably one that preserves the active task-state packet instead of forcing users to reconstruct work in a new thread.

darkhipo · 1 month ago

R5709 follow-up from local repro gathering. I added a redacted local extractor in commit 4518b2f7 so future occurrences can be reported without copying raw prompt/account-bearing log bodies.

Command used:

python -m multiaim_agents.continuity.codex compact-repro --limit 8

Codex remote compact repro evidence

  • generated_at: 2026-06-12T21:16:54.534833+00:00
  • logs_db: /Users/dmitri.arkhipov/.codex/logs_2.sqlite
  • endpoint: https://chatgpt.com/backend-api/codex/responses/compact
  • privacy: raw log bodies omitted; rows include hashes and metadata only
  • compact transport rows: 5
  • UI error mentions: 8

Compact transport rows

| utc | event | status | thread | turn | model | effort | total_tokens | row | body_sha256 |
| --- | --- | --- | --- | --- | --- | --- | ---: | ---: | --- |
| 2026-06-12T21:16:48.631691Z | request | | 019e132c-0d1 | 112929c7-6c7 | gpt-5.5 | high | 7111122 | 128089899 | 54ee96b9fb1fdc46 |
| 2026-06-12T21:16:30.200559Z | request | | 019e132c-0d1 | 112929c7-6c7 | gpt-5.5 | high | 7111122 | 128087352 | 1168140c11dc5cdc |
| 2026-06-12T21:16:12.036361Z | request | | 019e132c-0d1 | 112929c7-6c7 | gpt-5.5 | high | 7111122 | 128085291 | 0e0d0899adb830ec |
| 2026-06-12T21:16:00.832398Z | request | | 019e132c-0d1 | 112929c7-6c7 | gpt-5.5 | high | 7111122 | 128081742 | b9d06ade996bd28d |
| 2026-06-12T21:15:46.975648Z | request | | 019e132c-0d1 | 112929c7-6c7 | gpt-5.5 | high | 7111122 | 128080941 | e1ed77d8feb287b9 |

UI error mentions

| utc | target | thread | row | body_sha256 |
| --- | --- | --- | ---: | --- |
| 2026-06-12T21:16:54.296123Z | log | ` | 128095743 | de8c7f8027933e3a |
| 2026-06-12T21:16:54.296072Z | log | | 128095729 | 4e897101d4922eaa |
| 2026-06-12T20:30:36.181617Z | codex_core::stream_events_utils | dfb1b3b9-e2b | 126940224 | 82f77c34ef7b53a0 |
| 2026-06-12T15:24:52.051894Z | codex_client::transport | dfb1b3b9-e2b | 120829063 | 87e965012a333506 |
| 2026-06-12T15:23:20.669290Z | codex_client::transport | dfb1b3b9-e2b | 120828839 | 87e965012a333506 |
| 2026-06-12T15:21:35.391626Z | codex_client::transport | dfb1b3b9-e2b | 120828316 | 87e965012a333506 |
| 2026-06-12T15:20:23.483568Z | codex_client::transport | dfb1b3b9-e2b | 120826005 | 538d79a673183f89 |
| 2026-06-12T00:16:32.704221Z | codex_client::transport | dfb1b3b9-e2b | 107729075 | 9c67b9bdbc47abd5` |

Note: the compact transport rows above are request-side rows only in the latest window; historical UI error mentions show the TUI-facing symptom: Error running remote compact task: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact). Raw log bodies are intentionally omitted; body_sha256 values are available for local correlation.

darkhipo · 1 month ago

June 12, 2026 additional recurrence/update from local repro gathering.

The same failure happened again after my earlier June 12 updates. I am adding this because it shows the user-visible wedge can be present in history/rollout state even when the current compact-repro window does not expose a fresh compact transport row.

Environment still observed locally:

codex-cli 0.139.0
platform: macOS 26.5 / Darwin 25.5.0 arm64
model: gpt-5.5
reasoning effort in affected turns: high

Fresh redacted extractor run:

multiaim body-continuity compact-repro --limit 20

Result at 2026-06-12T23:25:58Z:

compact transport rows: 0
UI error mentions: 6
logs_db: ~/.codex/logs_2.sqlite
endpoint: https://chatgpt.com/backend-api/codex/responses/compact
privacy: raw log bodies omitted; hashes/metadata only

Recent UI-error metadata from that run:

2026-06-12T15:24:52.051894Z target=codex_client::transport thread=dfb1b3b9-e2b row=120829063 body_sha256=87e965012a333506
2026-06-12T15:23:20.669290Z target=codex_client::transport thread=dfb1b3b9-e2b row=120828839 body_sha256=87e965012a333506
2026-06-12T15:21:35.391626Z target=codex_client::transport thread=dfb1b3b9-e2b row=120828316 body_sha256=87e965012a333506
2026-06-12T15:20:23.483568Z target=codex_client::transport thread=dfb1b3b9-e2b row=120826005 body_sha256=538d79a673183f89
2026-06-12T00:16:32.704221Z target=codex_client::transport thread=dfb1b3b9-e2b row=107729075 body_sha256=9c67b9bdbc47abd5
2026-06-12T00:15:49.685915Z target=codex_client::transport thread=dfb1b3b9-e2b row=107728064 body_sha256=69594ce795674c55

Additional user-visible evidence from ~/.codex/history.jsonl after the earlier report:

session=019e132c-0d1f-7700-addc-396fc383089f
text includes: "Error running remote compact task: stream disconnected before completion: error sending request for url (https://chatgpt.com/backend-api/codex/responses/compact)" followed by "please proceed."

session=dfb1b3b9-e2ba-44be-96ed-d79f18a3e355
text begins: "It happened again."

Operational impact in this recurrence:

  • The in-flight task was not just idle chat; it was a long background transcript ingest/normalization run.
  • The last known task state before the wedge was: Claude raw skipped 822/822, opencode raw skipped, Claude normalized count recorded, raw Gemini complete, next phase normalization/tail linking.
  • After the compact failure, recovery again moved into a separate safety thread. That is exactly the continuity-loss mode described above: the workaround thread starts spending more and more effort on recovering/resuming the original work instead of naturally continuing it.

Current local conclusion: the upstream fix should not only make /responses/compact more reliable. The CLI also needs a supported fallback path when remote compaction fails: preserve or accept a compact task-state packet on resume, so codex resume <thread_id> can continue the actual in-flight work instead of requiring a separate recovery session to reconstruct it.

darkhipo · 1 month ago

June 13, 2026 recurrence/update: this happened again on the same older primary session, after the local mitigation/comment history above.

Environment observed locally:

codex-cli 0.139.0
platform: macOS 26.5 / Darwin 25.5.0 arm64
model in affected rows: gpt-5.5
reasoning effort in affected rows: high

Operational impact this time:

  • The affected primary session is still 019e132c-0d1f-7700-addc-396fc383089f.
  • The dedicated safety/recovery session had also hit the same failure earlier, so recovery continues to drift into new threads and does not naturally resume the original in-flight work.
  • The latest recurrence again forced manual/safety-session continuation rather than a clean codex resume <thread_id> continuation of the active task.

Fresh redacted extractor run:

multiaim codex-continuity compact-repro --limit 20

Codex remote compact repro evidence

  • generated_at: 2026-06-13T04:08:23.339131+00:00
  • logs_db: /Users/dmitri.arkhipov/.codex/logs_2.sqlite
  • endpoint: https://chatgpt.com/backend-api/codex/responses/compact
  • privacy: raw log bodies omitted; rows include hashes and metadata only
  • compact transport rows: 2
  • UI error mentions: 10

Compact transport rows

| utc | event | status | thread | turn | model | effort | total_tokens | row | body_sha256 |
| --- | --- | --- | --- | --- | --- | --- | ---: | ---: | --- |
| 2026-06-13T04:08:11.119168Z | ui_error_mention | 200 OK | 019e132c-0d1 | af8787ff-52e | gpt-5.5 | high | 6532964 | 132406196 | 358f7aec9807f311 |
| 2026-06-13T04:07:57.782787Z | ui_error_mention | 200 OK | 019e132c-0d1 | af8787ff-52e | gpt-5.5 | high | 6532964 | 132405577 | 48d3eff780df6b4e |

Recent UI error mentions

| utc | target | thread | row | body_sha256 |
| --- | --- | --- | ---: | --- |
| 2026-06-13T02:20:30.544251Z | codex_client::transport | dfb1b3b9-e2b | 132047829 | b0586f6c530f2d11 |
| 2026-06-13T02:20:19.793885Z | codex_client::transport | dfb1b3b9-e2b | 132047163 | 2ed88fa5f6804449 |
| 2026-06-13T02:20:07.675240Z | codex_client::transport | dfb1b3b9-e2b | 132045503 | a921edef1a0ecb54 |
| 2026-06-13T02:19:44.174565Z | codex_client::transport | dfb1b3b9-e2b | 132042825 | 528444ed3cf82995 |
| 2026-06-13T02:19:26.486297Z | codex_client::transport | dfb1b3b9-e2b | 132041304 | 3e1304bad6d46215 |
| 2026-06-13T02:19:09.609120Z | codex_client::transport | dfb1b3b9-e2b | 132038346 | 715ea95dfbe9fcb4 |
| 2026-06-13T02:18:57.630959Z | codex_client::transport | dfb1b3b9-e2b | 132037227 | 2f9b4f3df6d70eb5 |

The notable new bit is that the latest primary-session rows carry status=200 OK metadata in the same redacted compact/error extraction window, while the user-visible failure still resolves to:

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

So from the user side, a successful-looking compact-adjacent response is still followed by a failed/unusable continuity state. The requested product behavior is the same as above: when remote compaction fails or produces an unusable resume state, Codex needs a supported fallback/recovery path that preserves active task state.

amandrecksau-stack · 1 month ago

A useful way to make the fallback testable may be to separate transport recovery from task-continuity recovery.

Before attempting remote compaction, persist a small, versioned recovery capsule containing only:

  • active objective and current phase;
  • completed results with resolvable evidence/file references;
  • the single next action;
  • constraints and decisions that must survive resume;
  • a side-effect ledger for tool calls that may have mutated external state;
  • source rollout cursor/hash and capsule checksum.

If remote compaction disconnects, returns an incomplete result, or produces a summary that fails validation, resume could rehydrate this capsule rather than trying to infer the active task from the visible chat tail.

A compact acceptance matrix could cover:

  1. remote compaction succeeds;
  2. disconnect before response bytes;
  3. disconnect mid-stream;
  4. response completes but continuity validation fails;
  5. repeated failure followed by local fallback.

For each case, assert that the objective and next action match, evidence references still resolve, the source cursor is monotonic, and no side-effecting tool call is repeated without an explicit retry decision. Emitting one structured recovery event with the capsule version, source cursor, failure kind, and selected fallback would also make this diagnosable without exposing transcript bodies.

That would turn the current manual rollout surgery into a supported recovery contract, while keeping the fallback artifact small enough to validate independently of the original thread size.

etraut-openai contributor · 21 days ago

Thanks for reporting this problem. Until recently, Codex used a separate endpoint and server-side logic for compaction. We recently switched to a more robust approach where the compaction logic is moved locally using the same endpoint as normal turns. This eliminates "remote compaction" errors and increases the stability and reliability of compaction operations. If you see further problems with compaction, please use /feedback and open a new bug report.