codex - 💡(How to fix) Fix Recoverable reconnect loop before HTTP fallback when entering new or resumed thread

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

26.519.31651

What subscription do you have?

ChatGPT Plus

What platform is your computer?

Darwin 25.4.0 arm64 arm

What issue are you seeing?

When I enter a new or resumed Codex Desktop thread, the first user turn often shows a recoverable reconnect loop:

Reconnecting... 2/5
Reconnecting... 3/5
Reconnecting... 4/5
Reconnecting... 5/5

The session eventually recovers and completes normally, so this is not a permanent connectivity failure.

From local logs, the pattern appears to be:

Codex first attempts responses_websocket against wss://chatgpt.com/backend-api/codex/responses. The WebSocket startup prewarm / first turn stream fails or times out. Codex retries several times. Codex falls back to responses_http / SSE. The turn completes successfully. Representative sanitized log fragments:

startup websocket prewarm setup failed: timeout waiting for child process to exit
event.name="codex.websocket_connect" duration_ms=15002 success="false" error.message="timeout"
stream disconnected - retrying sampling request (1/5 ...)
stream_request:model_client.stream_responses_api ... transport="responses_http"
response.completed

This happens in a proxied network environment using Shadowsocks + Clash Verge Rev with local mixed proxy 127.0.0.1:7897.

What steps can reproduce the bug?

1. Start Codex Desktop on macOS.
2. Open an existing workspace.
3. Create a new thread or resume an existing thread.
4. Send the first user message.
5. Observe Reconnecting... 2/5 through 5/5.
6. Wait for the retries to finish.
7. The session eventually becomes usable after HTTP/SSE fallback.

Additional experiments performed:

• codex app --disable plugins: reconnect still occurred.
• Clash Global mode with the same node: reconnect still occurred.
• Different proxy node type: reconnect still occurred.
• Minimal CLI control test via proxy completed successfully.
• Codex logs show traffic routed through 127.0.0.1:7897, so this does not appear to be missing proxy configuration.
• Plugin catalog endpoints may return Cloudflare 403, but model requests still succeed after fallback.

I can provide a sanitized diagnostic report if useful.

What is the expected behavior?

Codex Desktop should either:

1. establish the WebSocket transport successfully, or
2. fall back to responses_http / SSE quickly and quietly when WebSocket prewarm fails.

Ideally there should also be a documented local configuration option to force HTTP/SSE or disable responses_websocket in network environments where WebSocket is unreliable.

Additional information

Environment:

• macOS Tahoe 26.4.1, Apple Silicon
• Platform: Darwin 25.4.0 arm64 arm
• Codex CLI: 0.130.0
• Codex Desktop: 26.519.31651
• Network: mainland China network, Shadowsocks + Clash Verge Rev, local mixed proxy 127.0.0.1:7897

The issue is recoverable: after several reconnect attempts, the turn completes via HTTP/SSE fallback. The main impact is a consistent startup delay and confusing reconnect UI whenever entering a new or resumed thread.