Codex Desktop renderer crashes after subagent wait with React #185 and unknown conversation state

Open 💬 2 comments Opened Jul 4, 2026 by malikdraz

What version of the Codex App are you using (From "About Codex" dialog)?

Codex App 26.623.101652, build 4674

Local evidence:

  • /Applications/Codex.app/Contents/Info.plist
  • CFBundleShortVersionString = 26.623.101652
  • CFBundleVersion = 4674
  • Sentry release: codex@26.623.101652

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Darwin 25.5.0 arm64 arm

Additional local context:

  • macOS 26.5.1, build 25F80
  • app arch: arm64

What issue are you seeing?

Codex Desktop shows the full-screen error boundary:

Oops, an error has occurred

with the buttons:

Update Codex and Try again

The app is already up to date, so the Update Codex action is misleading here. The failure appears to be renderer/session-state related, not an update problem.

This happened while reopening/inspecting a local Codex Desktop thread that had spawned multiple subagents. The affected parent thread id was:

019f2bac-7b89-7002-b960-fc3639bd5a3c

The relevant subagent ids were:

  • 019f2bd9-8906-7122-ac08-79cc2a0912a2
  • 019f2bd9-a7f7-7890-b852-68e142cf8a2a
  • 019f2bd9-c835-7893-b66f-0f0e6d9fabbf

Two subagents returned completion notifications. The third subagent stayed unresponsive through repeated wait_agent calls and was later closed. Around the same window, the renderer logged repeated unknown-conversation/state errors and then React error #185.

Local Sentry breadcrumb counts from ~/Library/Application Support/Codex/sentry/scope_v3.json:

  • 10 occurrences of Minified React error #185
  • 69 breadcrumbs matching unknown conversation or missing conversation state

Sample React error:

2026-07-04T06:40:47Z
Error: Minified React error #185; visit https://react.dev/errors/185 for the full message or use the non-minified dev environment for full errors and additional helpful warnings.
    at _e (app://-/assets/local-conversation-thread-CRryh-25.js:8:72757)
    at a (app://-/assets/app-initial~app-main~worktree-init-v2-page~remote-conversation-page~onboarding-page~hotkey-~ke3yc5wu-BLQiF1Gs.js:173:21245)

Sample unknown-conversation/state breadcrumbs:

2026-07-04T07:07:46Z [electron-message-handler] Received item/completed for unknown conversation conversationId=019f2bf2-f17b-7081-bb03-7a3f68e6b27b
2026-07-04T07:07:46Z [electron-message-handler] Conversation state not found conversationId=019f2bf2-f17b-7081-bb03-7a3f68e6b27b
2026-07-04T07:07:48Z [electron-message-handler] Received item/started for unknown conversation conversationId=019f2bf2-f17b-7081-bb03-7a3f68e6b27b

What steps can reproduce the bug?

I do not have a minimal deterministic repro yet, but this is the observed shape:

  1. Open Codex Desktop 26.623.101652 on macOS.
  2. Use a local thread that dispatches multiple subagents.
  3. In this case, the parent thread spawned three multi_agent_v1 explorer agents.
  4. Wait for subagent results with wait_agent.
  5. Two subagents complete and send <subagent_notification> messages.
  6. One subagent remains unresponsive through repeated waits.
  7. Reopen or navigate around the affected local conversation while this state exists.
  8. The renderer eventually shows the full-screen Oops, an error has occurred fallback with Update Codex and Try again.
  9. Local breadcrumbs show repeated unknown-conversation / missing conversation state errors and React error #185 in local-conversation-thread.

Relevant parent-thread lifecycle:

2026-07-04T06:38:24Z spawn_agent -> 019f2bd9-8906-7122-ac08-79cc2a0912a2
2026-07-04T06:38:32Z spawn_agent -> 019f2bd9-a7f7-7890-b852-68e142cf8a2a
2026-07-04T06:38:40Z spawn_agent -> 019f2bd9-c835-7893-b66f-0f0e6d9fabbf
2026-07-04T06:39:16Z wait_agent on all three, timeout 240000ms
2026-07-04T06:40:51Z wait_agent on remaining two, timeout 240000ms
2026-07-04T06:42:08Z wait_agent on remaining one, timeout 240000ms
2026-07-04T06:49:17Z wait_agent on remaining one, timeout 60000ms
2026-07-04T06:51:12Z close_agent on all three

The third sidecar session file existed but only had four JSONL lines and did not produce a normal assistant/tool response before shutdown.

What is the expected behavior?

Codex Desktop should keep the parent thread renderable even if a subagent stalls, emits late notifications, or has an incomplete sidecar session.

More specifically:

  • A stalled or closed subagent should not poison the parent LocalConversationThread render path.
  • Events for unknown conversation ids should be ignored, quarantined, or attached only after the conversation is registered.
  • React #185 should not reach the app-wide error boundary.
  • The full-screen fallback should not suggest Update Codex when the installed app is already current.
  • Try again should recover the view or provide a useful diagnostic instead of looping back to the same crash.

Additional information

This looks related to, but not exactly the same as, several existing reports:

The closest overlap appears to be the combination of:

  • subagent/session state corruption
  • unknown conversation routing
  • local conversation renderer crash
  • misleading full-screen Update Codex / Try again fallback

I can provide a redacted screenshot of the fallback screen and sanitized local breadcrumb snippets if useful.

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