Codex Desktop SSH handoff fails for conversations larger than 16 MiB because rollout is sent as one WebSocket message

What version of the Codex App are you using (From “About Codex” dialog)?

26.707.41301

What subscription do you have?

Pro

What platform is your computer?

Linux 6.8.0-134-generic x86_64 x86_64

What issue are you seeing?

Summary

A cross-host handoff from Codex Desktop on macOS to a connected Ubuntu SSH
host consistently fails during transfer-host-artifacts when the task has a
large conversation history.

The rollout file is approximately 24.7 MB. Codex attempts to transfer it as one
WebSocket message whose serialized size is 32,936,861 bytes. The remote
app-server rejects it because its per-message limit is 16,777,216 bytes.

This prevents preserving and handing off long-running conversations.

Environment

• Codex Desktop client build: 26.707.41301
• Local codex-cli: 0.144.0-alpha.4
• Local OS: macOS
• Remote codex-cli: 0.144.1
• Remote platform: Ubuntu x86_64
• Connection type: Codex Desktop SSH host
• Source project: local Git checkout
• Destination: matching saved project on the SSH host

Steps to reproduce

1. Create or use a Codex task with a sufficiently large conversation history.
2. Ensure its rollout JSONL is larger than 16 MiB.
3. Configure a matching Git project on a connected SSH host.
4. In a separate coordinator task, hand off the large task to that SSH host.
5. Wait for the cross-host handoff.

Expected result

The conversation and associated Git state are transferred to the SSH host, and
the task switches to the remote project.

Actual result

prepare-host-transfer completes, but transfer-host-artifacts fails:

Failed to continue on another host:
App-server connection closed before process exited

The remote app-server log contains:

websocket receive error:
Space limit exceeded: Message too long: 32936861 > 16777216

The SSH proxy subsequently reports:

Error: failed to relay data between stdio and socket

Caused by:
failed to copy data from stdin to socket
Broken pipe (os error 32)

Relevant sizes

• Source rollout JSONL: 24,702,507 bytes
• Source rollout lines: 18,217
• Serialized WebSocket message: 32,936,861 bytes
• Remote WebSocket limit: 16,777,216 bytes

Reproducibility

Consistent across repeated attempts.

The following did not help:

• Rebooting the SSH host
• Disabling and re-enabling the SSH connector
• Restarting the remote app-server
• Staging the task in a local Codex worktree before remote handoff
• Confirming both repositories are clean and at the same commit

Probable cause

The handoff creates a destination rollout.jsonl using a subprocess similar to:

cat > <handoff-directory>/rollout.jsonl

It appears to send the complete rollout to the remote subprocess in one
WebSocket/process-input message. Conversations whose serialized transfer
payload exceeds the app-server's 16 MiB per-message limit therefore cannot be
handed off.

Requested fix

Please stream or chunk handoff artifacts into messages substantially below the
WebSocket limit, rather than sending the complete rollout in one message.

For example:

• Send process input in 4–8 MiB chunks, or
• Transfer the file using a streaming filesystem operation or SSH file transfer.

It would also help if the UI surfaced the underlying size-limit error instead of
only reporting that the app-server connection closed.

Impact

There is currently no supported workaround that both:

1. Completes the SSH handoff, and
2. Preserves the complete conversation history.

Summarizing or truncating the task would lose the conversation state that the
handoff feature is intended to preserve.

What steps can reproduce the bug?

Steps to reproduce

1. Create or use a Codex task with a sufficiently large conversation history.
2. Ensure its rollout JSONL is larger than 16 MiB.
3. Configure a matching Git project on a connected SSH host.
4. In a separate coordinator task, hand off the large task to that SSH host.
5. Wait for the cross-host handoff.

What is the expected behavior?

Please stream or chunk handoff artifacts into messages substantially below the
WebSocket limit, rather than sending the complete rollout in one message.

Additional information

_No response_