Codex App update left old crashpad helper; relaunch could no-op until clean restart

What version of the Codex App are you using?

Installed app version from /Applications/Codex.app metadata:

26.527.31326

A stale helper process was still annotated as the previous version:

_version=26.519.81530

What platform is your computer?

macOS 26.4.1 (25E253)
Darwin 25.4.0 arm64

What issue are you seeing?

After a Codex Desktop auto-update, launching Codex from the app icon could appear to do nothing: no usable window came up, while old Codex-related helper processes were still present. A clean launch via open -a Codex restored the app, and the current main process/app-server/renderer came up normally.

The notable local evidence is that after the app was already updated to 26.527.31326, an old crashpad helper from 26.519.81530 was still alive and orphaned under launchd:

PID   PPID  STARTED                         ELAPSED       COMMAND
1723  1     Fri May 29 19:02:52 2026        01-00:17:38   /Applications/Codex.app/Contents/Frameworks/Electron Framework.framework/Helpers/chrome_crashpad_handler ... --database=/Users/mac/Library/Application Support/Codex/Crashpad ... --annotation=_productName=Codex --annotation=_version=26.519.81530 ...

Current post-recovery app processes were from the new app install:

15217  1      Sat May 30 19:13:04 2026  /Applications/Codex.app/Contents/MacOS/Codex
15277  15217  Sat May 30 19:13:07 2026  /Applications/Codex.app/Contents/Resources/codex app-server --analytics-default-enabled

There was also a live extension-host process:

14535  1555  Sat May 30 19:11:14 2026  /Users/mac/.codex/plugins/cache/openai-bundled/chrome/latest/extension-host/macos/arm64/extension-host chrome-extension://...

I am not claiming the crashpad helper is definitely the process holding Electron's single-instance lock. The observed user-visible behavior is consistent with stale instance/router/lifecycle state after update, and the leftover old-version crashpad helper is a concrete signal that the update/quit path did not fully clean up Codex-owned child/helper processes.

Local log DB evidence

~/.codex/logs_2.sqlite is valid but large:

$ du -h ~/.codex/logs_2.sqlite
728M    /Users/mac/.codex/logs_2.sqlite

$ sqlite3 ~/.codex/logs_2.sqlite 'PRAGMA integrity_check; SELECT count(*) FROM logs;'
ok
254104

This may be separate from the launch-no-op symptom, but it matches other reports where logs_2.sqlite growth/corruption contributes to startup or performance problems.

Steps to reproduce

I do not have a deterministic reproduction yet. The sequence was approximately:

1. Use Codex Desktop normally across an app auto-update from 26.519.81530 to 26.527.31326.
2. Quit/relaunch Codex.
3. Launching from the app icon appeared to do nothing/no window appeared.
4. Inspect processes and observe stale Codex helper process from the previous version.
5. Run open -a Codex; the app then launched successfully.

Expected behavior

After auto-update or quit/relaunch:

• old-version Codex helper/child processes should not survive indefinitely;
• a stale helper/router/single-instance state should not make the app appear to launch with no window;
• if another instance/router is active, the app should either focus the existing window or show a user-facing recovery/error state;
• rebuildable log state such as logs_2.sqlite should not permanently block startup if it is corrupt, and large log DBs should be bounded/rotated.

Related issues

This looks related to, or at least in the same failure family as:

• #23917: update followed by app restart failure with logs_2.sqlite corruption
• #24001: logs_2.sqlite corruption prevents app-server readiness
• #11324: Codex App process/MCP cleanup gaps, including orphaned chrome_crashpad_handler after quit
• #12974: background/no-UI launch with Another router is active on Windows
• #20213 / #21134: large logs_2.sqlite and TRACE log churn impacting performance