Remote SSH disconnects when large `plugin/list` response blocks WebSocket pongs

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

26.825.41651

What subscription do you have?

ChatGPT Pro Lite

What platform is your computer?

Client: Darwin 24.6.0 arm64 arm; server: Linux 6.8.0-111-generic x86_64 x86_64

What issue are you seeing?

Codex Desktop Remote SSH repeatedly disconnects with WebSocket code 1006, although SSH remains available and the persistent remote app-server stays alive.

A protocol probe identified this sequence:

1. plugin/list returns approximately 7.57 MB containing over 3,300 remote plugin summaries.
2. The response is emitted as one unfragmented WebSocket frame.
3. While that frame drains through the SSH proxy, pong frames cannot interleave.
4. Desktop continues sending pings, but its 60-second no-pong watchdog eventually terminates the healthy proxy.

The app-server does not appear globally stalled:

Cached plugin/list:          0.31 s,  7,568,723 bytes, 1 frame
Forced plugin/list:           9.47 s,  7,573,180 bytes, 1 frame
Concurrent config/read: 2-6 ms

During an actual failure, server-side monitoring showed continuing proxy output, acknowledged TCP traffic, and an empty TCP send queue. The persistent app-server retained the same PID after the proxy was terminated.

A controlled slow-reader test reproduced the behavior without SSH: once the large frame began, subsequent pongs and small responses remained unavailable until the frame completed, causing a no-pong watchdog to fire.

What steps can reproduce the bug?

1. Enable plugins and remote_plugin on a Linux Codex host.
2. Connect using Codex Desktop Remote SSH.
3. Trigger or wait for a background plugin/list.
4. Observe the request timeout, WebSocket close code 1006, and reconnection.
5. Confirm that SSH and the persistent app-server remain alive.

The failure also reproduced with SSH multiplexing disabled and a fresh authenticated SSH connection.

What is the expected behavior?

Large app-server responses should not block WebSocket control traffic or disconnect the remote host.

Additional information

As a size-control experiment, setting

[features]
remote_plugin = false

reduced the response from approximately 7.57 MB to 319 KB while retaining bundled and locally curated plugins.

Related: #37401, #34244, #36518.

Start with the app-server plugin/list response path and the WebSocket proxy behavior described in the report. Reproduce the issue with the controlled slow-reader test or remote_plugin enabled, then trace why a large unfragmented frame prevents pongs and small responses from being handled. Done means large responses no longer trigger the no-pong watchdog or disconnect the healthy remote session.