›_ Codex Issues
Codex Issues / #21167

Codex Desktop reconnect loop on new/restarted conversations due to turn/started for unknown conversation

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

Summary

Codex Desktop consistently enters a reconnect loop when I:

  • start a new conversation
  • restart an old conversation

This is reproducible on every attempt in the desktop app.

The issue does not appear to be caused by my VPN or local cache state. I reset the relevant local storage areas and the behavior remained unchanged.

Environment

  • Product: Codex Desktop
  • Date observed: May 5, 2026
  • OS: macOS
  • App version seen in session metadata: 0.128.0-alpha.1

Reproduction

  1. Open Codex Desktop
  2. Start a new conversation
  3. Or restart an old conversation
  4. Observe repeated Reconnecting... retries
  5. Eventually it may recover, but the reconnect loop happens first

Expected behavior

New conversations and restarted conversations should start normally without reconnect loops.

Actual behavior

The app shows repeated reconnect attempts specifically at conversation start / restart time.

Key log evidence

In the desktop logs, the pattern is:

  1. browser sidebar thread is registered with conversationId=new-conversation
  2. browser-use is force-installed at runtime
  3. the conversation is created successfully
  4. turn/start is routed successfully for the expected conversation
  5. immediately after that, the app logs:

Received turn/started for unknown conversation

This strongly suggests a conversation routing bug inside the desktop app.

Example reproduction after local reset

Log file:

/Users/qinggang/Library/Logs/com.openai.codex/2026/05/05/codex-desktop-cc899bf8-644a-44ab-8b1f-e69327433dde-53115-t0-i1-101625-0.log

Relevant sequence from that log:

  • registered browser sidebar thread conversationId=new-conversation
  • forceInstallPluginNames=["browser-use"]
  • bundled_plugin_install_requested pluginName=browser-use reason=forced
  • Conversation created conversationId=019df7a3-a20a-7671-8c71-af4fafb29e9c
  • normal turn/start
  • captured turn route conversationId=019df7a3-a20a-7671-8c71-af4fafb29e9c
  • then:

Received turn/started for unknown conversation conversationId=019df7a3-b244-7f80-8d4d-5de2d6ed71b1

Earlier matching reproductions

Same pattern was also seen for these conversations:

  • 019df631-720c-7ba3-9a40-0849d27bbd9b
  • 019df78a-be9e-7e12-8125-5788c03e7a9b

What I already tried

I ruled out local state corruption by resetting these areas:

  • main app Session Storage
  • main app SharedStorage
  • browser partition Partitions/codex-browser-app

I also set this in ~/.codex/config.toml:

[plugins."browser-use@openai-bundled"]
enabled = false

