Codex CLI 0.157.0 Installs a Persistent, Self-Updating Background Daemon by Default

Codex CLI 0.157.0 starts a persistent background daemon by default, and users want it opt-in

Since version 0.157.0, opening an interactive codex session starts a persistent, self-updating background daemon without asking. GitHub issue openai/codex#48195, opened by user Yihua-Liu-1997 on September 25, 2026, requests that the daemon_auto_start feature flag be made opt-in (default false) for the CLI, or at minimum that the tool ask once before enabling it. The issue reached 599 points and 292 comments on Hacker News, where the dominant reaction was that a CLI installed through a package manager should not spawn a long-lived, self-updating server process.

The reporter's environment is Codex CLI 0.157.0, installed via npm install -g @openai/codex on Linux (WSL2). The issue carries the labels CLI, app-server, and enhancement.

The daemon does four things the reporter considers surprising defaults

According to the issue, merely opening an interactive codex session triggers all of the following:

1. It starts a persistent background daemon (codex app-server --managed-daemon). The process runs in its own session with no TTY and keeps running after every Codex window is closed, reparented to PID 1, until codex app-server daemon stop or a reboot.
2. It copies the whole platform package — roughly 374 MB, comprising codex, codex-code-mode-host, and bundled bwrap/zsh/rg — into ~/.codex/packages/app-server-daemon/releases/<version>/. The copy is byte-identical to what npm had just installed, and the daemon runs from that copy. From that point on, the backend's version is decoupled from the CLI version the user installed with their package manager.
3. It starts a detached updater (codex app-server daemon pid-update-loop) that checks for updates five minutes after start and then hourly, downloads new releases, and restarts the backend. That restart can kill active turns, a separate problem tracked in issue #40969.
4. It pins the environment of whichever session happened to start it. The reporter launches Codex through a wrapper that sets HTTPS_PROXY per invocation; the daemon keeps the first session's proxy variables, so its outbound connections go through that proxy regardless of what later sessions are launched with.

The reporter links the environment-pinning behavior to issue #42457 (hooks in --remote mode receive the daemon's cwd, not the session's) and issue #37537 (hooks spawned by the app-server daemon cannot identify the client terminal), describing them as looking like the same root cause.

The reporter's stated expectation: a CLI backend should live and die with the window

The issue frames the request around least-surprise defaults for a command-line tool:

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. A shared, self-updating daemon makes sense for Remote Control / the desktop app, so it would be fine to enable it there, or when the user explicitly runs codex app-server daemon start / bootstrap.

If the default is kept, the reporter asks for two fallbacks: exit an auto-started daemon when its last client disconnects, and do not copy or self-update when the CLI was installed by a package manager (npm, brew, pacman) — run the installed binary instead. Those requests reference issue #41188 (support externally managed app-server daemon executables), issue #46468 (npm update leaves app-server on an old version, but daemon update/restart refuse recovery), and issue #48050 (Codex 0.157.0 no longer starts with the Arch Linux package unless --no-daemon is used).

codex app-server daemon stop does not stop the updater

The issue reports a bug found while trying to turn the feature off: codex app-server daemon stop stops the app-server but leaves the pid-update-loop updater running. The reporter states it was still alive 70 seconds later and had to be killed manually.

The workaround documented in the issue is:

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

With the flag off, the reporter confirms a new TUI session no longer spawns a daemon.

Confirmation from other platforms, and a config-file fix

Commenters on the GitHub issue confirmed the behavior on other systems and pointed to a configuration-based fix.

User tagorr reported the same problem on Windows 10 LTSC with Codex CLI 0.157.0 and stated that setting daemon_auto_start = false in config.toml resolves it. tagorr also proposed two improvements: automatically fall back to local mode when daemon startup is blocked by elevation instead of requiring --no-daemon, and make daemon auto-start opt-in rather than the default. The issue author replied that both would work.

