macOS app quits on launch after update: managed app-server daemon stays on old version (0.143.0 vs bundled 0.147.0-alpha.6.5) -> initialize handshake timeout

Summary

After today's auto-update of the macOS Codex/ChatGPT desktop app, the app no longer launches: the window appears briefly, an update-related error may show, and the process exits. The root cause is a version mismatch between the updated app and the managed app-server daemon — the app bundle was updated to 0.147.0-alpha.6.5, but the managed standalone package at ~/.codex/packages/standalone/current still points to 0.143.0 (from July 8). The daemon never got updated alongside the app.

This looks like the underlying mechanism behind the recurring "can't launch after update" reports in #29040.

Environment

• macOS 15.7.3 (24G419), Apple Silicon (Mac15,6)
• App: /Applications/ChatGPT.app, bundle id com.openai.codex, version 26.803.41515 (build 6321)
• Bundled CLI: /Applications/ChatGPT.app/Contents/Resources/codex → codex-cli 0.147.0-alpha.6.5 (binary timestamp = time of this morning's update)
• Managed daemon: ~/.codex/packages/standalone/current → releases/0.143.0-aarch64-apple-darwin → codex-cli 0.143.0

Root cause

On launch the app spawns the bundled codex binary (stdio transport, argsCount=4), which routes through the managed app-server daemon. The daemon reports the mismatch:

{"status":"started","backend":"pid","managedCodexPath":"/Users/yanniskiefer/.codex/packages/standalone/current/codex","managedCodexVersion":"0.143.0","socketPath":"/Users/yanniskiefer/.codex/app-server-control/app-server-control.sock","cliVersion":"0.147.0-alpha.6.5","appServerVersion":"0.143.0"}

The old 0.143.0 app-server never answers the new client's initialize request, so the app times out after 30 s and aborts bootstrap:

[AppServerConnection] app_server_connection.state_changed cause=initialize_handshake_timeout connectionError={"code":"restart-required"} durationMs=30002 ...
[AppServerConnection] initialize_handshake_result outcome=failure errorMessage="Codex app-server initialize handshake timed out"
[AppServerConnection] fatal_error_broadcasted errorMessage="Codex app-server initialize handshake timed out"
Desktop bootstrap failed to start the main app phase=bootstrap-import-main

Notably, running the bundled binary standalone works fine — the same initialize handshake is answered immediately:

$ printf '%s\n' '{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"clientInfo":{"name":"debug","version":"0.0.1"}}}' | /Applications/ChatGPT.app/Contents/Resources/codex app-server
{"id":1,"result":{"userAgent":"debug/0.147.0-alpha.6.5 (Mac OS 15.7.3; arm64) ...","codexHome":"/Users/yanniskiefer/.codex",...}}

So the bundled binary is healthy; only the stale managed daemon version breaks the launch. Side observation: ~/.codex/app-server-daemon/ contains app-server-updater.pid.lock and daemon.lock dating from July 21 — possibly related to why the managed package was never bumped past 0.143.0.

Workaround (verified)

Point the managed standalone package at the binary from the updated app bundle:

CB="/Applications/ChatGPT.app/Contents/Resources"
REL="$HOME/.codex/packages/standalone/releases/0.147.0-alpha.6.5-aarch64-apple-darwin"
mkdir -p "$REL/bin" "$REL/codex-path"
ln -sfn "$CB/codex" "$REL/bin/codex"
ln -sfn "$CB/codex-code-mode-host" "$REL/bin/codex-code-mode-host"
ln -sfn "bin/codex" "$REL/codex"
ln -sfn "$CB/rg" "$REL/codex-path/rg"
ln -sfn "$HOME/.codex/packages/standalone/releases/0.143.0-aarch64-apple-darwin/codex-resources" "$REL/codex-resources"
# codex-package.json: same layout as 0.143.0, with "version": "0.147.0-alpha.6.5"

"$CB/codex" app-server daemon stop
ln -sfn "$REL" "$HOME/.codex/packages/standalone/current"
"$CB/codex" app-server daemon start

After this, daemon version reports appServerVersion: 0.147.0-alpha.6.5 (== cliVersion) and the app launches normally.

Expected behavior

When the desktop app updates, the managed app-server daemon package must be updated too (or the app should fall back to spawning its own bundled binary directly instead of relying on a potentially stale managed version), so that appServerVersion always satisfies the app's minimum. At minimum, a version mismatch should produce an actionable error instead of a silent 30 s handshake timeout followed by an exit.