Companies · Opinion
Codex CLI plants a self-updating server on laptops and procurement should refuse it
Since version 0.157.0, OpenAI's Codex CLI leaves a self-updating background daemon running. Buyers should make opt-in installs a written condition of every AI developer-tool contract.
Since version 0.157.0, opening OpenAI's Codex CLI in a terminal also starts codex app-server --managed-daemon, a process with no terminal attached that keeps running after every Codex window is closed. It stops when someone types codex app-server daemon stop or the machine reboots. On the way in, it copies roughly 374 MB of binaries into the user's home directory and runs from that copy. A second process checks for new releases five minutes after starting and then every hour, downloads them and restarts the backend. All of this is laid out in issue #48195 on the openai/codex repository, opened on 25 September by a developer posting as Yihua-Liu-1997.
I expected the usual grumbling about an annoying default. What I read was closer to an incident report that someone's security team should have written first. The daemon keeps the environment of whichever session launched it. The reporter sets HTTPS_PROXY per invocation through a wrapper, yet later sessions sent their outbound traffic through the first session's proxy anyway. Picture a contractor who routes each client's work through that client's proxy, and an agent quietly sending one client's traffic down another's path. The stop command, meanwhile, left the updater alive 70 seconds later; the reporter had to kill it by hand. A separate issue, #40969, reports that auto-update force-kills active agent turns after a 60-second drain and cannot be switched off.
Read that list as a buyer and every item maps to a line on a vendor security questionnaire: what runs on our endpoints, which version, who can change it, and which network path it uses. Because the daemon runs its own copy, its version no longer follows what npm or brew installed. Your software inventory reads the package manager, so it reports a version that may not be the one doing the work. The Arch Linux package, according to issue #48050, would not start at all without --no-daemon.
I can see why OpenAI built it this way. The desktop app and Remote Control want a shared backend that stays up, and even the reporter agrees the design makes sense there. I suspect keeping every install on the newest build also shrinks the number of versions OpenAI has to support. That saving goes to OpenAI, while customers pay in disk space, traffic through the wrong proxy, killed turns and the hours IT spends tracing a process nobody approved.
The serious defence of auto-update is security. Check Point Research found that Codex CLI loaded and ran tool-server entries from a repository's own config files at startup, without asking, so a planted file could run arbitrary commands on a developer's machine (CVE-2025-61260). OpenAI fixed it in version 0.23.0, and anyone who never updated stayed exposed. I agree stale installs are dangerous, but I think the update channel belongs to the customer. Companies already push patches through package managers and endpoint management; what they need from a vendor is quick releases and honest notice. Vendor-pushed updates at scale have a history too: Microsoft said the faulty CrowdStrike update in July 2024 hit 8.5 million Windows devices. And AI coding tools are already a target. In the Nx attack of 26 August 2025, malicious npm versions turned Claude, Gemini and Amazon Q command-line tools against their owners using flags like --yolo and --trust-all-tools, and thousands of GitHub repositories were compromised. An hourly downloader feeding a persistent process with agent-level file access gives the next attacker a better channel.
So write it down. Every AI developer-tool contract should say that no persistent background process or self-updater runs unless a customer administrator enables it, that the binary executing is the one the package manager installed, that changes to defaults of this kind are announced in writing before release, and that the stop command stops everything the tool started. None of that is expensive to honour. A commit titled "codex: disable daemon auto-start by default" referencing the issue appeared on 28 September, yet the issue remained open more than two weeks later, and the reporter's own workaround ends in pkill and rm -rf.
Before your next renewal with OpenAI or anyone selling a coding agent, ask your endpoint team to search developer machines for ~/.codex/packages/app-server-daemon and for running processes matching pid-update-loop, then put the count of hits on the table when the account manager asks why you want the clause.
Prompted by CLI: make `daemon_auto_start` opt-in — a persistent, self-updating background daemon shouldn't be the default, github.com.