Desktop: launch crash ("Something went wrong") caused by a persisted composer @-mention draft — at-mention-list TypeError reading 'match'

Open 💬 5 comments Opened Jun 21, 2026 by Lime-Cocoa

Environment

  • Codex App version: 26.616.51431 (build 4212)
  • Platform: macOS 26.5.1 — Darwin 25.5.0 arm64 arm
  • Subscription: ChatGPT Pro

What happens

On launch, Codex Desktop immediately shows the full-screen "Something went wrong" / "糟糕,出错了" error and is completely unusable — clicking Retry just throws again. It started right after the app auto-updated to 26.616.51431, so this is a regression (the previous version was fine).

How to reproduce

  1. In the composer (the message box of a new conversation), type @ followed by a letter — e.g. @r — to start an @-mention. Don't pick anything from the popup and don't send the message; just leave @r sitting in the box.
  2. Quit Codex while that unsent text is still in the composer.
  3. Reopen Codex.

➡️ It comes straight up to the "Something went wrong" screen and never loads the UI.

In short: any half-typed @-mention left in the composer when you quit will brick the app on the next launch.

Screenshot

<img width="1100" height="500" alt="Image" src="https://github.com/user-attachments/assets/a1f95f29-59b4-48da-9fa8-651fe56a2956" />

Workaround

Since the app won't open, you can't clear it from the UI. Quit Codex, then in ~/.codex/.codex-global-state.json set electron-persisted-atom-state.composer-prompt-drafts-v1 to {} (that's where the unsent composer draft is stored — mine held {"new-conversation":"@r"}). Back up the file first, then relaunch.

Technical details (for maintainers)

Renderer error, caught by the top-level AppRoutes error boundary:

TypeError: Cannot read properties of undefined (reading 'match')

React component stack (leaf first): at-mention-list → composer-top-menu-chrome → composer. On launch the saved draft is restored, the @-mention list re-renders for that query, and something on that code path calls .match() on an undefined value — which throws through the top-level error boundary and takes down the whole app.

Notes:

  • Reproduces with a clean --user-data-dir, so it isn't Chromium profile/cache corruption.
  • Independent of remote SSH hosts (crashes whether or not a remote connects).
  • An @r draft in an otherwise-empty CODEX_HOME doesn't crash on its own — it needs normal workspace/session data present so the @-mention list has items to render.

Expected behavior

A leftover/partial @-mention draft should render normally (or simply be ignored). It must never throw through the top-level error boundary and make the entire app unlaunchable — the @-mention list should guard the undefined value instead of calling .match() on it.

View original on GitHub ↗

5 Comments

18wu · 2 months ago

I have the same problem.

tallesairan · 2 months ago

i have same problem :(

tallesairan · 2 months ago

Has anyone found a possible solution yet?

Lime-Cocoa · 2 months ago
Has anyone found a possible solution yet?

Quit Codex, then in ~/.codex/.codex-global-state.json set electron-persisted-atom-state.composer-prompt-drafts-v1 to {} (that's where the unsent composer draft is stored — mine held {"new-conversation":"@r"}). Back up the file first, then relaunch.

kidroca · 29 days ago

Confirmed the same persisted atom-state startup lockout on Windows Store build 26.721.4979.0.

The app briefly rendered the sidebar/new-chat view and then entered the permanent “Oops, an error has occurred” screen. Repair, reinstall, Retry, and Update did not help.

Binary isolation confirmed that the failure followed electron-persisted-atom-state; projects, sessions, auth, plugins, config, and hooks were not responsible. Resetting only that object to {} in both:

  • %USERPROFILE%\.codex\.codex-global-state.json
  • %USERPROFILE%\.codex\.codex-global-state.json.bak

restored normal startup while preserving chats and projects.

Log signature:

error boundary errorMessage="" errorName=Error name=AppRoutes

When the exact malformed nested atom is unknown, clearing the complete electron-persisted-atom-state object is a safe broader workaround after backing up both files.