Windows Desktop stuck on Reconnecting despite successful WebSocket diagnostics — turn/started received for unknown conversation

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

26.901.51231 Released Sep 5, 2026

What subscription do you have?

Pro

What platform is your computer?

No response

What issue are you seeing?

Environment

Windows 11 x64
ChatGPT / Codex Desktop package: OpenAI.Codex 26.901.6511.0
Codex CLI: 0.153.4 windows-x86_64
Desktop executable:
C:\Program Files\WindowsApps\OpenAI.Codex_26.901.6511.0_x64__2p2nqsd0c76g0\app\ChatGPT.exe

Problem

For the last few days, the Windows Desktop app has been unusable.

Chat, Work, and Codex all get stuck on:

Reconnecting...

The web version works correctly on the same computer and network.

I also tested using a mobile hotspot and the Desktop behavior is unchanged.

Network diagnostics

Basic connectivity is working:

Test-NetConnection ws.chatgpt.com -Port 443
TcpTestSucceeded : True

Test-NetConnection chatgpt.com -Port 443
TcpTestSucceeded : True

Both IPv4 and IPv6 HTTPS requests to https://ws.chatgpt.com succeed and reach the server.

I initially had a misleading certificate error from codex doctor because my Conda environment was setting:

SSL_CERT_FILE=C:\Users\gabri\anaconda3\Library\ssl\cacert.pem
CURL_CA_BUNDLE=C:\Program Files\PostgreSQL\16\ssl\certs\ca-bundle.crt

After running Codex from a clean PowerShell environment with those variables removed, all provider/network diagnostics succeed:

network.provider_reachability:
status: ok
ChatGPT inference URL: reachable (HTTP 405)
desktop assets CDN: reachable (HTTP 200)

network.websocket_reachability:
status: ok
Responses WebSocket handshake succeeded
handshake result: HTTP 101 Switching Protocols

So this does not appear to be a DNS, firewall, VPN, proxy, TLS, IPv4/IPv6, or WebSocket connectivity problem.

Desktop log

The desktop app successfully creates a conversation and starts the turn.

A conversation is created with:

conversationId=01a07cad-f3cb-7420-8b10-c4d9d68e8639

Then turn/start succeeds for that same conversation:

[AppServerConnection] response_routed
conversationId=01a07cad-f3cb-7420-8b10-c4d9d68e8639
method=turn/start
errorCode=null

The log confirms that conversation creation and turn/start are succeeding normally.

A few seconds later, however, the renderer receives:

[electron-message-handler]
Received turn/started for unknown conversation
conversationId=01a07cae-054a-7e60-9365-36bcad63f819

Notice that this is a different conversation ID from the one created above.

The UI then remains stuck in the reconnecting state.

There are some unrelated MCP startup failures, for example:

codex_apps:
https://chatgpt.com/backend-api/ps/mcp

context7:
https://mcp.context7.com/mcp

but these happen after the main thread has already been created and turn/start has succeeded.

There is also:

[ThreadMetadataGenerationService]
Failed to generate thread title
Timed out waiting for structured result

which appears to be a downstream symptom rather than the initial failure.

What steps can reproduce the bug?

1. Launch ChatGPT/Codex Desktop for Windows.

2. Start a new local Codex conversation/workspace.

3. Send any prompt, for example:

   "Reply only with OK"

4. The UI gets stuck on:
   "Reconnecting..."

5. The desktop log shows that the conversation is created successfully:

   conversationId=01a07cad-f3cb-7420-8b10-c4d9d68e8639

6. turn/start is also accepted successfully for that same conversation:

   [AppServerConnection] response_routed
   conversationId=01a07cad-f3cb-7420-8b10-c4d9d68e8639
   method=turn/start
   errorCode=null

7. Shortly afterwards, the renderer receives turn/started for a different conversation ID:

   [electron-message-handler]
   Received turn/started for unknown conversation
   conversationId=01a07cae-054a-7e60-9365-36bcad63f819

8. The UI then remains stuck in the reconnecting state and no model response is rendered.

This reproduces consistently for Chat, Work, and Codex in the Windows Desktop app.

Network connectivity itself appears healthy. Running Codex Doctor from a clean PowerShell environment reports:

network.provider_reachability: ok
network.websocket_reachability: ok
handshake result: HTTP 101 Switching Protocols

The web version of ChatGPT works normally on the same PC and network. The issue also reproduces when switching the PC to a mobile hotspot.

Minimal diagnostic command:

codex doctor --json

Relevant result:

"network.websocket_reachability": {
  "status": "ok",
  "summary": "Responses WebSocket handshake succeeded",
  "handshake result": "HTTP 101 Switching Protocols"
}

Desktop app version:
OpenAI.Codex 26.901.6511.0

Codex CLI:
0.153.4 windows-x86_64

Desktop app session ID:
e153ee1c-035e-4448-8587-57a7c324c637

Affected conversation IDs:
Created/started:
01a07cad-f3cb-7420-8b10-c4d9d68e8639

Unexpected turn/started:
01a07cae-054a-7e60-9365-36bcad63f819

Token limit usage: N/A
Context window usage: N/A
The issue reproduces immediately on a new conversation with a trivial one-line prompt.

What is the expected behavior?

The turn/started event should be routed to the conversation that originated the turn, and the response stream should appear normally in the Desktop UI.

Actual Behavior
Desktop creates conversation A, successfully sends turn/start for A, then receives turn/started for unknown conversation B, after which the UI gets stuck on Reconnecting.

Additional information

ChatGPT web works normally on the same machine.
Switching to a mobile hotspot does not change the problem.
WinHTTP proxy: direct/no proxy.
WebSocket diagnostics from a clean Codex environment return HTTP 101 Switching Protocols.
Disabling the WireGuard adapter did not change the behavior.
Reinstall/reset attempts have not resolved the issue.

This looks more like a Desktop/app-server conversation routing or synchronization issue than a network connectivity problem.

ChatGPTError.txt

Start with the attached ChatGPTError.txt and the desktop log entries around conversation creation, turn/start, and the unexpected turn/started event. Trace why the event carries a different conversation ID; done means events route to the originating conversation and the Desktop UI renders the response instead of remaining on Reconnecting.