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?
- Start Codex Desktop on macOS.
- Open an existing workspace.
- Create a new thread or resume an existing thread.
- Send the first user message.
- Observe
Reconnecting... 2/5 through 5/5.
- Wait for the retries to finish.
- 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:
- establish the WebSocket transport successfully, or
- 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.
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:
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:
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?
Reconnecting... 2/5through5/5.Additional experiments performed:
codex app --disable plugins: reconnect still occurred.Globalmode with the same node: reconnect still occurred.127.0.0.1:7897, so this does not appear to be missing proxy configuration.I can provide a sanitized diagnostic report if useful.
What is the expected behavior?
Codex Desktop should either:
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_websocketin network environments where WebSocket is unreliable.Additional information
Environment:
Darwin 25.4.0 arm64 arm127.0.0.1:7897The 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.