Codex Desktop intermittently crashes/resets on macOS with auth_elicitation feature mismatch and unknown conversation state #23725

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   app-serverIssues involving app server protocol or interfacesIssues involving app server protocol or interfaces

   on May 20, 2026
2. github-actions commented on May 20, 2026

   

   github-actionsbot

   on May 20, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Codex Desktop: composer submit times out after stale conversation state accumulates; restart clears it #23644
   • Codex Desktop Windows: orphan task_started without task_complete poisons thread reopen and crashes LocalConversationPage #23035
   • Codex App crashes after left-click, right-click, left-click on toolbar #22933

   Powered by Codex Action
3. jjhuang2023 commented on Jun 14, 2026

   

   jjhuang2023

   on Jun 14, 2026 – with ChatGPT Codex Connector

   More actions

   Additional current repro/evidence from another macOS arm64 install. This still looks like the same renderer reset / conversation-state desync class, but on a newer Desktop build.

   Environment observed locally:

   • Codex Desktop: 26.609.41114 (CFBundleVersion 3888)
   • Chromium base: 149.0.7827.54
   • CLI on PATH: codex-cli 0.139.0
   • Platform: macOS arm64
   • Date observed: 2026-06-14

   What I observed:

   • The main Codex process had been alive since 2026-06-13 12:32:32 CST, so the user-visible "restart" did not appear to be a full app-process restart.
   • There was a fresh Crashpad minidump at about 2026-06-14 11:53:02 CST under ~/Library/Application Support/com.openai.codex/web/Crashpad/pending/.
   • The Crashpad sidecar for that dump was:

   {"osarch":"arm64","ptype":"renderer"}

   • Around the same timestamp, the desktop log showed normal thread/sidebar hydration calls such as thread/list, thread/read, thread/goal/get, and thread/resume, followed by repeated state mismatch messages:

   Received item/completed for unknown conversation
   Received item/started for unknown conversation
   Conversation state not found
   Received turn/completed for unknown conversation
   

   • There was also Statsig: error while bootstrapping post-login client with user.custom.workspace_type being null, though I do not know whether that is causal or just adjacent startup noise.
   • The install also had helper-process amplification at the time of inspection: multiple SkyComputerUseClient and node_repl processes, plus repeated screen-capture churn:

   screen capture display enumeration timed out after 5 seconds
   capture session exited; delaying restart
   No shareable content available: Content unavailable: user declined TCC capture
   

   One related local detail: this machine also has a persisted goals_1.sqlite.thread_goals row with status = blocked, matching the separate renderer-crash class reported in #26784. That blocked row is old, so I am not claiming it caused the 2026-06-14 11:53 renderer dump, but it may be another way to trigger or poison the same renderer/session state path.

   User-visible symptom:

   • Codex appears to restart/reset by itself.
   • Side conversations disappear or the sidebar loses conversation state after the reset.
   • After a recent update, the sidebar now appears to show all conversations again; previously it only showed roughly the first 50. That part seems improved, but the renderer reset / unknown-conversation state mismatch still reproduced on this build.

   Privacy note: I am not attaching raw logs, minidumps, or session JSONL publicly because they contain local paths and private conversation metadata. The details above are the sanitized signatures from the local logs.
4. linear commented on Jun 14, 2026

   

   linearbot

   on Jun 14, 2026 – with Linear

   More actions

   from lxing:

   Slack triage update from #demo-infra on 2026-06-14.

   Reporter: Alex Christiansen / alexc
   Urgency: demo-blocking; user needs Codex Public build for a demo tomorrow.

   User-visible symptom:

   • Codex Demo Platform / Codex Public build freezes after every prompt.
   • Restarting several times and using the latest build did not resolve it.
   • User says they cannot use the Codex demo platform at all.

   Forwarded local log analysis from Codex Alpha:

   • Public created conversation 019ec878-52c2-78c1-b5c6-6122e3fd982f.
   • turn/start was accepted for that conversation.
   • About four seconds later, the app received turn/started and turn/completed for a different conversation: 019ec87b-4a06-75c0-bf57-94549f62e463.
   • Renderer logged Received turn/started for unknown conversation and Received turn/completed for unknown conversation.
   • Result: backend appears to complete a turn, but UI discards the events and keeps waiting on the original active conversation.

   This looks like the same conversation-state desync class tracked here, now specifically blocking Codex Public demo use through the demo platform.
