[app][macOS] Realtime voice fails on low-MTU VPN paths with QUIC "Message too long"

Summary

Realtime voice in the Codex macOS desktop app fails to start when traffic to OpenAI is routed through a low-MTU VPN tunnel. The backend successfully creates the realtime call, but the QUIC/WebRTC connection fails while sending its 1200-byte initial packet. The UI eventually reports only:

Voice chat couldn't start
Voice chat took too long to start

Switching the same VPN to a mode that exposes an MTU of 1500 makes voice start normally.

Environment

• Platform: macOS 26.5.1 (25F80), Apple silicon
• Failure first diagnosed on Codex Desktop 26.721.81911, bundled app-server 0.146.0-alpha.3.1
• Workaround/success reconfirmed on Codex Desktop 26.727.40816 (build 6067), bundled CLI/app-server 0.146.0-alpha.9.2
• Authentication: ChatGPT
• VPN: Astrill

Reproduction

1. Connect Astrill using WireGuard.
2. Confirm that api.openai.com routes through the VPN tunnel with MTU 1200.
3. Open a Codex task and start voice chat.
4. Wait for the startup timeout.

The same failure also reproduced using Astrill StealthVPN, where the tunnel MTU was 1107.

Evidence

The call itself is created successfully:

POST /backend-api/codex/realtime/calls -> 201 Created

The client receives a valid rtc_... realtime session ID. In at least one attempt, the WebSocket also reached 101 Switching Protocols.

The macOS network logs then show the QUIC initial packet failing at the tunnel boundary:

nw_socket_service_writes_block_invoke ... sendmsg(..., 1200 bytes) [40: Message too long]
quic_conn_handle_error_inner ... received error: Message too long
(state quic_conn_state_initial_sent)

The desktop app closes the realtime session after roughly 7–9 seconds and shows the generic startup-timeout message.

Workaround

Switching Astrill from WireGuard/StealthVPN to OpenWeb changes the route to an MTU of 1500:

route -n get api.openai.com
interface: utun10
mtu: 1500

New voice chats then start normally on the same machine, account, and Codex installation.

Expected behavior

The realtime client should adapt to or fall back on low-MTU VPN paths where possible. If the transport cannot start, the app should surface an actionable network/MTU error rather than a generic startup timeout.

Related reports

• #35252 is the closed issue where I previously reported the same visible timeout, but that issue concerns provisional task materialization and appears to have a different root cause.
• #35474 concerns voice connecting successfully and then disconnecting.
• #35968 concerns a startup timeout caused by slow skills/list.
• #35201 concerns cleanup and end-reason handling after WebRTC failure.

No credentials, session IDs, or full log files are included above.