Remote SSH thread becomes blank and thread/resume drops with "Max payload size exceeded" on a ~500 MB rollout #38431

Summary

In ChatGPT Desktop on Windows 11, opening one large existing Codex task on a remote Linux host over the Desktop SSH connection leaves the conversation blank. The initial metadata/read path can succeed, but thread/resume closes the SSH WebSocket transport with Max payload size exceeded; subsequent requests report Codex app-server is not available.

The rollout is structurally valid JSONL, and smaller tasks on the same remote host load normally. This has happened more than once and forces a manual handoff to a fresh task.

Environment

• Client: ChatGPT Desktop on Windows 11
• Execution host: Linux over the Desktop Remote SSH connection
• Remote Codex app-server: 0.146.0
• Rollout: $CODEX_HOME/sessions/.../rollout-<redacted-thread-id>.jsonl
• Rollout size: 500,458,555 bytes (about 477.3 MiB)
• JSONL records: 4,055 valid; zero parse failures
• Largest individual record: 10,719,705 bytes
• Inline data:image occurrences: 103

Steps to reproduce

1. Use a Remote SSH-backed Codex task for long-running, tool- and image-heavy work until its rollout approaches 500 MB.
2. Close or unload the task.
3. Open the existing task again from ChatGPT Desktop.
4. Observe that the conversation area remains blank while resume/reconnect attempts repeat.

In this incident, the failure first became visible after attempting to open the existing task through ChatGPT mobile Remote. That is timeline context only: causality is not established, and there is no evidence that the mobile client corrupted the task.

Expected behavior

• Render task metadata and recent turns quickly, then load older history lazily or in bounded pages.
• If a task exceeds a supported limit, fail only that task with a clear, recoverable error.
• Offer a supported export/compact/continue workflow rather than leaving a blank view.

Actual behavior

• The task remains indexed.
• An initial thread/read can succeed.
• thread/resume closes the Remote SSH WebSocket transport.
• The UI stays blank and follow-up resume attempts see an unavailable app-server.
• Smaller tasks on the same host continue to load.

Sanitized evidence/logs

thread/read ... errorCode=null
transport_closed ... connectionError={"code":"connection-failed","message":"Max payload size exceeded"}
method=thread/resume ... {"code":-32000,"message":"Codex app-server is not available"}

No raw logs or rollout data are attached because they contain private conversation and project content.

Impact

This failure is recurrent for the reporter. Each occurrence breaks continuity and requires a manual handoff to a fresh task plus a separate text export of the inaccessible conversation.

Related issues

• Long threads are unrecoverable when rollout JSONL grow beyond resume/list limits #25215 — long rollouts become unrecoverable during resume/list hydration
• Codex App reopening some threads stalls because thread/resume returns oversized image-heavy payloads #26352 — oversized image-heavy thread/resume payloads
• # Codex desktop main-process crash: RangeError: Invalid string length when loading sessions whose rollout JSONL exceeds V8's max string length #22004 — failures around approximately 512 MB image-heavy rollouts
• [Codex App][Remote SSH] Thread hydration blocks the app-server queue and causes an endless reconnect loop #36189 — Remote SSH hydration can destabilize the app-server connection
• Thread navigation/loading slows from unbounded metadata and eager large-history hydration #21211 — eager large-history hydration and blank/slow thread loading
• Codex Desktop meta-bug: unbounded session/turn state causes freezes, context bloat, and lost active-turn control #25779 — meta-tracking for unbounded session/turn state

This report adds a distinct Remote SSH/WebSocket failure mode with the exact Max payload size exceeded transport error.

Workaround / notes

The original rollout was left intact. A reporter-side, text-only export preserves the readable conversation, and read-only analysis found that the latest compaction checkpoint plus its tail would be 28,579,498 bytes across 592 records. No source repair or rollout rewrite was attempted.

Starting a fresh task and handing off context works around the UI failure, but this is not an official repair and loses normal thread continuity.