Codex CLI 0.157.0 starts a self-updating background daemon, users report
A user filed issue #48195 on the openai/codex GitHub repository asking that the Codex CLI stop starting a persistent, self-updating background daemon by default. The setting involved is called daemon_auto_start. The reporter runs CLI 0.157.0, installed with npm install -g @openai/codex on Linux (WSL2), and says that since that version simply opening an interactive codex session sets off a chain of side effects.
First, a daemon (codex app-server --managed-daemon) starts in its own session with no TTY. It keeps running after every Codex window is closed, reparented to PID 1, until the user runs codex app-server daemon stop or reboots. Second, the CLI copies the whole platform package, about 374 MB (the codex and codex-code-mode-host binaries plus bundled bwrap, zsh and rg), into ~/.codex/packages/app-server-daemon/releases/
Third, a detached updater (codex app-server daemon pid-update-loop) checks for updates 5 minutes after start and then hourly, downloads new releases and restarts the backend. The reporter notes that this restart can kill active turns and links issue #40969, whose title says auto-update force-kills active turns after a 60s drain budget and cannot be disabled. Fourth, the daemon pins the environment of whichever session started it. The reporter launches Codex through a wrapper that sets HTTPS_PROXY per invocation, and the daemon keeps the first session's proxy variables, so its outbound connections go through that proxy whatever later sessions are launched with. Issues #42457 and #37537, about hooks in --remote mode receiving the daemon's cwd and not identifying the client terminal, look to the reporter like the same root cause.
The reporter's argument is that for a CLI the least surprising default is a backend that lives and dies with the window, runs the installed binary and does not update itself in the background. A shared, self-updating daemon makes sense for Remote Control or the desktop app, so enabling it there, or when the user explicitly runs codex app-server daemon start or bootstrap, would be fine. The ask: make daemon_auto_start opt-in (default false), or at least ask once. If it stays on by default, the reporter asks that an auto-started daemon exit when its last client disconnects, and that the CLI not copy itself or self-update when it was installed by a package manager (npm, brew, pacman). Related issues cited: #41188, #46468 and #48050, the last being that Codex 0.157.0 no longer starts with the Arch Linux package unless --no-daemon is used.
The reporter also found a bug while turning the feature off: codex app-server daemon stop stops the app-server but leaves the pid-update-loop updater running; it was still alive 70 s later and had to be killed by hand. The workaround given is codex features disable daemon_auto_start, then codex app-server daemon stop, then pkill -f 'app-server daemon pid-update-loop', then rm -rf ~/.codex/packages/app-server-daemon. With the flag off, a new TUI session no longer spawns a daemon.
The thread drew many reactions and comments. One commenter says they hit the same thing and that software should not create mystery servers and processes on small version bumps without a heads-up. Another says the CLI is unusable until this is fixed. A Windows 10 LTSC user confirms the problem on 0.157.0, says daemon_auto_start = false in config.toml resolves it, and suggests falling back to local mode automatically when daemon startup is blocked by elevation instead of requiring --no-daemon. Others call the behaviour malware-like, joke about a botnet, or say they are rolling back Codex seat licenses at their company; these are opinions, and no evidence of malicious activity is presented. One commenter running v0.160.0 on a Raspberry Pi says they see no daemons.
On Oct 3, 2026 a commenter proposed that the daemon expose an execution receipt for each client attachment (client CLI version, daemon binary digest, daemon generation, updater state, inherited environment generation) so a client can tell which daemon generation, binary and environment is actually authoritative for a turn. A later commenter says the opt-out is still missing from the official config reference, which has no daemon_auto_start rows while documenting check_for_update_on_startup, and that the 0.157.0 release note covers the change in one sentence without naming the persistent process, the package copy or the hourly updater. The activity log shows labels (enhancement, CLI, app-server) added on Sep 25, 2026 and commits referencing the issue on Sep 28, Oct 7, Oct 10 and Oct 12, without their contents.
Key facts
- The reporter says that since Codex CLI 0.157.0, opening an interactive session starts a daemon (codex app-server --managed-daemon) that keeps running after all windows close, until it is stopped explicitly or the machine reboots.
- The CLI copies a ~374 MB platform package into ~/.codex/packages/app-server-daemon/releases/
/ and runs the daemon from that copy, so its version is decoupled from the npm-installed CLI. - A detached updater checks for updates 5 minutes after start and then hourly, and restarts the backend, which can kill active turns; the daemon also pins the first session's environment, including proxy variables.
- The request is to make daemon_auto_start opt-in (default false) for the CLI. The reporter's workaround is codex features disable daemon_auto_start, plus stopping the daemon and killing the updater by hand.
- Other users, including one on Windows 10 LTSC, report the same problem; the text shows no response from OpenAI maintainers.
Why it matters
A command-line tool normally lives and dies with the terminal that started it. The reporter's complaint is that Codex CLI now leaves a long-lived process behind, runs a private copy of itself that can diverge from the version the user installed, and updates that copy on a schedule without being asked. The 0.157.0 release note, as quoted by a commenter, describes the change as: Enabled automatic background-server startup for eligible interactive sessions, with recovery choices when server settings are incompatible. The thread argues that this one sentence does not convey a persistent process, a ~374 MB package copy or an hourly updater.
Who it affects
Anyone running Codex CLI 0.157.0 or later in interactive sessions, as reported on Linux (WSL2) with an npm install, on Windows 10 LTSC, and with the Arch Linux package. People who launch Codex through wrappers that set environment variables per invocation, such as HTTPS_PROXY, are hit by the pinned-environment behaviour. So are users whose hooks run in --remote mode, which receive the daemon's cwd and not the session's. Users who package-manage their tools see the installed binary and the running binary drift apart.
How to use it
The reporter's workaround is four commands: codex features disable daemon_auto_start; codex app-server daemon stop; pkill -f 'app-server daemon pid-update-loop' (needed because daemon stop leaves the updater running); and rm -rf ~/.codex/packages/app-server-daemon. With the flag off, a new TUI session no longer spawns a daemon. A Windows commenter says setting daemon_auto_start = false in config.toml resolves the problem for them. Another commenter notes that the opt-out is not visible in the official config reference.
How solid is it
This is a user-filed GitHub issue on the official openai/codex repository, not a vendor announcement. The reproduction is detailed but comes from one setup (npm install, Linux WSL2), with the ~374 MB size and the ~/.codex paths measured there. Other commenters confirm the behaviour on Windows 10 LTSC and point to related issues, and the thread shows many reactions. The 0.157.0 release note is quoted only second-hand by a commenter. A commenter on v0.160.0 on a Raspberry Pi saw no daemons, but the text does not establish whether later versions changed the default. No response from OpenAI maintainers appears in the text, and the text does not say whether the issue is open or closed.
Risks and caveats
The malware comparisons and the botnet remark are commenters' opinions; no evidence is presented that the daemon exfiltrates data or acts maliciously. The reporter's own concern is about surprise, version drift, force-killed turns and a pinned environment. The reporter says a shared, self-updating daemon does make sense for Remote Control or the desktop app, so the request is about the default for the CLI, not about removing the feature. The workaround includes deleting the daemon's package directory and killing a process by pattern, so check what the pkill pattern matches on your machine before running it.
“For a CLI, the least surprising default is that the backend lives and dies with the window, runs the binary I installed, and doesn't update itself in the background.”
— Issue reporter, openai/codex GitHub issue #48195