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

What it claims

In Codex CLI 0.157.0 (npm install, reported on Linux/WSL2 and confirmed on Windows 10 LTSC), daemon_auto_start is on by default. Opening any interactive session leaves three things behind:

• A daemon. codex app-server --managed-daemon runs with no TTY. It is reparented to PID 1 and survives until codex app-server daemon stop or a reboot.
• A package copy. The daemon runs from a copy at ~/.codex/packages/app-server-daemon/releases/<version>/ rather than the binary your package manager installed.
• An updater. A detached pid-update-loop checks for updates 5 minutes after start and then hourly, then downloads releases and restarts the backend. Per linked issue #40969, which is still open, that restart force-kills active turns after a 60-second drain and cannot be disabled.

The issue is a feature request, not a fix. Commits reference it, but the page does not show any resolution.

Consequences the summary doesn't spell out

• Version drift from your package manager. After an npm update, the daemon can keep running an old version, and daemon update/restart refuse to recover it (#46468).
• Distro packages break. On Arch Linux, 0.157.0 will not start without --no-daemon (#48050).
• Windows elevation blocks startup. On Windows, an elevated context can block daemon startup, leaving the CLI unusable for input until you pass --no-daemon or disable the flag.
• Wrong secrets can be used. Each new session attaches to the existing daemon, which carries the first session's environment. The agent then uses that environment, not the current one. One commenter reports this with direnv and common variable names such as GH_TOKEN. That means an agent can act with credentials from a different project.
• Proxy settings stick. Per-invocation HTTPS_PROXY set by a wrapper is ignored after the first session. The daemon's outbound traffic keeps going through the first session's proxy.
• The opt-out is undocumented. As of 2026-10-12, the official config reference has no daemon_auto_start entry. The 0.157.0 release note gives the change one sentence: "Enabled automatic background-server startup for eligible interactive sessions…". It does not mention the persistent process, the package copy or the updater.

How to use it

To disable the daemon fully, run the reporter's workaround. The pkill line is needed because daemon stop leaves the updater alive; in the report it was still running 70 seconds later.

codex features disable daemon_auto_start
codex app-server daemon stop
pkill -f 'app-server daemon pid-update-loop'   # not stopped by `daemon stop`
rm -rf ~/.codex/packages/app-server-daemon

Alternatively, set this in config.toml (confirmed working on Windows):

daemon_auto_start = false

For a single run, --no-daemon bypasses the daemon. After disabling the flag, new TUI sessions no longer spawn a daemon.

What's being asked for

• Make the daemon opt-in, enabled only for Remote Control, the desktop app, or an explicit daemon start/bootstrap.
• Failing that:
• exit the daemon when its last client disconnects;
• skip the copy and self-update when a package manager owns the install;
• fall back to local mode when elevation blocks startup.
• An "execution receipt" per client attachment (client CLI version, daemon binary digest, daemon generation, updater state, inherited-environment generation). This would let a client see which binary and which environment actually serve a turn.

Limits

• The reports cover only 0.157.0 on WSL2 and Windows 10 LTSC.
• One commenter running v0.160.0 on a Raspberry Pi saw no daemon. The page does not say whether the default changed or whether that setup just isn't "eligible".
• The documentation-gap comment is based on reading docs and source, not on running the daemon.
• Before relying on current behaviour, check the issue's status and the latest release notes.