Codex CLI Background Daemon: How to Turn It Off

If you installed Codex CLI with npm, brew or a distro package and later found a 300 MB process tree you did not start, you are not imagining it. A GitHub issue asking OpenAI to make the background daemon opt-in reached the Hacker News front page on October 12, 2026, and it describes exactly what happens the moment you run codex.

Last updated: October 12, 2026

If you want the short version of how to turn off the Codex background daemon: disable the daemon_auto_start feature, stop the running daemon, and check that the updater process died with it. The details, and the reasons people are annoyed, are below.

What the primary source says#

The issue (openai/codex #48195) was opened on September 25, 2026 by a user running Codex CLI 0.157.0 on Linux under WSL2. Their account of what an interactive codex session now does:

1. It starts a persistent background process, codex app-server --managed-daemon, in its own session with no terminal. It keeps running after every Codex window is closed until you stop it or reboot.
2. It copies the whole platform package, about 374 MB by the author's measurement, into ~/.codex/packages/app-server-daemon/releases/<version>/ and runs the daemon from that copy. The backend version is then decoupled from whatever your package manager installed.
3. It starts a detached updater, codex app-server daemon pid-update-loop, which checks for new releases five minutes after start and then hourly, downloads them and restarts the backend.
4. The daemon keeps the environment of whichever session started it. The author launches Codex through a wrapper that sets HTTPS_PROXY per invocation, and later sessions still went out through the first session's proxy.

I could not run the daemon myself, so treat those measurements as the reporter's. What I could verify is the origin: the 0.157.0 release notes list "automatic background-server startup for eligible interactive sessions," and the changelog includes pull request #47179, "Enable automatic daemon startup by default." So this is a deliberate default, not a regression.

The workaround, as reported#

The issue author gives this sequence for turning it off:

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

Two caveats. First, the pkill line exists because the author found that daemon stop stops the app-server but leaves the updater loop running. That was on 0.157.0; check ps on your version before assuming it is fixed. Second, a Windows commenter on the same issue reports that daemon_auto_start = false in config.toml resolves it for them, which is the persistent form of the same switch. Nothing here is a documented guarantee, so verify after you apply it: open a new codex session and confirm no app-server process appears.

Why this is more than a disk-space complaint#

The size and clutter are the visible part. The more interesting part is the update model. An older issue, #40969, describes the same updater on long-lived codex remote-control hosts. Its author traced the source and reports that when a new release lands, the daemon sends SIGTERM to the app-server, waits a 60 second grace period and then sends SIGKILL, even if assistant turns are still running. On their host that meant every attached client dropped at once and turns running 3 to 30 minute build and test suites were terminated. A second reporter in that thread saw the same thing on macOS across 0.152.0 to 0.152.1, with one session about 4 hours 45 minutes in.

Note the layers: #40969 is titled "cannot be disabled" because it concerns the updater on a remote-control daemon, while daemon_auto_start controls whether a normal session starts the daemon at all. Turning off auto-start is what keeps the updater from being launched by plain codex sessions; if you run codex remote-control yourself, the updater concern still applies.

Those reports are about the remote-control setup, and the issue is still open, so I would not claim an ordinary single-window session loses work every hour. But if you run unattended or long agent turns, the combination of an hourly update check and a 60 second drain budget is the thing to understand before leaving it on.

What a builder does Monday#

The decision turns on how you use Codex:

• One interactive window at a time: the daemon mostly costs you disk and a surprise process. Disabling it is a preference, not an emergency.
• Package-managed install (nix, Arch, brew, npm): the daemon copies and self-updates outside your package manager, which defeats pinning. The issue links reports from an Arch Linux user and a request for externally managed executables. Two commits referenced from the issue show nix users disabling it by default in their packaging.
• Long unattended runs or CI: do not rely on the daemon. Run the headless path instead, covered in our codex exec CI guide, and pin the version you tested. Budget long runs with the limits in Codex CLI Resource Budgets.
• Multiple worktrees with different proxy or environment settings: the pinned-environment behavior is the one that bites. Related, the 0.162.1 patch we covered in Codex CLI 0.162 fixed startup failures caused by a running background server's feature settings differing from the CLI defaults.

The angle for the vendor is a trade-off, not a villain story. A shared daemon makes resuming sessions, remote control and fast startup possible, and the issue author concedes it "makes sense for Remote Control / the desktop app." The ask is narrower: enable it where it earns its keep, exit it when the last client disconnects, and do not self-update an install your package manager owns. That is the same gap anyone running agents as long-lived infrastructure runs into, which we cover in Long-Running Agents Need Harnesses.

What people are actually saying#

The Hacker News thread had 93 points and 37 comments when I read it. Paraphrasing the main camps:

• Defaults for professional tools: several commenters argue that auto-update is not an acceptable default for a tool that edits your code, and that package managers already update software without each app installing itself its own way.
• Disk clutter: one commenter reports about 12 GB of old versions on their machine and another points to .codex/packages/standalone/releases keeping every previous version, with each binary around 300 MB. These are anecdotes, not measurements I reproduced.
• The counter-case: one commenter argues the space moves fast and harnesses should update automatically, like browsers. Replies pushed back that Firefox on their setup does not force a restart, so the analogy is shaky.
• Not just Codex: another commenter says Claude Code works the same way, with prior binaries under ~/.local/share/claude/versions/ and background tasks running without a foreground session. I did not verify that, but it is a fair reminder to check any agent CLI you run.

FAQ#

How do I turn off the Codex CLI background daemon?#

The issue author reports that codex features disable daemon_auto_start stops new sessions from spawning it and codex app-server daemon stop stops a running one. A commenter reports daemon_auto_start = false in config.toml also works. Verify with ps afterward.

Since which version does it start automatically?#

0.157.0, released September 25, 2026, per the release notes.

Does stopping the daemon stop the updater?#

Not on 0.157.0, according to the issue author. The pid-update-loop process survived and had to be killed by hand.

Continue Reading#

• Codex CLI 0.162: Managed Worktrees and Pinned Tasks - the latest release and its background-server fix
• Codex CLI Resource Budgets - limits that apply to long runs
• Codex exec in CI - the headless path that avoids the daemon question
• Long-Running Agents Need Harnesses - why agent infrastructure needs explicit lifecycle control
• Codex CLI Worktrees and Durable Sessions - how sessions persist across checkouts

Sources#

• openai/codex #48195: make daemon_auto_start opt-in - opened September 25, 2026
• openai/codex #40969: app-server daemon auto-update force-kills active turns - opened August 26, 2026
• Codex CLI 0.157.0 release notes - OpenAI, September 25, 2026
• Hacker News discussion