5. nachoal commented on Jul 16, 2026

   

   nachoal

   on Jul 16, 2026 – with ChatGPT Codex Connector

   More actions

   Additional deterministic macOS multi-window repro and local root-cause evidence from a current build.

   Environment

   • Codex Desktop / ChatGPT macOS app: 26.707.72221 (bundle build 5307)
   • Bundle ID: com.openai.codex
   • macOS 26.5.2 (25F84), Apple Silicon (arm64)
   • 128 GB RAM
   • Observed 2026-07-15/16

   Deterministic trigger

   1. Keep six primary Codex windows open, each on a different thread; some threads may still have active/background work.
   2. Press Cmd+Shift+N to open a seventh primary window.
   3. The new window opens normally.
   4. Within roughly 25–50 seconds, 2–4 pre-existing windows reload/reset (three in the captured incident).
   5. The underlying threads continue in app-server/session state, but the affected windows lose the thread route they were displaying. The user cannot navigate back unless they remember which threads those windows owned.

   This causes significant productivity/context loss and is not backend thread deletion.

   Captured incident timeline

   The same Desktop main process remained alive throughout. Sanitized desktop-log chronology:

   05:07:55.115Z  created/loaded new primary window: windowId=62 webContentsId=67
   05:07:57.636Z  new window renderer routes mounted
   05:08:20.260Z  existing windowId=23 webContentsId=24 renderer routes mounted again
   05:08:45.251Z  existing windowId=17 webContentsId=17 renderer routes mounted again
   05:08:47.304Z  existing windowId=45 webContentsId=49 renderer routes mounted again
   

   The three existing-window remounts reused the same BrowserWindow/webContents IDs and had no corresponding new-window creation records, so these were renderer reloads rather than intentional window replacement.

   Crashpad created three matching sidecars:

   {"osarch":"arm64","ptype":"renderer"}

   • one at local 23:08:17
   • two at local 23:08:42

   This matches the one-then-two renderer remount sequence above.

   Confirmed immediate cause

   Read-only inspection of the exact packaged app build shows:

   • Cmd+Shift+N creates a fresh BrowserWindow; there is no six-window cap, reuse, or intentional eviction path.
   • Every window installs a render-process-gone handler.
   • For a non-clean renderer exit, the recovery path reports a fatal event and calls webContents.reload() after 500 ms.
   • That reload path does not durably preserve and restore the affected window's current thread route before recovery.

   Therefore the visible reset/context loss is explained by three existing renderer processes crashing, followed by the app's automatic blind reload of those renderers. The app-server and threads keep running, but the renderer/window-to-thread mapping is lost.

   After the reloads, logs also contain the familiar secondary state-desynchronization signatures:

   Received item/started for unknown conversation
   Received item/completed for unknown conversation
   Conversation state not found
   Item not found in turn state
   

   The renderer code keeps an independent conversation map per window, while app-server events are broadcast to all renderer windows. After a renderer reload, events can therefore arrive before that window has rehydrated the relevant conversation.

   What is not yet proven

   The lower-level reason Chromium/Electron terminated these renderers is not recoverable from the remaining local artifacts:

   • the main process sends render-process-gone reason/exit code to Sentry but does not write it to the durable plaintext Desktop log;
   • Crashpad retained only renderer sidecars, not the local minidumps.

   Post-incident renderer RSS was unusually high (roughly 1.3–2.8 GB per renderer), so renderer-local memory exhaustion or another Chromium/Electron renderer defect is plausible. This is not enough to claim memory as the root trigger, especially because the 128 GB system still reported substantial free memory when inspected.

   Suggested fix/instrumentation

   1. Persist each window's current route/thread ID in the main process (keyed by BrowserWindow) and restore it after renderer reload.
   2. Durably log render-process-gone reason, exit code, window ID, and webContents ID before Sentry upload.
   3. On renderer recovery, rehydrate the displayed conversation/active turn before applying queued events; do not drop events merely because the renderer-local conversation map is not ready.
   4. Investigate whether broadcasting all app-server events and duplicating full conversation state in every renderer is driving per-window memory growth.
   5. Add a regression test with seven primary windows: open a unique thread in each, simulate three renderer exits, and verify every window returns to its previous thread while backend work remains visible.

   This appears to be the same renderer-reset/conversation-state-desync class already tracked here, with a new deterministic multi-window trigger. It is also related to #24263, but that report is Windows-specific and does not identify opening a seventh window as the trigger.

   Privacy note: raw logs/session files are not attached because they contain local paths and private thread metadata. Sanitized excerpts or exact timestamps can be provided privately if useful.