Codex CLI runs a background daemon you never agreed to
A 500+ point Hacker News thread asks OpenAI to make Codex CLI's persistent, self-updating background daemon opt-in. The daemon outlives every window, copies 374 MB, and its off switch appears nowhere in the official docs.
Hacker News is arguing with a CLI. The issue at the center of it, titled "make daemon_auto_start opt-in", crossed 500 points while asking OpenAI's Codex CLI to stop doing something it has done quietly since version 0.157.0: installing a background process that outlives every window you open it from.
The issue's teardown of 0.157.0 on WSL2 reads like a scope audit. Opening an interactive codex session starts a managed daemon with no TTY. Close the window and the daemon keeps running, reparented to PID 1, until you run codex app-server daemon stop or reboot. Along the way it copies roughly 374 MB of its own platform package into ~/.codex/packages/app-server-daemon/releases/, byte-identical to what npm had just installed, and runs the backend from that copy. From then on, the version serving your sessions has nothing to do with the version your package manager manages.
A detached updater sits next to it. It checks for new releases five minutes after the daemon starts, then hourly, downloads them, and restarts the backend in place. The restart can land on top of an active turn: a separate issue from August describes a 60 second drain budget followed by a force kill, and it is still open. The daemon also pins the environment of whichever session happened to start it. Set HTTPS_PROXY per invocation through a wrapper, and every later session's traffic goes through the first session's proxy. A separate report filed this week says the daemon leaks environment variables across sessions on 0.162.1, the current release, so the pinning problem is alive in the shipping version, not a 0.157.0 artifact.
The rollout deserves its own case study. The pull request that flipped the default was merged on September 22 and shipped in 0.157.0 with one line in a long release notes list: "Enable automatic daemon startup by default." The official config reference documents a related flag, check_for_update_on_startup, six times. For daemon_auto_start it documents nothing. The off switch exists, but as of this writing you learn about it from a Hacker News comment, not from the vendor.
The comment section reads like a support queue for symptoms nobody had connected. One commenter reports the background updater randomly flipping .git to read-only, one of a pile of bugs that blocked goals every few hours and left the tool impossible to trust with any of them. Another found the daemon running two weeks ago and had Codex write its own launcher to bypass it. Nobody in that thread chose invisible software. The invisibility was the default.
The harshest verdicts showed up anyway. One early user writes that the issue, and the way the team responds to it, ends any trust in the harness for good, and the workaround is running Codex only inside an open source client. Another points out the same operational model already exists in Claude Code: prior versions on disk, background tasks running, nothing in the foreground. That reaction is outsized for what the process technically does. Browsers self-update, and most people want that. The difference is that a browser tells you, keeps the setting in plain sight, and does not run when every one of its windows is closed. Codex fails all three, and it failed quietly for eighteen days before a thread this size noticed.
The practical part fits in four lines. Add daemon_auto_start = false under [features] in ~/.codex/config.toml, or run codex features disable daemon_auto_start. After a daemon stop, check for a leftover updater; the stop command leaves it running, one bug among the 16 comments on the issue. Some commenters go further and symlink the daemon's pid and lock files to /dev/null, which works until an update rearranges the directory.
Nearly three weeks after the issue was opened, the flag is still missing from the docs and the default still stands. Whatever OpenAI decides, the lesson reaches past this one tool. A default is a product decision, and persistence is the kind of default users expect to be asked about. Codecora wrote about the friendlier version of this pattern earlier this month, agents improvising their own persistent memory on the machines they run on. This is the same story from the other side: software that persists itself, and a user base that wants a say in it.
Comments ()