Researched from primary sources
Fact-checked · Human-approved
Apps & Software

OpenAI’s Codex CLI Now Keeps Running After You Close It — and Developers Want It Opt-In

Since version 0.157.0, opening OpenAI's Codex CLI starts a self-updating background daemon that outlives your terminal. Developers want it opt-in.

Close every Codex window on your machine, and OpenAI’s coding tool may still be running. Since version 0.157.0 of the Codex CLI, released on September 25, starting an interactive session also starts a background daemon that keeps running after the terminal closes, copies hundreds of megabytes of binaries into your home folder, and updates itself on an hourly cycle. A GitHub issue asking OpenAI to make the behavior opt-in reached the front page of Hacker News on October 12 with more than 400 points.

What the daemon actually does

The issue, filed by a developer running the CLI on Linux under WSL2, lays out the mechanics. The daemon runs as its own process with no terminal attached, and it stays alive until you explicitly stop it or reboot. Instead of running the binary you installed, it first copies the entire platform package — about 374 MB — into a releases folder inside ~/.codex and runs from that copy, so the background server’s version is no longer the version your package manager installed.

A separate updater process checks for new releases five minutes after starting and then every hour. When it finds one, it downloads the release and restarts the backend. A linked issue reports that an auto-update can force-kill active work after a 60-second grace period, and that the update check cannot be turned off from the restart path.

The daemon also keeps the environment of whichever session happened to start it. Start Codex once from a shell with a particular proxy setting, and later sessions inherit that setting through the daemon, whether or not it still applies — behavior the project’s own documentation acknowledges for shared clients.

What developers are asking for

The request at the top of the issue is narrow: make auto-start opt-in for the CLI, or at least ask once before turning it on. If the default stays, the reporter proposes two fallbacks — shut the daemon down when its last client disconnects, and stop copying and self-updating when the CLI was installed through a package manager such as npm, Homebrew or pacman.

There is also a reported bug in the off switch itself: stopping the daemon stopped the main server but left the hourly updater process still alive more than a minute later, and the reporter had to kill it manually. Windows and WSL users separately reported the CLI failing to start at all after the change; later releases, from 0.158 through 0.162.1, shipped a series of fixes for those cases, according to an explainer that checked the claims against the project’s release notes and documentation. Some users also report gigabytes of stale release copies piling up in ~/.codex over time.

The case for a shared backend

The daemon exists for a reason. According to its documentation, it provides one shared backend that the terminal, the Codex desktop app and remote or mobile clients can all connect to at once. For anyone using Codex across those surfaces, a long-running server is the sensible design — in the same way that other agent tools keep pushing behavior into the background, a trend that has already produced surprises such as the agent actions that led Anthropic to pull live internet access from its internal evaluations.

The dispute is about the default, and about disclosure. OpenAI’s release notes covered the change in a single line about automatic background-server startup for eligible sessions, and the opt-out setting does not appear in the official CLI documentation — developers found it in the source code and the issue threads. The documented way to turn auto-start off is codex features disable daemon_auto_start; codex --no-daemon skips the daemon for a single session.

As of October 13, the GitHub issue remained open, with no reply from OpenAI in the thread. Until that changes, the daemon stays on by default — and the only notice most users will get is the one they find in their process list.

How we report

Chip Current builds every story from primary sources — company announcements, official filings, and first-party statements — then a human editor verifies the facts before publication. Spotted an error? See our Corrections Policy.

Written & approved by

Dylan Hart

Founder & editor-in-chief of Chip Current. Reviews and approves every story before it publishes.

Related Coverage