Codex Desktop: orphaned app-server from stale Sparkle path + AppKit menu inconsistency leads to crash on project resume

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

Version 260208.1016 (571)

What subscription do you have?

Pro

What issue are you seeing?

Codex Desktop becomes unstable when resuming sessions in one specific local monorepo (<project-root>), with very high CPU, repeated short-lived git probes, and eventual app crash.

I found two likely-related issues:

• #11090 (orphaned app-server + git/worktree churn)
• #11188 (app crashes on certain projects)

This report adds a specific process-leak signature and timeline.

What steps can reproduce the bug?

1. Launch Codex.app on macOS.
2. Resume an existing session whose cwd is a large monorepo (<project-root>).
3. Keep the app open and switch focus a few times.
4. Observe CPU spikes, repeated git child-process failures in breadcrumbs, and eventual crash/abort.
5. After crash/relaunch, observe old codex app-server processes still alive with PPID=1.

What is the expected behavior?

• Desktop app should remain stable when resuming in large repos.
• Old app-server processes should be cleaned up on crash/restart/update.
• No concurrent writers should hold the same rollout session file.

Additional information

Environment:

• macOS 26.2 (25C56), Apple Silicon
• Codex Desktop app (com.openai.codex)

Observed crash signals:

• launchd logs show repeated self-aborts (SIGABRT) by Codex.

Observed AppKit errors before/around failures:

• Internal inconsistency in menus
• Unable to find className=(null)
• (Earlier run) A menu item's height should never be 0

Observed process leak pattern:

• Multiple codex app-server --analytics-default-enabled remained alive as orphans (PPID=1).
• At least two orphaned app-server processes were from stale Sparkle installation cache paths (older binary), while current app also had a live app-server.
• Two orphaned processes held write handles to the same rollout JSONL simultaneously (same inode), suggesting concurrent writers after crash/restart cycles.

Observed git probe failures (from app breadcrumbs):

• Repeated git child process exits (code 1, code 128), including subcommand=config,args=3 failures shortly after startup and on refocus.

Privacy/sanitization note:

• I intentionally redacted user identity, local absolute paths, project/repo names, email, session IDs, and account identifiers.
• I can provide private full logs to maintainers on request.