What the Codex CLI daemon in 0.157.0 runs, updates and inherits, and how to remove it

The behavior is documented in GitHub issue #48195 on openai/codex. The issue was opened on September 25, 2026 against CLI 0.157.0, installed with npm on Linux under WSL2. It asks for daemon_auto_start to be opt-in and remains open. Most of the detail below comes from the reporter and the related issues the reporter links. One commenter reports two documentation gaps: the official config reference, fetched on October 12, documents check_for_update_on_startup but has no daemon_auto_start row, and the 0.157.0 release note gives the change one sentence.

Per the issue reporter, starting one interactive session sets up three things. None of them go away when the terminal closes.

The copy is what decouples the daemon from your install. Once the daemon runs from a managed release directory that the updater can replace, the backend version no longer follows the CLI version your package manager installed. One commenter on the issue described this as installed CLI identity not being the same as daemon execution identity. The process that services a later turn is no longer necessarily the artifact you installed or invoked.

The updater restarts the backend after it downloads a release, and that restart can kill work in progress. Issue #40969 reports that the app-server daemon's auto-update force-kills active turns after a 60-second drain budget and cannot be disabled. A commenter on #48195 notes that #40969 is still open and describes the behavior as a 60-second drain followed by SIGKILL. According to that commenter, the config reference documents check_for_update_on_startup for the CLI's own update check. The sources point to no documented switch for the daemon's update loop other than turning off daemon_auto_start altogether.

One Hacker News commenter argued that fast-moving tools should update themselves the way browsers do. Others replied that updates do not need a resident daemon or a store of previous versions, and that professional tools should not change underneath an active project. Another commenter said Claude Code uses the same model: it keeps prior versions under ~/.local/share/claude/versions/ and runs background tasks with no copy of Claude Code in the foreground.

Disk use is the other reported cost. One user on the issue says that a few days after installing the CLI, it had downloaded 1.3 GB of updates in the background. A Hacker News commenter reports old versions taking up something like 12 GB in total. Another says .codex/packages/standalone/releases keeps all the old versions and that each codex binary is about 300 MB. A third found 11 separate codex and codex-code-mode-host binaries of about 300 MB each in ~/.bun/install/cache/@openai, and the sources contain no systematic measurement beyond these individual reports.

According to the reporter, the daemon pins the environment of whichever session happened to start it. The reporter launches Codex through a wrapper that sets HTTPS_PROXY for each invocation. The daemon kept the first session's proxy variables and sent its outbound connections through that proxy, regardless of how later sessions were launched. The reporter links two issues that look like the same root cause: in #42457, hooks in --remote mode receive the daemon's cwd instead of the session's, and in #37537, hooks spawned by the daemon cannot identify the client terminal.

The sources establish only a few things about what the daemon can reach on a developer machine. It holds the first session's environment variables, including proxy settings, and uses them for outbound connections. It ships its own bundled bwrap, zsh and rg, and downloads new releases, all after the window that started it has closed. The sources do not say which hosts the updater contacts or what filesystem permissions the daemon runs with; one commenter cites the Codex docs as wanting full read and write access to the entire host filesystem, but the docs themselves are not quoted. The sources also do not cover CI runners: the release note refers to eligible interactive sessions, and nothing in the material says whether non-interactive invocations start the daemon.

Three linked issues describe the daemon conflicting with how Codex was installed. #46468 reports that npm update leaves the app-server on the old version, and that daemon update and restart refuse recovery. #48050 reports that 0.157.0 no longer starts with the Arch Linux package unless --no-daemon is used. #41188 asks for support for externally managed app-server daemon executables.

On Windows 10 LTSC with 0.157.0, a commenter says setting daemon_auto_start = false in config.toml resolved the problem. They asked for two changes: an automatic fallback to local mode when elevation blocks daemon startup, instead of requiring --no-daemon, and auto-start made opt-in. Another commenter calls the CLI unusable on Windows because of this bug, and a third says they cannot type any input in the CLI at all.

Commits referencing #48195 show people turning the default off themselves. One titled "codex: disable daemon auto-start by default" was added on September 28. On October 13, one titled "fix(home): disable Codex daemon auto-start" was added, along with another whose title begins "fix(agents): keep Codex from starting its self-updating background". The sources do not say which repositories these commits belong to or whether any shipped in an official release. One Hacker News commenter says the Codex package in numtide/llm-agents.nix appears to patch out the retention of old versions, and the sources do not show OpenAI changing the default; one commenter's report of no running daemon on v0.160.0 is a single observation, not a confirmed change.

The reporter's workaround follows. After the flag is off, a new TUI session no longer spawns a daemon. The reporter also found that codex app-server daemon stop leaves the pid-update-loop updater running: it was still alive 70 seconds later and had to be killed by hand.

To contain the daemon rather than remove it, one Hacker News commenter suggests wrapping badly behaved applications in a systemd cgroup so the whole process tree is force-killed on exit, for example with systemd-run --user --pty --wait --collect -p TimeoutStopSec=5s. The commenter gave the command from memory and said it may not be exactly what is needed.

The reporter's preferred fix is that, in the CLI, the backend lives and dies with the window, runs the installed binary, and does not update itself in the background. A shared, self-updating daemon would stay on for Remote Control and the desktop app, or when the user explicitly runs codex app-server daemon start or bootstrap. If the default stays on, the reporter asks for two things: an auto-started daemon should exit when its last client disconnects, and npm, brew or pacman installs should run the installed binary without copying or self-updating.

A commenter on #48195 proposed a complementary change. The daemon would return a receipt on each client attachment containing client_cli_version, daemon_binary_digest, daemon_generation, updater_state and inherited_environment_generation. A client could then tell when the daemon binary changed independently of the package-manager state, or when the daemon inherited its environment from an earlier session. Neither proposal has been adopted in the sources provided.