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

What it is

Codex CLI 0.157.0 (reported on npm install, Linux/WSL2) turns on daemon_auto_start by default. The first interactive session spawns a persistent codex app-server --managed-daemon and a detached updater, and the daemon keeps running after every Codex window is closed. The page's main value for an engineer is the opt-out, the cleanup steps, and the practical consequences for secrets and proxies.

How it works

• The daemon runs in its own session with no TTY and is reparented to PID 1. It lives until codex app-server daemon stop or a reboot.
• It runs from a copy of the platform package under ~/.codex/packages/app-server-daemon/releases/<version>/, not from the npm-installed binary.
• The updater (codex app-server daemon pid-update-loop) checks 5 minutes after start, then hourly, and restarts the backend after downloading a release. Issue #40969 (still open per the thread) covers this killing active turns after a 60s drain.
• The daemon inherits the environment and cwd of whichever session started it. Later sessions don't override them. The reporter saw a per-invocation HTTPS_PROXY stick to the first session. A commenter saw direnv-style GH_TOKEN values from the first directory used by the agent in later directories.
• Hooks in --remote mode receive the daemon's cwd and terminal rather than the session's (#42457, #37537), which look like the same root cause.

Preconditions / Affected

• CLI 0.157.0 is confirmed on Linux/WSL2 and on Windows 10 LTSC. On Windows, daemon startup blocked by elevation makes the CLI unusable unless --no-daemon is passed, according to commenters.
• Package-manager installs (npm, brew, pacman) are affected. Related reports are #41188, #46468 and #48050 (Arch package fails without --no-daemon).
• Anyone who launches Codex with per-project or per-session secrets or proxy settings is exposed to wrong-credential or wrong-egress behavior.
• One commenter says v0.160.0 on a hardened Raspberry Pi showed no daemon. That is a single anecdote, not a confirmed fix.

What to do

The reporter's workaround:

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

• A Windows commenter confirmed that daemon_auto_start = false in config.toml resolves the issue.
• --no-daemon is the per-invocation escape hatch.
• Verify afterwards that no pid-update-loop or --managed-daemon process remains. The reporter found the updater alive 70s after daemon stop.
• Until the daemon is disabled, don't rely on per-session env vars (GH_TOKEN, proxy) being honored.

Caveats

• daemon_auto_start is reportedly absent from the official config reference. A commenter checked the full page, and their notes say the 0.157.0 release note describes the change in one sentence without mentioning the persistent process or updater. That commenter traced docs and source and did not run the daemon.
• The page shows commits referencing the issue (dated Sep 28 and Oct 7-12), but no maintainer response or fix is visible in the text. Whether the default changed is unconfirmed.
• The proposed "execution receipt" (client version, daemon binary digest, generation, updater state, inherited-environment generation) is a community suggestion, not planned work. The commenter who proposed it links their own tool.
• Several comments call the behavior malware-like. That is opinion, and nothing in the text shows malicious intent.