Codex CLI 0.157.0 Auto-Start Daemon Sparks User Backlash

What changed in Codex CLI 0.157.0

Since version 0.157.0, opening an interactive Codex CLI session automatically starts a persistent background daemon (codex app-server --managed-daemon). The process runs in its own session with no TTY, survives after all Codex windows are closed by being reparented to PID 1, and keeps running until the user executes codex app-server daemon stop or reboots the machine.

The daemon copies the entire platform package, roughly 374 MB including codex, codex-code-mode-host and bundled bwrap, zsh and rg, into ~/.codex/packages/app-server-daemon/releases/<version>/ and runs from that copy. As a result, the backend version becomes decoupled from the CLI version installed through the user's package manager. A detached updater process (codex app-server daemon pid-update-loop) checks for updates five minutes after start and then hourly, downloading new releases and restarting the backend, which can terminate active turns (issue #40969).

User complaints and workarounds

Issue #48195, opened on September 25, 2026, argues that a persistent, self-updating background daemon should not be the default for a CLI tool. The reporter notes that the daemon pins the environment of whichever session started it, so proxy variables set per invocation are ignored by later sessions, and that hooks in --remote mode receive the daemon's working directory instead of the session's (issues #42457 and #37537). A further bug: codex app-server daemon stop stops the app-server but leaves the pid-update-loop updater running, requiring a manual kill.

The documented workaround is to run codex features disable daemon_auto_start, stop the daemon, kill the updater process and remove the ~/.codex/packages/app-server-daemon directory. With the flag off, new TUI sessions no longer spawn a daemon. Users on Windows 10 LTSC report the CLI becoming unusable, with setting daemon_auto_start = false in config.toml resolving the issue. One user reported finding 1.3 GB of background updates downloaded days after installation. Community reaction was strongly negative, with many commenters describing the behavior as malware-like and some saying they would roll back Codex seat licenses.

Workarounds and remaining concerns

A September 28 packaging commit (b51c036, in the third-party nixvital/ml-pkgs repository) linked to the issue disables daemon auto-start for that Nix package, but no official OpenAI change to the default appears in the thread. Commenters noted the opt-out flag is still absent from the official config reference, and the 0.157.0 release note described the feature in a single sentence without naming the persistent process, the managed package copy or the hourly updater.

Further discussion focused on provenance: once the CLI copies itself into a managed release directory and a background updater can replace that copy, the process serving a later turn is no longer necessarily the artifact the user installed. One commenter proposed an execution receipt per client attachment containing client CLI version, daemon binary digest, daemon generation, updater state and inherited environment generation, so clients can verify which daemon is authoritative for a given turn. Related issues #40969, #41188, #46468 and #48050 remain open.

Sources: GitHub