›_ Codex Issues
Codex Issues / #18471

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

Open 💬 7 comments Opened Apr 18, 2026 by linchengyang
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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.

View original on GitHub ↗

7 Comments

github-actions[bot] contributor · 3 months ago

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

  • #16817

Powered by Codex Action

dushaoshuai · 3 months ago

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 · 3 months ago

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

rzv-me · 2 months ago

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

Mahkhmood9 · 2 months ago

I dont face it anymore , seems to be fixed for me - I only faced it once , at 5.5 launch

umiusiyear-ui · 7 days ago

Additional current Windows reproduction from 2026-07-13. In my case, the conversation-state race escalates to a fatal app-server exit.

Environment

  • Windows 11
  • Unified ChatGPT Desktop package: 26.707.8479.0
  • Bundled app-server: 0.144.2
  • Model: gpt-5.6-sol

Reproduction

  1. Updated the Desktop package from 26.707.8168.0 to 26.707.8479.0.
  2. Started from a fresh parent task without opening the previously affected conversation.
  3. Created a new delegated child conversation. A minimal no-tool probe completed once.
  4. Created another fresh delegated child for one bounded task.
  5. Desktop crashed as the delegated conversation started.

This was reproduced more than once on fresh tasks, so it is not limited to reopening an old or contaminated rollout.

Relevant redacted evidence

The Desktop log around the failure contains repeated conversation-state errors including:

Received item/... for unknown conversation
Conversation state not found

The app-server then exits with:

code=3221225786
0xC000013A

The crash dialog displays this WARN as the "Most recent error":

Model personality requested but model_messages is missing,
falling back to base instructions.

That WARN may be incidental/last-seen rather than the root cause. The stronger correlation in this reproduction is new delegated-conversation creation followed by unknown-conversation/state-not-found events and then the fatal exit.

Control

The standalone CLI was upgraded to the current 0.144.3 and tested with an ephemeral, read-only, no-tool prompt using the same model/provider route:

model: gpt-5.6-sol
provider: openai
exit code: 0
result: CLI_CONNECTIVITY_OK
elapsed: 4.3s

This does not prove the model is universally fault-free, but it narrows the failing path toward Desktop conversation/subagent state coordination rather than basic model connectivity.

Impact / request

Fresh delegated conversations are unsafe because a conversation hydration/routing race can terminate the entire local app-server. Please consider buffering events for not-yet-hydrated conversation IDs, retrying state resolution, and showing the actual fatal-path error instead of the last WARN.

Possibly related: #16271 and #22996. I can provide redacted timestamped log excerpts through a secure feedback channel if needed.

user-nmmmmm · 15 hours ago

I can reproduce a very similar issue on the new Windows desktop app.
Environment
ChatGPT Windows app: 26.715.2236.0
Windows 11 Pro Insider Preview, build 26220.8764
Proxy is configured through WinHTTP / Clash Verge

Regular Chat works normally in the desktop app. Existing/historical Work conversations can also send messages successfully. However, every newly created Work conversation remains indefinitely stuck on “Sending”; Codex is affected as well.
The same account works normally in ChatGPT Work on the web. I have also reproduced this after reinstalling/resetting the app, flushing DNS, syncing system time, and switching proxy nodes.
This seems more consistent with a Windows Desktop new-conversation/session-initialization issue than a general connectivity failure. I have also reported it to OpenAI Support.