Desktop: first turn sometimes shows "Reconnecting... 2/5" even though app-server transport remains connected

[linchengyang]

Summary

In Codex Desktop on Windows, the first message in a newly created conversation sometimes shows:

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

However, the local desktop logs suggest this is not always a real transport reconnect. In the failing case below, the app-server transport stayed connected, and the problem looked more like a conversation/turn state sync race:

• client receives turn/started for an unknown conversation
• then repeatedly reports No turns for conversation
• UI surfaces this as Reconnecting...

This makes the issue look like a model/network reconnect, but the underlying failure appears to be conversation state initialization on the first turn.

Environment

• OS: Windows
• App: Codex Desktop
• Desktop package version seen in logs: 26.415.4139.0
• CLI/app-server version seen in logs: 0.122.0-alpha.1

Minimal Reproduction

1. Launch Codex Desktop on Windows.
2. Open or create a fresh conversation.
3. Send the first message in that conversation.
4. Observe that the UI may show:
   • Reconnecting... 2/5
   • Reconnecting... 3/5
   • etc.

This seems more likely on the first turn of a newly created conversation than on later turns in the same thread.

Expected Behavior

• The first turn in a new conversation should start streaming normally.
• If the underlying issue is conversation initialization rather than transport loss, the UI should not display a reconnecting state.

Actual Behavior

• UI shows Reconnecting... N/5.
• The turn may still eventually proceed, but the user sees what looks like a transport failure.
• Desktop logs show conversation-state errors rather than a clean transport disconnect/reconnect cycle.

Key Evidence

1. Transport appears to initialize and remain connected

From the desktop log:

• app_server_connection.state_changed ... next=connecting
• initialize_handshake_result ... outcome=success
• app_server_connection.state_changed ... next=connected

This suggests the app-server transport successfully initialized.

2. First-turn state race symptoms

During the timeframe matching the UI reconnecting behavior, the log shows:

• Received turn/started for unknown conversation
• followed by thread/read
• followed by repeated No turns for conversation

This strongly suggests the client receives turn events before the local conversation state is ready.

3. UI likely maps this state failure to reconnecting

The user-facing UI showed reconnect attempts, but the log did not show a fresh app-server state transition from connected -> disconnected -> reconnecting at that same moment.

Relevant Log Excerpts

Log file:
C:\Users\Think\AppData\Local\Packages\OpenAI.Codex_2p2nqsd0c76g0\LocalCache\Local\Codex\Logs\2026\04\18\codex-desktop-40ba8e35-9737-40fa-9cea-d938935f4635-10792-t0-i1-072620-0.log

Startup / connected:

• line 4: app-server state changed to connecting
• line 13: initialize_handshake_result ... outcome=success
• line 15: app-server state changed to connected

First-turn failure pattern:

• line 3810: Received turn/started for unknown conversation conversationId=019da05c-a16c-7bb2-8526-9a32097ba214
• line 3811: response_routed ... method=thread/read ... conversationId=019da05c-a16c-7bb2-8526-9a32097ba214
• line 3816+: repeated No turns for conversation conversationId=019da05c-a16c-7bb2-8526-9a32097ba214

A second similar case happens immediately after:

• line 3941: Received turn/started for unknown conversation conversationId=019da05f-447e-7941-98ec-ffce9ac2bb3d
• line 3942: response_routed ... method=thread/read ... conversationId=019da05f-447e-7941-98ec-ffce9ac2bb3d
• line 3943+: repeated No turns for conversation conversationId=019da05f-447e-7941-98ec-ffce9ac2bb3d

Interpretation

This looks like a race between:

• conversation creation / local state hydration
• incoming turn/started events

The UI may be treating this as a reconnect-worthy failure, even when the underlying transport is still healthy.

Additional Note

I also saw a separate earlier log entry on the same date where analytics/event traffic hit a 403 Forbidden Cloudflare challenge page. That may indicate an independent network/environment issue, but it does not appear to be the primary cause of this specific first-turn reconnecting symptom.

Possible Fix Direction

• Delay handling of turn/started until conversation state is guaranteed present locally, or
• buffer unknown-conversation turn events briefly and retry state resolution before surfacing reconnect UI, or
• distinguish transport reconnect from conversation-state hydration failure in UI messaging.

[github-actions]

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• Codex Mac Desktop App: existing threads don't load after app restart #16817

Powered by Codex Action

[dushaoshuai]

A workaround that consistently fixed this for me on macOS was to set proxy environment variables for Codex via ~/.codex/.env.

For example, either of these worked:

https_proxy=http://127.0.0.1:7892
http_proxy=http://127.0.0.1:7892
all_proxy=socks5://127.0.0.1:7892

or just:

all_proxy=http://127.0.0.1:7892

After adding that file and restarting Codex, the repeated Reconnecting... attempts at the start of a new conversation stopped for me.

So at least in my case, the symptom looked related to proxy / transport handling rather than only conversation-state initialization. This may not be the root cause for every report in this thread, but it could help others quickly confirm whether their environment is part of the problem.

[Mahkhmood9]

you should having simular issues with like Discord , or Electron based apps / chromium based apps too

[rzv-me]

This issue has been happening to me all day on new threads, on macOS and multiple Codex APP versions I updated through today, even the lastest Version 26.422.62136 (2180)

The same issue happens to me for the CLI, ending after ~100s in the error: ⚠ Falling back from WebSockets to HTTPS transport. timeout waiting for child process to exit

Described my bug in detail in #19994