User felipeelopes wrote that the Codex CLI is unusable due to this bug on Windows. User megahall, who appears to be responding in a maintainer capacity, wrote:

thanks for reporting this, I hit it myself... stuff should not be creating mystery servers and processes all of a sudden on small version number bumps without giving people a heads-up...

User kr8vka0z wrote that the CLI is unusable until this is fixed. User skhaz added "+1 for disabling this." User laurynas-karvelis was blunter: "Basically - a trait of malware. TBF I don't even think this was done by accident."

The provenance argument: installed CLI identity is not daemon execution identity

A comment from user aetherxeg-source framed the issue as a provenance boundary problem, stating that installed CLI identity != daemon execution identity. The argument is that once the CLI copies itself into a managed release directory and a background updater can replace that copy, the process servicing a later turn is no longer necessarily the artifact the user explicitly installed or invoked.

The comment proposes that the daemon expose a small execution receipt for each client attachment containing at least client_cli_version + daemon_binary_digest + daemon_generation + updater_state + inherited_environment_generation, so a client can distinguish four states: same installed artifact and same daemon generation; same CLI but different daemon generation; daemon binary changed independently of package-manager state; and daemon inherited environment from an earlier session.

Downstream packagers began disabling daemon auto-start

Several third-party repositories added commits referencing the issue, indicating that packagers treated the default as something to override. These include a commit titled "codex: disable daemon auto-start by default" in nixvital/ml-pkgs (September 28, 2026), a dotfiles commit updating Codex to 0.160.1 with a sandbox patch for nix-user-chroot (October 7, 2026), and a NixOS commit packaging Codex CLI from official release binaries (October 10, 2026).

On Hacker News, the debate split between "this is malware-like" and "browsers do this too"

The Hacker News thread surfaced both strong criticism and a defense of automatic updating.

The criticism centered on trust, disk usage, and regressions. User icantevenhold reported that old versions filled the disk: "I investigated and it took up something like 12 gigabytes in total on my system; which seems insane to me, it's just a harness? People moan about how badly made Claude code is but Codex seems much worse on every metric." User dllu reported that the daemon's auto-updating broke file permissions: "when auto-updating, it would randomly ruin the permissions and block the goal as .git became read-only." User ranger_danger wrote simply, "In some circles this is called a backdoor." User soletta wrote, "Deleting codex and unsubbing. Thank you, OP, for highlighting this important PSA."

The defense was that self-updating is now standard. User dingaling911 wrote: "This stuff is moving fast, should update automatically. This is kind of standard now. Browsers do it. No reason for harnesses not to do it as well." User piker, who says they built a legal IDE, argued the intent is not necessarily hostile: "We considered different updating approaches with our legal IDE where security, stability, etc. are paramount, and having a buggy application out in the wild is user-hostile... We considered the daemon thing, but ended up with a hard-update check on every boot." User infinite_spin noted the context matters: "I expect this sort of thing when installing/running the client, but I can see why it would be alarming for a CLI installed via NPM to do this."

Claude Code uses a similar operational model, according to one commenter

User timdorr pointed out that the pattern is not unique to Codex, writing that it is "the same operational model as Claude Code" and citing ls ~/.local/share/claude/versions/ and ps auxww | grep "claude bg", which show prior versions of the Claude Code binary and several running background tasks with no Claude Code in the foreground.

Documented workarounds from the Hacker News thread

Multiple commenters described ways to disable the daemon.

User whimblepop, who submitted the story, noted that no settings are documented to disable the feature, but that it currently sits behind a feature flag that can be flipped in ~/.codex/config.toml:

[features]
daemon_auto_start = false

whimblepop also described a more aggressive approach: the daemon writes pid files and lock files into ~/.codex at startup, and those can be deleted and replaced with symlinks to /dev/null, then marked unwritable with chattr +i, so the background daemon would crash on startup if the feature flag is ever removed.

User grimgrin posted a redundant belt-and-suspenders configuration combining the config file with a shell function:

