The Codex CLI is a terminal‑based interface for interacting with OpenAI’s Codex model. Beginning with version 0.157.0, simply opening an interactive codex session triggers the automatic launch of a persistent background daemon (codex app‑server --managed‑daemon). According to the GitHub issue tracking this behavior, the daemon copies the entire platform package—approximately 374 MB containing the codex binary, codex‑code‑mode‑host, and bundled tools like bwrap, zsh, and rg—into a versioned directory under ~/.codex/packages/app‑server‑daemon/releases/. It then runs the daemon from that copy, effectively decoupling the executing backend from the version the user installed via their package manager.
This image shows the GitHub issue that describes the automatic background daemon launch and user concerns about environment pinning and uncontrolled updates.
Once started, a detached updater process (codex app‑server daemon pid‑update‑loop) checks for updates five minutes after launch and then hourly, downloading new releases and restarting the backend, which can kill active turns and cannot be disabled through the daemon’s stop command. The daemon also pins the environment of the session that started it; for example, any HTTPS_PROXY set in that first session is retained and used for all subsequent daemon‑spawned connections, regardless of later sessions’ settings. Additionally, hooks that run in remote mode receive the daemon’s working directory instead of the client’s, and they cannot determine the client terminal, breaking terminal‑targeting functionality.
Users report that stopping the daemon with `codex app‑server daemon stop` leaves the updater loop still running, requiring a manual kill (e.g., pkill -f 'app‑server daemon pid‑update‑loop') and cleanup of the ~/.codex/packages/app‑server‑daemon directory to prevent reaccumulation of old versions, which can occupy several gigabytes of disk space over time. Because the daemon runs independently of the CLI binary managed by npm, brew, or pacman, users feel the tool behaves like unwanted software that modifies the system without clear consent. The issue requests that daemon_auto_start be made opt‑in (default false) or at least prompt the user once before enabling the background service.