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

Open 💬 3 comments Opened May 24, 2026 by lexluthor0304

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 ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