A user reports that since Codex CLI version 0.157.0, simply opening an interactive codex session starts a persistent background daemon that keeps running after the window is closed. The daemon copies the full platform package, roughly 374 MB, into a local releases folder and runs from that copy. This decouples the backend version from the version installed through npm, and a detached updater checks for new releases shortly after start and then hourly, restarting the backend in the process.
The user also says the daemon pins the environment of the session that launched it. Because they use a wrapper that sets HTTPS_PROXY per invocation, the daemon keeps the first session's proxy variables, and its outbound connections route through that proxy regardless of later sessions. Related issues about working directory and terminal inheritance appear to share the same root cause.
The request is to make daemon_auto_start opt-in, defaulting to false, for the CLI, or at least to ask before enabling it. The user argues that a shared, self-updating daemon suits Remote Control and the desktop app, but a CLI should have a backend that lives and dies with the window and runs the binary the user installed. If the default stays on, the user suggests exiting auto-started daemons when their last client disconnects and skipping self-copying and self-updating when the CLI came from a package manager such as npm, Homebrew, or pacman.
The user also found a bug: codex app-server daemon stop halts the app server but leaves the pid-update-loop updater running. Their current workaround is to disable the feature flag, stop the daemon, kill the updater manually, and remove the cached packages folder.
Source: Hacker News · Summarized by HeadlinesBriefing