Remote Control app-server survives Homebrew upgrade from `.upgrading` path, causing stale `codex-code-mode-host` spawn failure

Summary

On macOS, a long-lived Codex Remote Control app-server can survive a Homebrew Cask upgrade after being launched from Homebrew's transient .upgrading directory. After the upgrade completes and that directory is removed, the old app-server continues running and later fails to spawn codex-code-mode-host because it resolves the helper relative to the stale install path.

This manifests when controlling a Mac ChatGPT/Codex session remotely from the iPhone ChatGPT app.

Environment

• macOS on Apple Silicon
• ChatGPT Desktop: latest version at time of report
• Bundled Codex: codex-cli 0.153.4
• Homebrew Cask Codex current version: 0.153.4
• Remote Control used from the iPhone ChatGPT app

Current Homebrew installation is complete:

/opt/homebrew/Caskroom/codex/0.153.4/bin/codex
/opt/homebrew/Caskroom/codex/0.153.4/bin/codex-code-mode-host

/opt/homebrew/bin/codex resolves correctly to:

/opt/homebrew/Caskroom/codex/0.153.4/bin/codex

CODEX_CLI_PATH is not set in either the shell or launchctl environment.

Error

Remote Code Mode reported:

failed to spawn code-mode host /opt/homebrew/Caskroom/codex/0.153.0/bin/codex-code-mode-host: No such file or directory (os error 2)

However, the current 0.153.4 installation contains codex-code-mode-host normally.

Root cause evidence

A stale Remote Control app-server had been running for several days:

2330  2322  Fri Sep 4 10:02:53 2026  codex -c features.code_mode_host=true app-server --listen unix://

Inspecting the executable mapped into that running process with lsof showed:

codex 2330 ... txt REG ... /opt/homebrew/Caskroom/codex/0.153.0.upgrading/bin/codex

So the Remote app-server had actually been launched while Homebrew was in the middle of upgrading Codex and the Cask directory had temporarily become:

/opt/homebrew/Caskroom/codex/0.153.0.upgrading/bin/codex

After the Homebrew upgrade completed, the transient/old directory was removed and the current installation became 0.153.4, but the old app-server process continued to run.

Later, when Code Mode was invoked through Remote Control, that stale process attempted to launch the sibling codex-code-mode-host from the old 0.153.0 installation path and failed with os error 2.

Expected behavior

A Remote Control / persistent app-server should not remain bound to a transient Homebrew .upgrading executable path after the package is replaced.

Possible expected behaviors:

1. Detect that the executable/runtime backing the daemon has been replaced or removed and restart the app-server.
2. Pin/copy a stable managed runtime before launching a persistent Remote Control daemon.
3. Avoid launching a long-lived app-server from a Homebrew .upgrading path.
4. Resolve codex-code-mode-host from a stable runtime location rather than a path that can disappear during package upgrades.

Actual behavior

The app-server survives the Homebrew upgrade and remains alive even though its original executable path no longer exists on disk. Code Mode later fails when attempting to spawn its sibling helper.

Workaround

Terminating the stale Remote app-server and its bootstrap parent fixes the issue:

kill -TERM 2330
kill -TERM 2322

After restarting/reconnecting Remote Control, the stale 0.153.0 / .upgrading references disappear and current ChatGPT Desktop app-servers use:

/Applications/ChatGPT.app/Contents/Resources/codex
/Applications/ChatGPT.app/Contents/Resources/codex-code-mode-host

The Homebrew installation also remains healthy at 0.153.4.

Related issues

This seems related to reports of Remote/app-server version skew and Code Mode host path issues, including #31835 and #31907, but this case specifically captures the Homebrew .upgrading race/lifecycle condition with direct lsof evidence.

Start at the Remote Control app-server launch and lifecycle entry points, then trace how the code-mode host path is resolved relative to the running executable. Reproduce the Homebrew .upgrading scenario and verify that a persistent app-server no longer retains a removed runtime path or fails to spawn the current codex-code-mode-host.