Codex CLI ships a self-updating daemon

Codex CLI is OpenAI’s open-source terminal coding agent. On September 25, 2026, user Yihua-Liu-1997 filed issue #48195 against the openai/codex repository: since version 0.157.0, merely opening an interactive session starts a background daemon, codex app-server --managed-daemon — no TTY, reparented to PID 1, alive until codex app-server daemon stop or a reboot. The issue then sat for 18 days without a maintainer reply. On October 12 it reached the Hacker News front page via user whimblepop, and by October 13 it held 370 points with roughly 200 comments. That was enough for OpenAI engineer Charlie Marsh to appear in the thread and say the update subsystem “seems like an oversight” that he intends to fix.

Key points

Since 0.157.0, opening an interactive Codex CLI session starts a persistent daemon and copies roughly 374MB of platform packages into ~/.codex/packages/app-server-daemon/releases/<version>/ — a measurement from the issue author’s Linux/WSL2 machine.
The daemon runs a detached updater, pid-update-loop, that checks for updates 5 minutes after start and then hourly, restarting the backend each time. The author measured it surviving daemon stop by 70 seconds. One user reports about 12GB of stacked old versions.
The off switch is codex features disable daemon_auto_start, undocumented in the repo as of October 13. Marsh has only committed to fixing the updater, not to making the daemon opt-in.

Background

Codex CLI ships through npm, brew and other package managers; the issue author had installed 0.157.0 with npm install -g @openai/codex. Complaints about the daemon’s behavior predate this thread: the author ties #42457 and #37537 (the daemon inheriting the first session’s working directory and terminal) and #40969 (auto-updates restarting the backend mid-task) to the same root cause. OpenAI published 0.162.1 on October 9; the request to change the default is still open. Terminal coding agents usually live and die with the terminal window — the minimalist Pi framework is built that way on purpose — and Codex’s recent news has lived at the model layer, like GPT-6.1 Sol’s default context moving to 500k. A background daemon as an unasked-for default is a different kind of change.

The facts

The issue body documents four behaviors, the workaround and one follow-on bug, all measured in the author’s environment (Linux/WSL2, npm install):

Behavior	Detail	Source
Persistent daemon	`codex app-server --managed-daemon`, no TTY, reparented to PID 1	issue #48195, 2026-09-25
Package copy	~374MB (`codex`, `codex-code-mode-host`, bundled `bwrap`/`zsh`/`rg`) into `~/.codex/packages/app-server-daemon/releases/<version>/`	same, user report
Self-update	`pid-update-loop` checks 5 minutes after start, then hourly, downloads releases and restarts the backend	same
Environment pinning	The daemon keeps the first session’s `HTTPS_PROXY`; later sessions route through it regardless of their own settings	same
Turning it off	`codex features disable daemon_auto_start`, or `[features] daemon_auto_start = false` in `config.toml`; HN users note the flag is undocumented	issue and HN

The 374MB figure is one machine’s measurement and will differ by platform. daemon_auto_start appears in nine places in the repo’s code (including config.schema.json); when I searched on October 13, none of them was under docs/.

What others say

The Hacker News thread spread the impact across setups. icantevenhold dug in and found about 12GB of stacked versions (“it’s just a harness?”). rfgplk confirmed .codex/packages/standalone/releases keeps every old version, each binary around 300MB. dllu said auto-updates once “randomly ruin[ed] the permissions and block[ed] the goal as .git became read-only,” killing long-running tasks. ilitirit reported that on Windows the CLI “launches a new console window every it executes” a command. ranger_danger put it bluntly: “In some circles this is called a backdoor.”

The issue’s own comments add specifics. tagorr confirmed the behavior on Windows 10 LTSC with 0.157.0 and saw it disappear after setting daemon_auto_start to false. felipeelopes called the CLI unusable on Windows because of it — one user’s claim, though zdd reporting a CLI that accepts no input at all points the same way.

timdorr argued Claude Code runs the same operational model: ~/.local/share/claude/versions/ piles up old binaries while claude bg tasks keep running after the foreground copy closes. Replies to that comment note Nix packages patch the behavior out and point to Claude Code’s issue #14980, summarized by one reader as “They don’t care.”

On the vendor side, Charlie Marsh — whose GitHub profile places him at OpenAI on the Astral team, building Ruff and uv — replied to the 12GB report on October 12 at 19:22 UTC: “I haven’t worked with the update subsystem before but that seems like an oversight to me. I’m gonna fix it.” He did not address the issue’s core ask of making the daemon opt-in. Downstream, the Nix package repo nixvital/ml-pkgs already carries a no-daemon_auto_start.patch for codex, with a comment citing issue #48195. Mainstream outlets had not picked the story up as of October 13 — searches in English and Chinese turn up only GitHub and Hacker News — and the thread itself splits on whether background auto-updates are acceptable at all: some compare Codex to browsers, while swatcoder argues professional tools should not auto-update by default.

How to turn it off

The issue author’s full sequence — daemon stop does not stop the updater, so the last line matters:

codex features disable daemon_auto_start
codex app-server daemon stop
pkill -f 'app-server daemon pid-update-loop'
rm -rf ~/.codex/packages/app-server-daemon

Or write it into ~/.codex/config.toml:

[features]
daemon_auto_start = false

With the flag off, the author found that new TUI sessions no longer spawn a daemon. To check whether you are affected, run ps aux | grep managed-daemon, or count the version folders under ~/.codex/packages/app-server-daemon/releases/.

Our take

For anyone running Codex daily, the practical impact lands in three places: the backend you are talking to can drift from the version your package manager installed; outbound traffic gets pinned to whatever proxy the first session carried, which bites anyone wrapping the CLI in an HTTPS_PROXY script; and hourly auto-updates restarting the backend put long tasks at risk. Every disk-space number here is a user report — 374MB came from one WSL2 machine, so treat it as anecdote, not a benchmark. The scope of the fix is also unsettled: Marsh acknowledged only the updater, and both the opt-in default and documentation remain open questions on the issue. Until OpenAI lands something, turning the daemon off manually and watching #48195 is the reasonable move.