›_ Codex Issues
Codex Issues / #24283

Homebrew cask install exposes remote-control but lacks the required standalone layout

Open 💬 3 comments Opened May 24, 2026 by lexluthor0304
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

codex remote-control is exposed by the Codex CLI installed through the Homebrew cask, but the command cannot start because it requires the standalone install layout managed by the official Codex installer.

This makes the Homebrew-installed CLI look like it supports remote control, while the actual daemon startup path only works when ~/.codex/packages/standalone/current/codex exists.

Environment

  • macOS: arm64
  • Codex CLI: codex-cli 0.133.0
  • Install method: Homebrew cask
  • which codex: /opt/homebrew/bin/codex
  • Homebrew binary target: /opt/homebrew/Caskroom/codex/0.133.0/codex-aarch64-apple-darwin

Reproduction

  1. Install Codex through Homebrew cask.
  2. Confirm the installed binary:
which codex
ls -l /opt/homebrew/bin/codex
brew info --cask codex
brew list --cask codex

Observed Homebrew layout:

/opt/homebrew/bin/codex -> /opt/homebrew/Caskroom/codex/0.133.0/codex-aarch64-apple-darwin

brew list --cask codex shows only the cask metadata and one binary artifact:

/opt/homebrew/Caskroom/codex/0.133.0/codex-aarch64-apple-darwin
  1. Run:
codex remote-control

Observed first-level error:

Starting app-server with remote control enabled...
Error: Remote control is enabled on <host> but the connection is errored.
  1. Run the explicit start command:
codex remote-control start

Observed root cause:

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

This command requires the standalone install managed by the Codex installer, because the daemon starts and updates app-server from that fixed path.

Install it with:
  curl -fsSL https://chatgpt.com/codex/install.sh | sh

Then rerun the command you just tried.

Expected behavior

One of the following should happen:

  1. The Homebrew cask should install the managed standalone layout required by remote-control; or
  2. remote-control should support the Homebrew cask binary layout; or
  3. The Homebrew-installed CLI should not expose remote-control as a usable command unless the standalone install is present; or
  4. The top-level codex remote-control error should immediately explain that the Homebrew cask install is unsupported for this command and point to the official installer.

Actual behavior

The Homebrew-installed CLI exposes codex remote-control, but the command fails because the standalone path does not exist:

~/.codex/packages/standalone/current/codex

Creating the directory manually is not a real fix because the daemon appears to rely on the managed standalone release/current layout and update mechanism created by the official installer.

Why this is confusing

For users, Homebrew appears to be an official supported install path. After installing Codex with Homebrew, codex remote-control --help advertises the feature:

[experimental] Manage the app-server daemon with remote control enabled

But the command is effectively unusable until the user installs Codex again using the standalone installer. That makes the Homebrew installation only partially functional for CLI features that depend on the managed standalone layout.

Requested fix

Please make the installer behavior consistent across supported installation paths, or document and enforce the limitation clearly.

The most useful fixes would be:

  • support remote-control from the Homebrew cask layout, or
  • update the Homebrew cask to install/create the managed standalone layout, or
  • make codex remote-control detect Homebrew immediately and show a clear actionable message before trying to start the daemon.

Related but not identical issue: #20595 asks for a first-class standalone installer. This issue is specifically about the current Homebrew cask exposing a command that requires the standalone installer layout.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 3 months ago

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

  • #24034

Powered by Codex Action

yui-stingray · 3 months ago

I traced the daemon-start path in openai/codex@7d47056, and the codex remote-control start failure mode appears to match this report. The top-level CLI routes remote-control into remote_control_cmd::run; the start subcommand then goes through the app-server daemon path, which resolves the managed binary as CODEX_HOME/packages/standalone/current/codex in codex-rs/app-server-daemon/src/managed_install.rs. codex-rs/app-server-daemon/src/lib.rs hard-fails when that managed binary is missing.

One extra data point: codex-rs/install-context/src/lib.rs classifies macOS /opt/homebrew / /usr/local installs as InstallMethod::Brew only after the standalone layout check, so I do not see a guard or fallback in this daemon-start path that would make the Homebrew cask layout satisfy the managed standalone requirement. This looks closely related to #24034, but the cask-specific mismatch described here still seems useful to track explicitly.

leehuiseok · 1 month ago

I hit a related case from the CLI/browser-backend side: a non-standalone codex command can run normally, but codex app-server daemon start fails with:

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

In that state, daemon-backed browser backend discovery from the CLI stays empty even when the Chrome extension/native host checks are healthy. Installing through the standalone installer and starting the daemon fixes the CLI browser backend discovery path.

I prepared a small diagnostic improvement here:

https://github.com/leehuiseok/codex/tree/codex/clarify-standalone-daemon-error

The change clarifies that npm, Homebrew, or bundled app codex commands can still run Codex, but daemon-backed workflows such as remote control and browser backend discovery require the standalone layout. It also adds a regression test for the error text.

Validation:

  • cargo fmt --check
  • cargo test -p codex-app-server-daemon

I could not open an upstream PR from the fork because this repository currently reports pull_request_creation_policy: collaborators_only, so I am leaving the branch here as a concrete patch reference.