Codex macOS updater can get stuck after clicking Update, leaving Codex, Autoupdate, and Updater.app idle without restarting

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

• #15596

Powered by Codex Action

That's not a duplicate and I'm seeing this as well over the last 10 days or so.

Apple Silicon M2 Pro and update just hangs - eventually you have to quit it and then it will relaunch but will still be on the same version: 26.417.40842 (1851)

I am experiencing this too

I hit what looks like the same failure mode on macOS: after clicking Update, the Codex window disappears, but the app process stays alive. Quitting Codex manually with Cmd+Q and launching it again restores normal behavior.

I could not find the desktop UI / Sparkle wrapper source in this public repo, so the following is based on inspecting the packaged Electron bundle from /Applications/Codex.app rather than a source checkout. In the installed app I checked (26.513.20950, build 2816), the macOS update path appears to be:

1. renderer sends install-app-update
2. main process calls sparkleManager.installUpdatesIfAvailable()
3. the Sparkle wrapper invokes onInstallUpdatesRequested before native installUpdatesIfAvailable()
4. the app calls app.quit()

The suspicious part is that on macOS this goes through the normal Electron quit lifecycle. The update path calls allowQuitTemporarilyForUpdateInstall(), but does not set its skipDrainBeforeQuit option. The will-quit handler then preventDefault()s the first quit, disposes some lifecycle managers, waits for all global state flushes, and only then calls app.quit() again.

That means if one of those flushes stalls, or if the second quit happens after the temporary update quit allowance expires, Sparkle can be left waiting for the app process to exit while Codex has already hidden/destroyed its visible window. That matches the observed “app is still running, but no window comes back until manually quitting” behavior.

A likely fix would be to make the update-install quit path bounded or update-specific, for example by passing skipDrainBeforeQuit: true when quitting for Sparkle install on macOS, or by adding a timeout/fallback around the will-quit drain before forcing process exit for update installation. I have not been able to validate this with a local patch because the desktop wrapper source/build pipeline does not appear to be public.

I hit a related updater failure on macOS, but the local evidence points to a failed Sparkle download path rather than a downloaded delta/package being stuck during handoff.

Environment:

• Codex App: 26.513.20950 (CFBundleVersion 2816)
• Bundle ID: com.openai.codex
• Platform: Darwin 25.4.0 arm64 arm
• Sparkle is enabled (SUAutomaticallyUpdate = 1, SUEnableAutomaticChecks = 1)
• App bundle contains both Sparkle.framework and Squirrel.framework

Observed behavior:

• The update button appears.
• Clicking it can make the app disappear/quit, but the update is often not installed and Codex does not reliably relaunch.
• Repeating the flow several times eventually succeeds.

Local updater logs show repeated Sparkle download failures for the current package URL:

2026-05-15T00:45:45.983Z error [sparkle] Update failed to download: Error Domain=NSURLErrorDomain Code=-1001 "The request timed out."
NSErrorFailingURLStringKey=https://persistent.oaistatic.com/codex-app-prod/Codex-darwin-arm64-26.513.20950.zip

2026-05-15T00:45:46.006Z error [sparkle] Update aborted with error: Error Domain=SUSparkleErrorDomain Code=2001 "An error occurred while downloading the update. Please try again later."

The same pattern repeated at roughly 2026-05-15T02:01:31Z, 03:18:37Z, 04:03:55Z, and 04:33:44Z. Earlier logs on May 14 show the same NSURLErrorDomain Code=-1001 timeout for the same zip.

The Sparkle cache directory exists but has no persisted update payload after these failures:

~/Library/Caches/com.openai.codex/org.sparkle-project.Sparkle/Launcher
~/Library/Caches/com.openai.codex/org.sparkle-project.Sparkle/Installation
~/Library/Caches/com.openai.codex/org.sparkle-project.Sparkle/PersistentDownloads

I also checked the package URL directly afterward and it was reachable with HTTP 200, content-type: application/zip, and content-length: 346479191, so the artifact itself was not missing at that point.

This looks like the updater UI/relaunch flow is not robust to download failure/timeouts. Expected behavior would be for Codex to only offer the install/restart action after Sparkle has a verified downloaded package, or to keep the app open and show a retryable error when the download aborts. If the app does quit for an update install, it should either relaunch after a successful install or surface a clear recovery path when the install did not happen.