OpenAI's Codex CLI leaves a self-updating daemon running after you close the terminal

Developers have flagged that OpenAI's Codex CLI starts a background daemon that keeps running after every terminal window is closed, and an independent reproduction confirms the behaviour. According to a dev.to write-up by Neeraj Sharma, the report originated as a GitHub issue on OpenAI's codex repository asking that the daemon be made opt-in, and the thread reached the top of Hacker News. Since version 0.157.0, launching codex interactively also starts a backend process, copies roughly 374 MB of binaries into the home directory and updates itself on a schedule.

What actually runs

Sharma installed Codex CLI 0.157.0 in a clean Linux container with an empty home directory on 13 October 2026 and started the daemon. The tool installed a package under ~/.codex/packages/app-server-daemon and reported a started backend. A process listing then showed two processes, both with parent PID 1: the backend itself and an updater labelled pid-update-loop. Because their parent is the init process rather than any shell, closing the terminal does not stop them.

According to the GitHub issue, the updater checks for a new release five minutes after start and then every hour, downloads the full platform package into a new releases folder and restarts the backend, which can interrupt a turn that is still running. Sharma measured 374 MB under ~/.codex/packages, matching the issue, though he notes he did not wait an hour to watch the update cycle happen. The net effect is a second copy of the CLI that runs from the home directory instead of wherever npm, brew or another package manager put it.

The stop command leaves a process behind

Sharma also reproduced the issue's claim that codex app-server daemon stop stops the backend but leaves the update loop running as an orphan. Removing it completely requires killing that process manually.

Questions for security teams

The dev.to post frames the workplace concerns as three questions that usually have clear answers for every other developer tool:

• What version is running? The daemon self-updates from a copy in the home directory, so the version a package manager pinned may not be the version doing the work; the issue reporter found the two could diverge.
• What environment does it use? The issue reports the daemon keeps the environment of the session that started it, so proxy settings from the first session stuck while settings in later sessions were ignored, which matters where companies route traffic through an inspecting proxy.
• Who approved it? Security teams generally want visibility into software that persists and updates itself, and an opt-out default means many developers will not know it exists.

Sharma is explicit that nothing suggests the daemon is malicious. A long-running backend can make sessions start faster and let several clients share state; the objection is to the default, and to the off switch not being where most people would look.

How to turn it off

A feature flag exists in 0.157.0. Running codex features disable daemon_auto_start writes daemon_auto_start = false to ~/.codex/config.toml, and the issue reporter confirms that a new session no longer starts a daemon afterwards. Existing processes still need cleanup: run the stop command, then kill the orphaned updater, for example with a pkill pattern matching app-server daemon pid-update-loop. To reclaim the disk space, delete ~/.codex/packages/app-server-daemon once both processes are gone.

A broader audit script

Because Codex is not the only AI coding tool on most machines, Sharma published a read-only bash script for macOS and Linux that lists orphaned processes from common AI CLIs such as codex, claude, cursor, gemini, aider, copilot, windsurf and opencode, the disk their self-managed copies consume, and any login items or services that mention them. On his test container it flagged the leftover updater and the 374 MB package. He cautions that the process check matches on names, so the output can include expected processes and should be read before anything is killed.

Why it matters

AI coding assistants are moving from novelty to default install, and they increasingly ship behaviour such as persistence, self-update and background execution that traditional developer tools reserve for explicitly approved services. A daemon that outlives the terminal, inherits the first session's environment and swaps its own binaries hourly sits outside version pinning, change control and endpoint monitoring. The fix here is a single config flag, but only for people who know it exists. Adding "does it persist or self-update?" to the checklist before approving any AI developer tool is a reasonable minimum standard, and Sharma's script offers a quick way to start.