codex - 💡(How to fix) Fix Desktop: first turn sometimes shows "Reconnecting... 2/5" even though app-server transport remains connected [2 comments, 3 participants]

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.