Codex CLI spawns persistent, self-updating daemon by default, GitHub issue warns

What happens when you launch Codex

Since version 0.157.0 of Codex CLI, opening an interactive session starts more than the terminal app: it also spawns a background daemon, a duplicate copy of the tool's binaries, and a detached updater, according to a feature request filed on OpenAI's Codex repository that has reached the Hacker News front page.

The reporter, running Codex 0.157.0 installed via npm on Linux (WSL2), describes the daemon, codex app-server --managed-daemon, as running in its own session with no controlling terminal. Once started it is reparented to PID 1 and keeps running after every Codex window is closed, persisting until the user runs codex app-server daemon stop or reboots. The issue asks OpenAI to make the daemon_auto_start flag opt-in, or at minimum to ask users once before enabling it.

A hidden copy and an hourly updater

Two behaviors drew particular objection. First, the setup copies the entire platform package, roughly 374 MB including the codex binary, codex-code-mode-host and bundled copies of bwrap, zsh and ripgrep, into ~/.codex/packages/app-server-daemon/releases/, even though the files are a byte-for-byte duplicate of what npm had just installed. The running backend is then decoupled from the version the user manages with their package manager.

Second, startup launches a detached updater, codex app-server daemon pid-update-loop, which checks for new releases five minutes after launch and then hourly, downloading them and restarting the backend. A linked issue (#40969) reports that this update path terminates active turns after a 60-second drain window and cannot be disabled.

Pinned environments and broken hooks

The daemon also locks in the environment of whichever session happened to start it. The reporter launches Codex through a wrapper that sets HTTPS_PROXY per invocation; because the daemon holds the first session's proxy variables, its outbound traffic goes through that proxy regardless of how later sessions are configured. Related issues (#42457, #37537) describe hooks in remote mode receiving the daemon's working directory instead of the session's, which breaks terminal-targeting hooks.

Friction with package managers

The reporter concedes that a shared, self-updating daemon is reasonable for the desktop app or Remote Control, where one persistent backend is the design. For a CLI, though, the expected contract is that the backend starts and stops with the window, runs the installed binary, and does not update itself in the background.

If the default stays, the issue asks that the daemon at least exit when its last client disconnects, and that it skip the copy-and-self-update routine when the CLI was installed by a package manager such as npm, Homebrew or pacman. Linked issues suggest the friction is already real: #48050 reports Codex 0.157.0 failing to start from the Arch Linux package unless --no-daemon is passed, #46468 describes npm updates leaving the app-server on an old version while the daemon's own update logic refuses to recover, and #41188 requests support for externally managed daemon executables.

Even disabling the feature is messy. The reporter found that codex app-server daemon stop halts the app-server but leaves the pid-update-loop process alive more than a minute later, requiring a manual process kill.

How to turn it off

The workaround posted in the issue has four steps: run codex features disable daemon_auto_start, stop the daemon, kill the lingering pid-update-loop process, and delete ~/.codex/packages/app-server-daemon. With the flag disabled, the reporter confirms that new TUI sessions no longer spawn a daemon.

Why it matters

CLI tools earn trust through predictability: they run the binary you installed, for exactly as long as you invoked them. A daemon that outlives your terminal, ignores your package manager, and silently replaces its own code every hour breaks that model without asking permission.

The security angle is not abstract. Hourly self-updates mean the code running on a machine can differ from what was reviewed, pinned or audited, and a long-lived process that fetches and executes new releases is a meaningful supply-chain surface. Version drift between the package-managed CLI and the daemon's private copy also complicates debugging and reproducibility.

Finally, the cluster of linked issues shows the costs are already concrete, from failed launches on Arch to sessions killed mid-turn and misrouted proxy traffic. As vendors push app-style architectures into terminal tools, defaults like this one determine whether developers learn about the change from documentation or from an incident.