Codex.app hangs after Homebrew cask CLI upgrade while desktop app is running on macOS

Summary

Codex.app became unresponsive on macOS shortly after I ran:

brew upgrade --cask codex

while the Codex desktop app was already running with active local work.

macOS generated a hang stackshot for /Applications/Codex.app/Contents/MacOS/Codex. The app did not crash with a signal; it stayed alive but unresponsive for ~239 seconds before sampling.

Important nuance: the Homebrew cask named codex appears to install/update the standalone CLI binary, not the /Applications/Codex.app bundle itself. On this machine, the Homebrew CLI symlink was updated on May 20, 2026, while the app bundle timestamp remained May 16, 2026. So this report is framed as a possible Desktop app / standalone CLI / app-server or IPC interaction after a Homebrew cask CLI upgrade while Desktop is live, not as proof that Homebrew replaced the app bundle while it was running.

Environment

• Platform: macOS 26.5, Build 25F71
• Host architecture: arm64e
• Codex process architecture: arm64
• Hardware: Mac16,8
• Memory: 48 GB
• Codex app path: /Applications/Codex.app/Contents/MacOS/Codex
• Codex app identifier: com.openai.codex
• Codex app version from stackshot / Info.plist: 26.513.31313 (2867)
• Homebrew cask: codex 0.132.0
• Homebrew CLI path: /opt/homebrew/bin/codex
• Homebrew CLI target: /opt/homebrew/Caskroom/codex/0.132.0/codex-aarch64-apple-darwin

Local timestamps after the event:

May 16 13:30:56 2026  /Applications/Codex.app
May 16 13:30:54 2026  /Applications/Codex.app/Contents/Resources/codex
May 20 15:10:24 2026  /opt/homebrew/bin/codex

brew info --cask codex reports:

codex (Codex): 0.132.0
OpenAI's coding agent that runs in your terminal
Artifacts:
  codex-aarch64-apple-darwin -> codex (Binary)

Steps to reproduce

Observed once so far:

1. Start Codex.app on macOS.
2. Have Codex running local work / local project threads.
3. In a terminal, run:

``bash
brew upgrade --cask codex
``

1. Leave Codex.app open during/after the upgrade.
2. Codex.app becomes unresponsive.
3. macOS records a hang report / stackshot.

Actual behavior

Codex.app became unresponsive. macOS stackshot details:

Command:          Codex
Path:             /Applications/Codex.app/Contents/MacOS/Codex
Identifier:       com.openai.codex
Version:          26.513.31313 (2867)
Architecture:     arm64
Event:            hang
Duration:         240.24s
Duration Sampled: 1.30s (process was unresponsive for 239 seconds before sampling)

Target process details:

Process:          Codex [24813]
Path:             /Applications/Codex.app/Contents/MacOS/Codex
Identifier:       com.openai.codex
Version:          26.513.31313 (2867)
Architecture:     arm64
CPU Time:         0.009s
Note:             Unresponsive for 239 seconds before sampling
Num threads:      52

Main thread:

Thread 0x1d82c
DispatchQueue "com.apple.main-thread"(1)
Thread name "CrBrowserMain"
13 samples (1-13)
last ran 238.045s ago

The heaviest main-thread stack is in Electron/AppKit/status-bar UI and blocks on a synchronous dispatch wait:

-[NSStatusBarButtonCell drawWithFrame:inView:]
-[NSSystemStatusBar drawBackgroundInRect:inView:highlight:]
-[NSSceneStatusItem _setSelectedContentFrame:options:]
-[NSStatusItemScene updateSettings:transition:]
-[FBSScene _updateClientSettings:]
-[FBSScene _sendUpdate:]
-[FBSWorkspaceScenesClient scene:didUpdateClientSettings:withDiff:transitionContext:]
-[BSServiceDispatchQueue performAsyncAndWait:]
_dispatch_async_and_wait_f
_dispatch_async_and_wait_f_slow
__DISPATCH_WAIT_FOR_QUEUE__
_dispatch_event_loop_wait_for_ownership
kevent_id

CPU usage was low during sampling, so this does not look like a CPU-bound loop. It looks like the UI main thread was blocked in AppKit / status item update after the Homebrew cask CLI upgrade happened while the desktop app was active.

Expected behavior

Running brew upgrade --cask codex while Codex.app is open should not leave the desktop app permanently unresponsive.

Possible acceptable behaviors:

1. Codex.app detects the standalone CLI/cask changed and prompts the user to restart.
2. Desktop ignores the changed standalone CLI until restart, but does not deadlock.
3. Desktop/app-server/IPC handles version skew between the running app and standalone Homebrew CLI with a timeout/error path.
4. The Homebrew cask or Codex updater warns that Codex.app is running if that combination is unsupported.

Related issues checked

• #20025 is related but not the same. It reports the standalone Homebrew cask CLI hanging on startup while the Desktop app was running, likely around app-server/IPC/version mismatch. This report is about the Desktop app process itself becoming unresponsive after running brew upgrade --cask codex while Desktop was already open.
• #16158 is a broader Desktop app startup unresponsiveness issue, but it is not tied to a Homebrew cask CLI upgrade or this AppKit/status-item stack.
• #11090 is a broader Desktop UI freeze involving worker crashes, git/worktree errors, and orphaned app-server processes, but it does not cover this Homebrew cask upgrade sequence.
• #19291 is a Desktop launch/UI hang where backend handshake succeeds, but it is not tied to Homebrew cask upgrade or the AppKit status-item stack.
• #20283 covers AppleSystemPolicy/spctl/kernel-panic class failures. This stackshot does not show that class of failure.

I also searched for open issues containing NSStatusItemScene, NSStatusBarButtonCell, BSServiceDispatchQueue, and __DISPATCH_WAIT_FOR_QUEUE__ and did not find an existing matching issue.

Diagnostics available

I have a local macOS stackshot file, but it is a full system stackshot with many unrelated processes and local paths, so I did not attach it wholesale. I can provide a redacted target-process excerpt if useful.