Codex Desktop SSH workspace disconnects when image attachments exceed the 16 MiB WebSocket limit

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

26.727.51351 (build 6119), bundled codex-cli 0.146.0-alpha.9.2

What subscription do you have?

Not specified; the failure occurs in the local Desktop-to-remote app-server transport before model processing.

What platform is your computer?

Client: macOS 26.5.2 (Apple Silicon)

SSH remote: macOS 26.5.2 (Apple Silicon), codex-cli 0.145.0-alpha.18

What issue are you seeing?

In a Codex Desktop project connected to a remote host over SSH, submitting image attachments can consistently disconnect the remote app-server when the serialized turn/start request exceeds the app-server's 16 MiB WebSocket message limit.

The images themselves are transferred to the remote host successfully. However, the request sent to the remote app-server still contains inline data:image/jpeg;base64,... image payloads. With two JPEGs of 8,001,043 and 11,429,867 bytes (19,430,910 bytes total), the base64 payload is approximately 25.9 MB before JSON overhead.

The Desktop UI then reports:

Codex app-server is not available

The local Desktop logs at the exact submit time contain:

transport_closed closeCode=1006
ssh_websocket_v0.proxy_command_failed code=1
failed to relay data between stdio and socket
Broken pipe (os error 32)

The SSH connection and app-server reconnect roughly one second later. Retrying the same images reproduces the disconnect.

A controlled reproduction against the stock 0.146.0-alpha.9.2 app-server with a single approximately 17 MiB WebSocket message produces the underlying error:

Space limit exceeded: Message too long: 17825840 > 16777216

The affected rollout records the images as inline data URLs and has no usable local-image entries:

images: ["data:image/jpeg;base64,...", ...]
local_images: []

This appears related to #32512, but it is a different user path: that issue covers transferring a large conversation rollout during cross-host handoff, while this issue occurs during an ordinary turn/start when sending image attachments to an already-connected SSH workspace.

What steps can reproduce the bug?

1. Add an SSH remote host to Codex Desktop and open a project on that host.
2. Start or open a normal task in the remote project.
3. Attach image files whose combined base64-encoded size plus JSON overhead exceeds 16 MiB. Two JPEGs around 8 MB and 11.4 MB reproduce it consistently.
4. Submit the message.
5. Observe Codex app-server is not available, WebSocket close code 1006, and a brief reconnect.
6. Retry with the same images; the failure repeats.

What is the expected behavior?

Image attachments should be submitted successfully without disconnecting the remote app-server.

Since Codex Desktop has already copied the files to the SSH host, it could reference the remote filesystem paths rather than re-embedding the image bytes as base64. Other possible fixes include chunking/streaming oversized requests, or making the server acceptor limit consistent with the existing 128 MiB remote client limit.

The UI should also surface the underlying size-limit error instead of reporting only that the app-server is unavailable.

Additional information

• The SSH listener remains stable throughout the failure; this is not an SSH tunnel failover or link drop.
• Remote CPU, memory, and disk were healthy.
• Text-only messages continue to work.
• The image files reach the remote filesystem before the request fails.
• Raising the Unix WebSocket acceptor's frame/message limit to 128 MiB in an isolated build allowed both 17 MiB and 32 MiB test messages to remain connected and respond to ping/pong.
• No application bundle modifications are involved in this report.

Related: #32512