App-server still drops remote-control clients when outbound queue fills (128 messages) — #18203 fix missed the code path

[joewolly]

Summary

codex app-server still disconnects remote-control clients mid-turn with disconnecting slow connection after outbound queue filled on codex-cli 0.147.0 (and the same code exists on current main and rust-v0.148.0-alpha.5). This is the same symptom as #18203, which was closed as fixed by #19246 — but that PR only raised the WebSocket writer buffer. The per-connection outbound message channel that actually triggers the disconnect is still 128 messages, so the bug is unfixed.

Environment

• codex-cli 0.147.0 (standalone package, Linux x86_64)
• codex app-server with remote control enabled; phone + desktop apps connected through the chatgpt.com relay (wss://chatgpt.com/backend-api/wham/remote/control/server)
• model routed through a local OpenAI-compatible proxy (opencode-go/deepseek-v4-flash, reasoning_effort=max)

Root cause

CHANNEL_CAPACITY is still 128 (verified identical on main, rust-v0.147.0, and rust-v0.148.0-alpha.5 as of 2026-08-07):

// codex-rs/app-server-transport/src/transport/mod.rs (line 25)
pub const CHANNEL_CAPACITY: usize = 128;

Disconnect path unchanged (codex-rs/app-server/src/transport.rs):

if connection_state.can_disconnect() {
    match writer.try_send(queued_message) {
        Ok(()) => false,
        Err(mpsc::error::TrySendError::Full(_)) => {
            warn!("disconnecting slow connection after outbound queue filled: {connection_id:?}");
            disconnect_connection(connections, connection_id)
        }
        ...

Reproduction

Run two threads concurrently so both stream reasoning deltas to one remote-control connection (each max-effort thread can emit hundreds of events/sec; relay latency lets the 128-slot queue fill). The app-server then kills the client:

20:23:28 WARN  transport | disconnecting slow connection after outbound queue filled: ConnectionId(25)
20:23:28 WARN  transport | dropping message for disconnected connection: ConnectionId(25)
20:23:28 INFO  client_tracker | forwarding remote control connection closed transport event connection_id=ConnectionId(25)

Both the phone and desktop apps show "connection lost"; the thread keeps running server-side but the client session is dropped.

Expected behavior

A slow-but-alive client should not be disconnected because of a burst. The outbound queue should be sized for streaming workloads, or the writer should apply backpressure (await send) and only disconnect after a timeout.

Suggested fix

• Raise CHANNEL_CAPACITY for remote-control connections (the WebSocket writer buffer was raised to 64K in Increase app-server WebSocket outbound buffer #19246), or
• Replace try_send + immediate disconnect with async backpressure plus a disconnect timeout.

References

• App-server disconnects remote TUI mid-turn when outbound queue fills (128 messages) #18203 (original report, closed 2026-04-24)
• Increase app-server WebSocket outbound buffer #19246 (merged "fix" that missed this code path)
• Evidence comment on App-server disconnects remote TUI mid-turn when outbound queue fills (128 messages) #18203: App-server disconnects remote TUI mid-turn when outbound queue fills (128 messages) #18203 (comment)