Codex CLI installs a persistent, self-updating background daemon by default

Users report that Codex CLI 0.157.0 (installed via npm -g on Linux/WSL2 and reproduced on Windows) now spawns a persistent background daemon by default when an interactive session opens. That daemon (codex app-server managed-daemon) runs detached with no TTY, survives session exit (reparents to PID 1), and is run from a copied release of the platform (~374 MB) placed under ~/.codex/packages/app-server-daemon/releases/, decoupling the backend from the package-manager-installed binary. A detached updater (pid-update-loop) checks for updates after five minutes and hourly thereafter, downloads new releases, and restarts the daemon - which can force-kill active turns after a 60s drain budget - while inheriting the environment of whatever session first started it (e.g., HTTPS_PROXY), breaking expected terminal/working-directory semantics for later sessions and hooks.

Reporters demand making daemon_auto_start opt-in (default false) or at least prompting before enabling; if enabled, require the daemon to exit when its last client disconnects and avoid self-updating when the CLI was installed by a package manager. A bug where codex app-server daemon stop leaves the pid-update-loop alive was documented; users workaround by disabling the feature flag, stopping the daemon, killing the updater, and removing the copied package. Community discussion confirms widespread disruption (including unusable CLI on Windows), and maintainers have committed changes referencing disabling auto-start by default while others propose exposing daemon execution receipts (version, binary digest, environment generation) so clients can detect when a different binary or environment is servicing turns.