Since Codex CLI 0.157.0 on 25 September 2026, starting an interactive codex session also starts a background daemon that keeps running after you close the terminal, and one user reports that daemon is backed by a roughly 374 MB copy of the platform package. A Hacker News thread on 12 October 2026 drew more than 400 points and 218 comments, and the linked GitHub issue is openai/codex #48195, still open when this was written. The shortest fix is one command: codex features disable daemon_auto_start. That command comes from the issue and the HN thread, not from OpenAI's CLI documentation, which does not mention the daemon at all. Below: what the daemon does, why people are angry, three ways to disable it, a disk cleanup checklist, and how Claude Code compares.
What the Codex CLI daemon actually does
OpenAI's Codex changelog lists the change under CLI 0.157.0, dated 2026-09-25: "Enabled automatic background-server startup for eligible interactive sessions." The matching pull request title is "Enable automatic daemon startup by default" (#47179). That is the entire user-facing description. One sentence, no config key named.
The reporter of issue #48195 (Linux and WSL2, CLI 0.157.0, installed through npm) spells out what happens in practice. Four things, according to that report:
The first interactive session starts a persistent process,
codex app-server --managed-daemon, which survives closing the window and gets reparented to PID 1.Codex copies the platform package, about 374 MB, into
~/.codex/packages/app-server-daemon/releases/<version>/and runs the daemon from that copy. Its version is therefore decoupled from the npm-installed CLI.A detached updater,
codex app-server daemon pid-update-loop, checks for updates five minutes after start and hourly after that, then restarts the backend. The reporter links #40969, where a restart killed an active turn.The daemon inherits the environment of whichever session started it. Later sessions' variables, such as
HTTPS_PROXY, are ignored.
These are one user's observations on one platform. I could not reproduce them here, and OpenAI has not published a design note that confirms the byte counts or the five-minute and hourly timings. Treat the numbers as reported, not specified.
A fifth claim deserves its own paragraph. A commenter on the issue says the daemon leaks environment variables from the first directory where Codex ran, with direnv-loaded values such as GH_TOKEN as the example. It is a single report with a suggestion to file it separately. If you load secrets per directory, it is worth testing before you assume your tokens stay scoped to one project.
Why people are angry
Three complaints dominate the HN thread. None of them is that a daemon exists. Plenty of tools run one. The complaint is that it arrived on by default, with one changelog sentence, and with an opt-out that is not in the config reference. A commenter on the GitHub issue made the same point: the opt-out "is still invisible in the official config reference."
Disk usage
The HN numbers are anecdotes, but they are consistent with each other. One commenter says old versions piled up to roughly 12 GB. Another says ~/.codex/packages/standalone/releases keeps every old version, each binary about 300 MB. A third found 11 separate codex and codex-code-mode-host binaries in a Bun install cache under @openai, again about 300 MB each. Eleven times 300 MB is 3.3 GB before you count the daemon copy.
Background processes that outlive the session
A process that survives exit surprises people on laptops, in containers, and on shared dev boxes. The issue adds a specific bug: codex app-server daemon stop stops the app server but leaves the pid-update-loop updater running, so you kill it by hand.
Auto-updates and read-only paths
One HN commenter reports that auto-updates made .git and other paths read-only, which blocked their work. I found no confirmation from OpenAI, and no GitHub issue in the material I read that reproduces it. Treat it as a single user report. The related complaint is better documented: an updater that restarts the backend can interrupt a running turn, which is the #40969 case.
OpenAI is patching around the edges. The changelog for 0.162.0 (2026-10-08) includes "Skip daemon auto-start for Windows-mounted WSL homes" (#50555), and 0.162.1 (2026-10-09) fixes a startup failure caused by mismatched feature settings on a running background server. Neither changes the default on Linux or macOS. Downstream, a Nix packaging commit dated 28 September disables the auto-start by default, which tells you what packagers think of it.
Three ways to turn the Codex CLI daemon off
A caution before the commands. Two sources disagree on key names. The issue and the HN thread name a feature flag called daemon_auto_start. A third-party write-up of the 0.157.0 release describes a [daemon] table with auto_start = false and commands such as codex server stop. The issue thread and the changelog do not use those names, and OpenAI's CLI docs document neither. I use the names from the issue below, because they appear in a bug report filed against the real binary. Run codex features list to see what your build actually exposes.
Method 1: the config file
Add this to ~/.codex/config.toml. A commenter on HN describes it as undocumented, and the issue thread shows the same line working:
[features]
daemon_auto_start = false
This is the right choice for a permanent change. It survives upgrades and applies to every launch method.
Method 2: the CLI
The same flag can be set without opening the file:
codex features disable daemon_auto_start
Separately, two commenters say a --no-daemon flag exists and gives you no background process and no auto-update for that run. One of them says it is needed when elevation blocks startup on Windows. OpenAI's CLI documentation does not mention --no-daemon, so I cannot call it supported. If you script Codex in CI, prefer the config flag, because an undocumented argument can vanish in a point release.
Method 3: stop it, kill it, delete it
If the daemon is already running, the config change does not touch it. Use the sequence reported on the issue and in the thread:
codex app-server daemon stop
pkill -f 'app-server daemon pid-update-loop'
rm -rf ~/.codex/packages/app-server-daemon
Run the pkill line even after stop succeeds, since the updater is the process that survives it. The last line deletes the daemon's private copy of the platform package. It is regenerated if the daemon starts again, which is why Method 1 or 2 comes first.
One more option from the thread, for people who want a hard guarantee: a commenter suggests replacing the pid and lock files in ~/.codex with symlinks to /dev/null and marking them immutable with chattr +i. It works on Linux filesystems that support the attribute, and it is a blunt tool. You will need chattr -i before Codex can write those files again.
Disk cleanup checklist
After disabling the daemon, reclaim the space. Check sizes first, delete second.
| Location | What it holds | Reported size |
|---|
| ~/.codex/packages/app-server-daemon/releases/ | Daemon's private copy of the platform package | About 374 MB per version (issue #48195) |
| ~/.codex/packages/standalone/releases/ | Every old standalone version | About 300 MB per binary (HN commenter) |
| ~/.bun/install/cache/@openai/ | Cached codex and codex-code-mode-host binaries | 11 copies at about 300 MB each (HN commenter) |
| ~/.codex/ pid and lock files | Daemon state | Negligible, but stale files confuse restarts |
Run du -sh on each path. Then work through this list:
Stop the daemon and the updater, using Method 3 above, and confirm with
pgrep -fl codexthat nothing is left.Delete old directories under
~/.codex/packages/standalone/releases/, keeping the version yourcodex --versionreports. Do not delete the one in use.Remove
~/.codex/packages/app-server-daemononce the auto-start flag is off.If you installed through Bun or npm, clear the matching
@openaicache entries with the package manager's own cache command rather thanrm, so its index stays consistent.Check for stray git worktrees and temp files left by agent runs. Several HN commenters name those as the real disk hog across all agent tools, not just Codex.
Reopen a session and run
pgrep -fl "app-server". Empty output means the flag took.Leave
~/.codex/config.tomland your session history alone unless you intend to lose them.
If your agents run unattended, the disk is the cheap problem. The expensive one is token spend from long-lived agents you forgot were running. The Agent Run Cost Simulator models a run's token bill before you launch it, and the AI Model Cost Calculator compares per-token prices across providers.
How Claude Code handles background processes and updates
Fairness check: the HN thread does not treat this as a Codex-only habit. One commenter points out that Claude Code uses the same pattern, with old versions kept under ~/.local/share/claude/versions/ and background claude bg processes. That is a commenter's report, so verify it on your own machine with ls ~/.local/share/claude/versions/ before you quote it.
| Question | Codex CLI 0.157.0 and later | Claude Code |
|---|
| Background process after you quit | Daemon on by default, per the 0.157.0 changelog | claude bg processes, per an HN commenter |
| Old versions kept on disk | Reported under ~/.codex/packages/ | Reported under ~/.local/share/claude/versions/ |
| Documented off switch | None found in OpenAI's CLI docs; flag documented only in a bug thread | Check the official docs for your version |
| Updater restarts a running backend | Reported (#40969) | Not reported in the thread |
The honest summary: both tools hoard old binaries. The difference people care about in this thread is the default and the discoverability of the off switch, not the existence of background work. If you run several coding agents side by side, our comparison of Grok Build, Claude Code and Codex covers how their runtimes differ, and the Devin Desktop ACP setup guide shows how to put Codex and Claude behind one IDE.
What to do this week
Set the flag, kill the updater, prune old releases. That takes about five minutes and frees somewhere between 0.4 and several GB, depending on how long you have been upgrading. Then watch issue #48195. The daemon is not malicious, despite what some commenters claim, and the HN thread contains no evidence of that. It is a default that shipped with a one-line release note and an opt-out that existed only in a bug report.
If you run agents for real work, two WOWHOW products pair with this cleanup. The Agent Cost Control Spreadsheet tracks per-run spend, and the Claude Code Production Pack covers settings and hooks for the Claude side of a mixed setup.
Quick answers
Is the Codex CLI daemon safe to disable?
Yes. Disabling auto-start restores the earlier per-session behavior, and the sources in this post describe no feature that depends on the daemon for ordinary interactive use. One HN commenter notes the daemon is useful for apps built on Codex's server, so if you run such a harness, test it after the change.
Which Codex version introduced it?
CLI 0.157.0, dated 2026-09-25 in the OpenAI changelog, via pull request #47179. A reporter on the GitHub issue saw it on 0.157.0, and a user on 0.160.0 said they could see no daemon running, so behavior varies by platform and install method.
Does --no-daemon work?
Two commenters say it does, and one adds that it is needed when elevation blocks startup on Windows. OpenAI's CLI documentation does not mention it. Use the config flag for anything you depend on.
How much disk space does it use?
The issue reporter measured about 374 MB for the daemon's package copy. HN commenters report about 300 MB per old standalone binary and one total near 12 GB. These are user reports, not OpenAI figures.
Why did the config key in another article not work?
A third-party write-up of the release describes a [daemon] table with auto_start and a codex server stop command. The bug report and HN thread use daemon_auto_start under [features] and codex app-server daemon stop instead. Check codex features list on your installed version and trust what your binary prints over any article, this one included.
Sources
- OpenAI Codex CLI documentation
Originally published at wowhow.cloud
Top comments (0)