[codex-desktop-reconnect-findings-2026-05-05.md](https://github.com/user-attachments/files/27395651/codex-desktop-reconnect-findings-2026-05-05.md)

View original on GitHub ↗

8 Comments

github-actions[bot] contributor · 3 months ago

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

  • #19994
  • #19983
  • #19529
  • #19703

Powered by Codex Action

pamelia · 2 months ago

Additional macOS reproduction on 2026-06-04 with current public desktop builds.

Environment:

  • macOS, Apple Silicon
  • Codex Desktop production DMG from https://persistent.oaistatic.com/codex-app-prod/Codex.dmg
  • Current public desktop app: 26.601.21317 / build 3511
  • Bundled app-server runtime in the signed app bundle: codex-cli 0.136.0-alpha.2
  • Homebrew CLI on same machine works: codex-cli 0.137.0

What was tried:

  • Full app-specific uninstall/reset: moved /Applications/Codex.app and Codex-specific Application Support, Caches, Logs, Preferences, HTTP storage, saved state, and crash reports out of the live locations; preserved ~/.codex because CLI works.
  • Reinstalled from the official public production DMG. The issue reproduced.
  • Verified the production Sparkle feed currently advertises build 3511 as latest.
  • Rolled back to official signed appcast builds:
  • 26.601.20914 / build 3497
  • 26.527.60818 / build 3437

Both still reproduced the same routing failure.

  • Temporarily disabled browser-related features via config while testing (browser_use = false, in_app_browser = false); the failure still reproduced. Those config changes were later removed.
  • Verified the desktop app honors CODEX_CLI_PATH; setting it in the GUI launchd namespace to /opt/homebrew/bin/codex made the app spawn the Homebrew runtime and report 0.137.0. With rollback UI build 3437 plus app-server 0.137.0, the same unknown-conversation failure still reproduced.

Representative log sequence from build 3437:

Current reported app-server version: currentVersion=0.136.0-alpha.2 hostId=local
Conversation created conversationId=019e9299-1c50-7dd1-baad-b539d03e79ba
response_routed ... conversationId=019e9299-1c50-7dd1-baad-b539d03e79ba ... method=turn/start ...
Received turn/started for unknown conversation conversationId=019e9299-1e72-7083-b360-4e66514e1ab9

Representative log sequence proving CODEX_CLI_PATH override works:

stdio_transport_spawned ... executablePath=/opt/homebrew/bin/codex ... spawnCommand=/opt/homebrew/bin/codex
Current reported app-server version: currentVersion=0.137.0 hostId=local

The current public production DMG still embeds 0.136.0-alpha.2, while the standalone CLI is 0.137.0 and works normally. The symptom appears isolated to the desktop app conversation routing path.

kosmotaur · 2 months ago

Adding another current macOS reproduction with sanitised details. No prompts, raw transcripts, screenshots, account identifiers, or full local paths included.

Environment

  • Product: Codex Desktop on macOS
  • Bundled CLI: codex-cli 0.137.0-alpha.4
  • OS: macOS 26.2, arm64
  • Observed: 2026-06-08 around 12:24 BST
  • codex doctor --json summary: auth OK, websocket handshake OK, installation/runtime OK, state rollout DB parity OK, active rollout files and state DB rows agree. The only doctor failure was TERM=dumb in the agent terminal, which does not look related to Desktop renderer state.

User-visible behaviour

  • Codex Desktop chat messages intermittently disappear from the active conversation.
  • Around the same observation window, the project sidebar showed multiple saved projects as No chats even though local thread/session data still existed and direct thread read by ID worked.

Relevant sanitised renderer log sequence

The app registered one conversation ID for the visible thread:

2026-06-08T11:24:48.180Z info [electron-message-handler] Conversation created conversationId=019ea6fa-2afa-...-c525a5
2026-06-08T11:24:48.237Z info [AppServerConnection] response_routed conversationId=019ea6fa-2afa-...-c525a5 method=turn/start errorCode=null
2026-06-08T11:24:48.306Z info [browser-session-registry] registered browser sidebar thread conversationId=019ea6fa-2afa-...-c525a5

Immediately afterwards, turn lifecycle events arrived for a different conversation ID that the renderer did not know about:

2026-06-08T11:24:49.375Z error [electron-message-handler] Received turn/started for unknown conversation conversationId=019ea6fa-64c3-...-f8ed
2026-06-08T11:24:54.143Z error [electron-message-handler] Received turn/completed for unknown conversation conversationId=019ea6fa-64c3-...-f8ed

That maps closely to the visible symptom: turn/message activity exists, but the Desktop renderer has no registered conversation to attach it to, so the message state disappears or is not rendered under the active chat.

Extra signal

The affected workspace initially had a Git directory with no commits/no HEAD, which caused Desktop git probes such as rev-parse --abbrev-ref HEAD to fail. I created an initial root commit, and the git branch probe now succeeds. That may explain some sidebar/project grouping instability, but it does not explain the separate turn/... for unknown conversation renderer errors above.

I can provide fuller logs privately if useful, but the public report is intentionally trimmed to avoid leaking local content.

mplibunao · 2 months ago

I’m seeing the same failure pattern on macOS with Codex Desktop 26.616.51431.

Fresh Desktop chats stay stuck on “thinking”. The key sequence is:

  1. thread/start succeeds.
  2. Conversation created conversationId=019ef210-ed3d-75a3-b4ac-08b836fc6795
  3. turn/start succeeds for that same visible conversation ID.
  4. IAB_LIFECYCLE reassigned browser use route sourceConversationId=019ef210-ed3d-75a3-b4ac-08b836fc6795 targetConversationId=client-new-thread:...
  5. Desktop then logs Received turn/started for unknown conversation for different IDs, e.g. 019ef210-fd51... and 019ef211-0427....

The unknown IDs do not exist in ~/.codex/state_5.sqlite; only the visible conversation row is persisted.

I ruled out local state/config causes:

  • reboot did not fix it
  • PRAGMA integrity_check is ok
  • no active / or temp-cwd rows
  • no archive flag mismatches
  • resetting Electron app-support state did not fix it
  • testing with a minimal ~/.codex/config.toml did not fix it
  • restoring the original profile/config reproduces the same behavior

This looks like an app-server/Desktop event-correlation regression: turn/start is associated with the visible conversation, but subsequent turn/started events arrive under different conversation IDs, so the renderer never attaches the running turn.

clavelinaswykoniki-cell · 2 months ago

Adding another current macOS reproduction that looks like the same Desktop conversation-routing failure, but with a slightly different user-visible trigger: an in-progress local task is interrupted by quitting the Codex app, and after reopening the same thread appears to keep "thinking" without actually resuming.

Environment:

  • Product: Codex Desktop on macOS
  • macOS: 26.5.1, arm64
  • Codex Desktop: 26.616.81150, build 4306
  • Bundled CLI/app-server: codex-cli 0.142.0
  • Observed: 2026-06-24 around 16:11 CST

User-visible behavior:

  1. A local Codex Desktop thread is actively running.
  2. I choose to quit Codex while the turn is still in progress. The app shows the quit confirmation dialog.
  3. I reopen Codex and return to the same thread.
  4. The thread still shows a running/thinking state and a "continue" style UI, but it does not make progress. It appears to spin rather than resuming the original task.

I have a 39s screen recording of this sequence, but I am not attaching it publicly because it includes local project and desktop contents. I can provide a redacted recording if needed.

Relevant sanitized log sequence:

2026-06-24T08:13:40.697Z response_routed ... method=thread/start ... errorCode=null
2026-06-24T08:13:52.050Z Conversation created conversationId=019ef8b1-295d-7881-bcc5-c5c07413800a
2026-06-24T08:13:52.150Z response_routed conversationId=019ef8b1-295d-7881-bcc5-c5c07413800a method=turn/start errorCode=null
2026-06-24T08:13:52.170Z IAB_LIFECYCLE reassigned browser use route sourceConversationId=019ef8b1-295d-7881-bcc5-c5c07413800a targetConversationId=client-new-thread:...
2026-06-24T08:13:52.438Z Received turn/started for unknown conversation conversationId=019ef8b1-5673-7c63-b1cb-e30e2df24fd9
2026-06-24T08:13:59.879Z Received turn/completed for unknown conversation conversationId=019ef8b1-5673-7c63-b1cb-e30e2df24fd9
2026-06-24T08:13:59.923Z response_routed conversationId=019ef8b1-295d-7881-bcc5-c5c07413800a method=thread/name/set errorCode=null

This matches the issue pattern already described here: turn/start is routed for the visible conversation, but subsequent turn/started and turn/completed events arrive under a different conversation ID. The visible Desktop thread then has no event stream to attach to, so it remains stuck in a running/thinking UI state.

The important additional trigger here is app lifecycle interruption: quitting the app while a turn is running, then reopening and returning to that session.

OMGyang · 21 days ago

Adding another macOS reproduction with a distinct interrupt/rollback trigger and a stronger orphaned-turn state signal.

Environment

  • Codex Desktop / ChatGPT app: 26.803.41515 (build 6321)
  • Bundled app-server: codex-cli 0.147.0-alpha.6.5
  • macOS 14.0 (23A344), arm64
  • Observed: 2026-08-07

Trigger sequence

  1. A long-running turn was using Browser Use.
  2. The active turn was steered and then interrupted.
  3. A replacement turn was started, interrupted, and rolled back.
  4. The desktop app was restarted.
  5. The same thread was reopened and a short "continue" message was sent.

Actual state

  • The two newest turns were simultaneously reported as inProgress.
  • Both turns contained only the user message: no reasoning item, assistant message, tool call, or approval request.
  • The thread snapshot reported status: active with activeFlags: [].
  • Waiting on the thread produced no progress, and restarting the app did not recover it.

Sanitized renderer/app-server evidence

response_routed conversationId=<redacted> method=turn/start errorCode=null
Received turn/started for unknown conversation conversationId=<redacted>

The rollout timeline also showed repeated turn_aborted, thread_rolled_back, and task_started events, followed by another task_started while the prior visible turn still had no terminal event.

This appears to be the same renderer/app-server conversation-correlation failure, but the user-visible outcome here is two orphaned "running" turns rather than only a reconnect banner. No prompts, transcripts, screenshots, account identifiers, conversation IDs, or full local paths are included.

pira22 · 9 days ago

Additional reproduction on the latest macOS desktop build.

Environment

  • ChatGPT/Codex Desktop: 26.814.41957
  • Release shown in About: Aug 17, 2026
  • Subscription: ChatGPT Pro
  • Platform: macOS
  • Observed: Aug 19, 2026

User-visible symptom

New chat creation intermittently fails with a toast containing an internal-looking object instead of an actionable error:

Error creating chat
{"value":{},"source":"owned","hooks":[],"promises":[]}

Fully quitting/reopening the app can temporarily restore operation, but the problem returns. The issue also returns after a full laptop reboot, so this is not just one stale process surviving a normal app quit.

Sanitized desktop-log sequence

The app-server can successfully route turn/start, but the renderer then reports the new conversation as unknown:

[AppServerConnection] ... method=turn/start ... errorCode=null
[electron-message-handler] Received turn/started for unknown conversation
[electron-message-handler] Failed to start visualization turn diff snapshot error={"value":{},"source":"owned","hooks":[],"promises":[]}
[electron-message-handler] Received turn/completed for unknown conversation
[electron-message-handler] pinned_thread_sync_failed error={"value":{},"source":"owned","hooks":[],"promises":[]}

The same affected session also produces repeated Browser/IAB route failures:

[browser-use-iab-api] ... errorMessage="No ChatGPT browser route is available for browser session ..."

and later repeated config/UI failures with the same malformed error object:

[electron-message-handler] Failed to load config requirements error={"value":{},"source":"owned","hooks":[],"promises":[]}

thread/list / thread/read and some configRequirements/read responses can still return successfully with errorCode=null while the renderer/UI is already in this inconsistent state.

Process observation

During an affected run there were 13 direct Codex (Renderer) children under the same desktop parent, with renderer client IDs increasing over the session. One renderer was using ~20% CPU at capture time. This may be related to the in-app Browser lifecycle, but I have not established renderer count as the root cause.

Notes

  • no git remotes found warnings are present in the same log but do not appear causal; the conversation-routing failures occur independently.
  • I intentionally omitted conversation IDs, local paths, and full raw logs for privacy.
  • The strongest signal remains: successful app-server turn routing followed immediately by Received turn/started for unknown conversation, after which multiple Desktop subsystems surface the same {"value":{},"source":"owned","hooks":[],"promises":[]} object.

This appears to show that the conversation-routing bug tracked here is still reproducible on 26.814.41957.

pira22 · 8 days ago

Follow-up from the same macOS 26.814.41957 reproduction: new-chat submission now surfaces a different user-facing error: Unable to send message — Permission mode is unavailable.

Targeted logs around the failure show the permission/config RPCs themselves can succeed, while renderer-side state later degrades:

[AppServerConnection] ... method=configRequirements/read ... errorCode=null
[AppServerConnection] ... method=permissionProfile/list ... errorCode=null

A resume event then shows inconsistent permission state in the renderer:

maybe_resume_success ...
derivedActivePermissionProfile=null
hasCurrentPermissions=false
hasExplicitPermissions=false
responseActivePermissionProfile=:workspace
responseApprovalPolicy=never
responseSandboxPolicy={"type":"workspaceWrite",...}

Later, the renderer repeatedly fails to load config requirements with the same internal-looking object seen in the earlier chat-creation failures:

Failed to load config requirements error={"value":{},"source":"owned","hooks":[],"promises":[]}

This repeats multiple times while configRequirements/read continues to succeed in other renderer/webContents contexts.

This suggests the new Permission mode is unavailable toast is likely another manifestation of the same Desktop renderer/session-state desynchronization: app-server permission/config endpoints are reachable, but the active renderer loses or fails to derive the permission profile required by the composer.

Raw logs and conversation IDs are omitted for privacy.