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

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

• #25215 — long rollouts become unrecoverable during resume/list hydration
• #26352 — oversized image-heavy thread/resume payloads
• #22004 — failures around approximately 512 MB image-heavy rollouts
• #36189 — Remote SSH hydration can destabilize the app-server connection
• #21211 — eager large-history hydration and blank/slow thread loading
• #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.

Start by tracing the thread/read and thread/resume paths through the Remote SSH WebSocket transport, using the reported 500 MB rollout and Max payload size exceeded error as the reproduction. Verify how large history is hydrated and identify the bounded-loading or task-scoped failure behavior needed so smaller tasks remain unaffected and oversized tasks show a recoverable error.