codex() { command codex --no-daemon "${@:-.}" }

User gruntled-worker added that the executable can simply be copied and run with --no-daemon, and that recent terminal UI changes can be disabled with CODEX_TUI_DISABLE_KEYBOARD_ENHANCEMENT=1 and the /tui command.

The environment-inheritance problem is the most user-hostile part, one commenter argues

User yearolinuxdsktp singled out the environment behavior rather than the daemon itself:

I think the most user-hostile aspect of this default change is silently breaking the "command runs in shell environment it was launched from" convention/expectation. For example, a session start hook to assert a valid environment will fail because it runs in the app server's environment. It also silently stops using the daemon if you pass in just about any -c argument, such as the model context size.

Platform-specific breakage: Windows console windows and elevation

User ilitirit reported that on Windows the tool "also launches a new console window every it executes (?) a command" and advised disabling it with --no-daemon, adding that the CLI "was perfectly usable two weeks ago." The GitHub issue's Windows confirmations from tagorr and felipeelopes point to the same platform being disproportionately affected, with tagorr specifically asking for an automatic fallback to local mode when daemon startup is blocked by elevation.

Broader complaints about Codex and AI harness quality

Several commenters used the thread to criticize the wider state of AI coding tools rather than the daemon alone.

User Alifatisk described the Codex VS Code extension as "insane how brittle it is," saying it was completely broken for about a week before being partially fixed, that multiple issues track the same problems, and that the community has started patching the extension themselves. Alifatisk wrote that they turned off autoupdate for the extension — the only extension they have had to do that for — and concluded: "I have now experienced the consequences of 'move fast and break things'. I realize how much software quality means to me."

User esjeon wrote: "I think the quality of Codex CLI (and Claude Code) is an honest reflection of the status quo of LLM-driven development. The future doesn't look really promising." User compiler-guy argued that user experience only improves with focused taste applied consistently over long periods, and that "if no one is taking the time, the UX will continue to suck. And no one seems to be." User Sha1rholder questioned whether human testing happens at all, calling the front-end quality of ChatGPT, Codex Desktop, and the Android app "simply dreadful."

The packaging counterargument: distros exist to prevent exactly this

User thebeardisred argued that the incident vindicates the operating-system distribution model: "you get folks who will package the software & test it out, make generally sensible defaults, and generally keep shenanigans like this from going on." User AndreasBackx made a related point about reinvention, noting that the Codex install script manages installation itself rather than using existing package managers: "We've figured out how to update software via package managers. Do we need a daemon to continually check for updates and do we need shell scripts to circumvent package managers?"

User clutter55561 recommended isolation instead of configuration: "never install those things into your host. A locked down Docker container is the bare minimum. Pin your versions and never update them without checking the changelog." User umutsevdi reported discovering the daemon while benchmarking and switching to bwrap around these tools for accurate measurements.

Alternatives users migrated to

Several commenters named lighter-weight harnesses. User reacharavindh described using GPT models through hax, "a bare bones harness with minimal tools," relying on bash for most tasks and adding CLI tools as needed via a single line in the system prompt. User sva_ recommended the Pi Coding Agent as "a lot more lightweight, and in my experience much better than any of the proprietary harnesses." User silverbluep said they abandoned Codex because it "mixes state and configuration data," which prevented declarative management in a nix-darwin environment, and now uses Codex only through opencode. User pkulak noted the mitigating factor: "OpenAI at least is fine with you using whatever harness you like. Having a crappy first-party one is bad, but an escape hatch puts a floor on it."

What the issue asks for, in one line

Make daemon_auto_start default to false for the Codex CLI, or prompt once before enabling it; if the default stays on, exit the daemon when its last client disconnects and stop copying or self-updating when the CLI was installed by a package manager. As of the issue's last activity on October 12, 2026, the issue remained open with no assignee, no milestone, and no linked pull request.