Codex CLI 0.157.0 leaves a daemon running after you quit

According to a feature request filed on GitHub, opening a single interactive session of Codex CLI 0.157.0 starts a background daemon. That daemon keeps running after you close every Codex window, until you run daemon stop or reboot. The author uses Linux under WSL2 with Codex installed through npm, and asks OpenAI to make daemon_auto_start opt-in, or at least to ask once before turning it on.

At a glance

• The daemon does not run the binary npm just installed. It runs from its own byte-identical copy of the roughly 374 MB platform package under ~/.codex, so its version drifts away from the CLI's.
• A detached updater checks for new releases 5 minutes after start and then every hour. It downloads them and restarts the backend, which a linked issue says can kill active turns.
• The daemon keeps the environment of whichever session started it, proxy variables included. Running codex app-server daemon stop leaves the updater alive, and the author had to kill it by hand.

If you have not been following Codex releases, here is the background. According to the Codex Knowledge Base, the CLI used to be a stateless per-session process: each invocation launched the TUI, ran the session and exited, and the background server was an opt-in for power users. The same source says daemon auto-start arrived as an opt-in in v0.156.0 on 2026-09-22 and became the stable default in v0.157.0, released 25 September 2026.

One session leaves behind a daemon and a 374 MB copy of Codex

The process is codex app-server --managed-daemon. It runs in its own session with no TTY. When the last Codex window closes, it is reparented to PID 1, the system's init process, and keeps going until codex app-server daemon stop or a reboot.

Before the daemon starts, Codex copies the whole platform package, about 374 MB, into ~/.codex/packages/app-server-daemon/releases/<version>/. The package holds codex, codex-code-mode-host and bundled bwrap, zsh and rg, and the copy is byte-identical to what npm had just installed. The daemon runs from that copy, so from then on the backend's version is decoupled from the CLI version your package manager installed.

An updater checks hourly and can restart the backend mid-turn

Codex also starts a detached updater, codex app-server daemon pid-update-loop. It checks for updates 5 minutes after start and then hourly, downloads new releases and restarts the backend. The author points to issue #40969, which reports that this auto-update force-kills active turns after a 60-second drain budget and cannot be disabled.

Package-manager installs run into their own problems, and the author lists three linked issues. #41188 asks for support for externally managed daemon executables. In #46468, npm update leaves the app-server on an old version and daemon update and restart refuse to recover. In #48050, 0.157.0 no longer starts with the Arch Linux package unless --no-daemon is used.

The first session's HTTPS_PROXY applies to every session after it

The daemon pins the environment of whichever session happened to start it. The author launches Codex through a wrapper that sets HTTPS_PROXY for each invocation, but the daemon keeps the first session's proxy variables. Its outbound connections go through that proxy no matter what later sessions are launched with.

The author thinks two other bugs share the same root cause. In #42457, hooks in --remote mode receive the daemon's working directory instead of the session's. In #37537, hooks spawned by the app-server daemon cannot identify the client terminal, which breaks hooks meant to target a specific terminal. In both cases the daemon's context wins over the session's.

Turning it off takes four commands, because daemon stop misses the updater

The author found a bug while switching the feature off and reports it in the same issue under additional information. codex app-server daemon stop stops the app-server but leaves the pid-update-loop updater running. The updater was still alive 70 seconds later and had to be killed manually.

The workaround has four steps: codex features disable daemon_auto_start, then codex app-server daemon stop, then pkill -f 'app-server daemon pid-update-loop', and finally rm -rf ~/.codex/packages/app-server-daemon to delete the copied releases. With the flag off, a new TUI session does not spawn a daemon. That fact is the one the short version of this story ended on.

Why would a CLI want a shared server at all?

According to the Codex Knowledge Base, the idea is to pay setup costs once. Sandbox provisioning, model connection negotiation and workspace indexing happen once when the server starts, not on every invocation, and this is meant to make cold starts faster. Later launches find the running server and reconnect to it. A background agent can keep working after its terminal closes, and several tabs share one view of running agents and queued tasks.

Think of a restaurant kitchen that stays lit between orders. Each new terminal is a waiter who walks in and hands over a ticket, not a cook who has to build the stove first. The same source says v0.157.0 needs the shared model for the f shortcut, which forks a conversation open in another app and keeps drafts and queued prompts.

The Codex Knowledge Base also describes how conflicts are handled. When a session starts with a model, sandbox profile or network policy that differs from the running server's, Codex offers three options. You can use the existing server and lose the session's override, restart the server and interrupt in-flight agents, or exit. The source says this is why the first session's configuration can carry over to later ones.

The issue documents one setup, WSL2 with an npm install, and nothing in the inputs measures how much faster cold starts get with the daemon, so we only see one side of the trade. In our view, the copy-and-self-update design clashes with package managers. Someone who runs npm update reasonably expects that version to answer, and here a parallel 374 MB install that updates itself makes the call instead.

Whether the CLI default flips back

The author suggests keeping the shared daemon for Remote Control and the desktop app, or for when a user explicitly runs codex app-server daemon start or bootstrap. If the CLI default stays, the fallback asks are an exit when the last client disconnects and no copying or self-updating for npm, brew or pacman installs. According to Updatify, 0.162.1 fixed startup failures from settings mismatches on Oct 9, 2026. No date has been given for any change to the default.