Long CLI threads exceed Responses WebSocket message limit before auto-compaction (close code 1009)

The 5.38 GB rollout + long-thread transport fallback makes this a useful boundary case for codex-rescue field validation. The tool won’t fix the WebSocket 1009 / transport-size mismatch; what I want to test is whether it can discover and diagnose the persisted session safely without loading/replaying unknown actions.

If the affected thread is still the latest local one, could you try:

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

Given the rollout size, please start with sessions + doctor only. A clean/healthy result is useful too because false-positive resistance is part of what I’m testing.

Please share only sanitized output, versions, timings/exit codes. No raw rollout/SQLite, prompts, credentials, or unredacted paths. Repo: https://github.com/shleder/codex-rescue

Excellent forensics — the patched-build close-code capture pins this. Confirming the code side on main @ 1f41cc5d92 and adding the classification/fix seams.

The close frame really is discarded. The Responses WebSocket receive loop pattern-matches the close frame away and emits a fixed string:

https://github.com/openai/codex/blob/1f41cc5d92722748e45cae9cecc6d883a4e7cbb1/codex-rs/codex-api/src/endpoint/responses_websocket.rs#L817-L821

Message::Close(_) → ApiError::Stream("websocket closed by server before response.completed"). Your diagnostic patch (including code + reason) is essentially the first fix as-is — without it, 1009 is indistinguishable from a flaky network drop, which is why the stock CLI's behavior looks so irrational.

Why five identical retries follow. The request is serialized and sent as a single Message::Text (responses_websocket.rs#L882, #L904). Once the failure is an ApiError::Stream, the retry machinery treats it like any dropped stream: stream_max_retries same-transport retries, then the transport fallback (core/src/responses_retry.rs#L86-L100 — the gate has no semantic check on the error). For 1009 the payload is byte-for-byte identical on every retry, so all five attempts are deterministic failures; only the HTTPS fallback (no equivalent per-message cap) can succeed. This is the same classification gap as #38831 (response.incomplete → generic Stream error → blind retries + fallback): semantically terminal information is flattened into "stream broke".

Why compaction never saves you. Auto-compaction triggers on token thresholds (your observed 244,800 of a 258,400 window), but the WS peer's limit is a byte cap on the serialized message. Tokens and bytes correlate loosely at best — histories heavy in JSON structure, tool output, or base64 content hit the byte cap well before the token threshold, opening exactly the window you measured (~225k tokens, under the compaction threshold, over the message cap). No token-tuned threshold can close a byte-defined gap.

Fix outline, smallest first:

1. Include close code + reason in the error (your patch). Also worth mapping WsError::ConnectionClosed separately from a received close frame — today both collapse into unlabeled Stream errors (#L567-L569).
2. Classify a received close 1009 as deterministic-for-this-payload: skip same-transport retries and go straight to HTTPS fallback. That alone removes the five wasted attempts and most of the latency you're seeing.
3. Byte-aware pre-flight: the client knows the serialized request size at #L904 before sending. Comparing it against a configured/known WS message cap and preferring HTTPS (or triggering early compaction) up front turns the failure mode into a non-event, and gives auto-compaction a byte-based trigger to complement the token one.

Your reproduction (small prompt on a ~225k-token thread) is directly reusable as the regression test for (2)/(3): assert one WS attempt max and no user-visible retry storm when the serialized request exceeds the cap.

when i instrumented it with heavier logging, it just said it was too big 5 times in a row.
The solution is pretty simple. the client just needs to truncate the message under the cap when it sends it in that's all.
I do not think the right behaviour is to skip retries or instantly default to http requests when the message goes above a certain size.
Hell, subdividing the message would be fine, but if the cap is about throughput anyways, truncation seems right to me.

That being said that call is for OpenAI to make, not me.

I had codex chase a little local patch, but its trivial and openai should probably make one go into mainstream codex-cli on next version.
I would guess a lot of users ran into this same issue and may not even realize it.

Fair pushback on the retry-skipping point — one consideration on truncation, though: the WS message here isn't a stream of independent data, it's one serialized JSON request containing the conversation history. Truncating it under the cap byte-wise would produce invalid JSON (or, if done structurally, silently drop history items the model was supposed to see — changing model behavior with no user-visible signal). The system already has a semantically-safe mechanism for "history too big": compaction, which summarizes rather than drops, and is model-visible. That's why I'd frame the byte-triggered path as "compact early (or choose the transport without the cap)" rather than literal truncation — same trigger you're proposing, but routed through the mechanism that preserves request validity. Subdivision would need server-side reassembly semantics the Responses WS protocol doesn't currently expose. Agreed the final call is OpenAI's; either way the first step is the same one your patch demonstrated — stop discarding the close code.

On the truncation debate: the WS payload here is one serialized JSON request containing prior turns, so byte-level truncation would corrupt the request rather than trim it gracefully. The workable seam is a client-side pre-flight byte budget over the serialized turn set - reject or shrink before send instead of discovering the cap at frame time.