Recoverable reconnect loop before HTTP fallback when entering new or resumed thread
已打开 08:34AM - 22 May 26 UTC
bug
app
connectivity
### 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:
```text
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:
```text
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.