Support externally managed app-server daemon executables

What variant of Codex are you using?

Codex CLI 0.150.1 and the app-server daemon on macOS and Linux. The reproductions use externally managed installations from Nix, Homebrew, npm, or a release archive rather than the Codex standalone installer.

What feature would you like to see?

Please support an externally managed app-server daemon executable without requiring the standalone installer to own $CODEX_HOME/packages/standalone/current/codex.

An externally managed installation needs two related controls:

1. An explicit way for a package manager or wrapper to provide the Codex executable that daemon Start launches. This could be configuration, an environment variable, or install-context integration.
2. An external ownership mode in which daemon Bootstrap does not download or run the standalone installer. It should either use the external executable without updating it or return an actionable error that leaves updates to the package manager.

The official standalone behavior can remain the default when no override is configured.

Additional information

Current behavior

codex agents invokes daemon Start. If no daemon already responds on the Unix socket, the daemon resolves its executable only as:

$CODEX_HOME/packages/standalone/current/codex

As a result, a functional Codex binary installed elsewhere fails with:

Error: managed standalone Codex install not found at .../packages/standalone/current/codex

The current source still constructs that fixed path in managed_install.rs. The released 0.150.1 CLI routes codex agents through daemon Start in main.rs.

Manually starting the same packaged binary with codex app-server --listen unix:// makes codex agents work because the socket probe succeeds first. Providing a compatibility link at the fixed path also works. I verified daemon start, version reporting, stop, and the complete codex agents startup using the Nix-packaged 0.150.1 binary.

This shows that the packaged executable can serve app-server correctly. The failure is the install-layout requirement, not a missing runtime component.

Why a package-manager contract helps

External package managers already own the executable and its update lifecycle. Asking each integration to synthesize a mutable standalone layout under the user's home directory creates competing ownership:

• Nix packages are immutable and updated through Nix generations.
• Homebrew, npm, and archive installations have their own layouts.
• The daemon Bootstrap lifecycle may run the standalone installer and replace current, crossing the external package manager's ownership boundary.

A supported executable override plus external update policy would let these packages use daemon-backed commands without maintaining a second Codex installation or mutating user state on every invocation.

Suggested acceptance behavior

• Daemon Start uses the configured external executable when present.
• Existing executable identity and version validation still apply.
• Daemon Bootstrap never invokes the standalone installer in external ownership mode.
• Official standalone installs retain their current managed update behavior by default.
• A focused test starts and stops the daemon from an executable outside packages/standalone/current and confirms that no installer is invoked.

Related reports

• #41187: codex agents fails with Homebrew
• #24283: Homebrew remote-control lacks the standalone layout
• #26459: the official package archive lacks the expected layout
• #24034: npm can start a stale, separately managed standalone app-server
• codex-cli-nix #145: Nix reproduction, source analysis, and verified compatibility workaround