Hot Tracking 019｜Codex CLI defaults to installing an invisible daemon: hits the hot board after 2.5 weeks of silence, OpenAI still has zero response

First, fix the timeline; this time it’s also two lines. On September 25th, user Yihua-Liu-1997 submitted issue #48195 in OpenAI’s Codex CLI repository. The title of the issue was straightforward: to change the default setting from automatic startup of the daemon to an optional option. A persistent, self-updating backend daemon should not be the default. This issue remained silent for two and a half weeks, with only a dozen users leaving comments. On October 12th, it became a hot topic on Hacker News. By the morning of October 13th, it had received over 450 upvotes and 239 comments. The other side of the spread was silence: the issue remains open, and none of the 15 comments came from OpenAI members. The official team has not responded positively as of publication. The following facts are based on the original issue text and Hacker News comments; opinions and textual descriptions are clearly attributed. Numbers refer to October 13th, and events are still being discussed within 48 hours after the incident occurred.

What Happened

According to the reporter, starting from version 0.157.0, when you open an interactive Codex session, four things happen behind the scenes.

First, a persistent backend daemon is started. It runs in a separate session without a terminal interface. Even if all Codex windows are closed, it remains alive. The process is managed by system process number 1 until you manually stop or restart the machine.

Second, a copy of the entire platform package is created in a hidden folder in the user’s directory. The reporter estimated this to be about 374MB, including the Codex ontology and several bundled tools. This copy is byte-for-byte identical to the one installed via the package manager, but it becomes separate from the CLI version you installed, running independently.

Third, a separate updater is started. It checks for updates for the first time 5 minutes after startup and then every hour. When a new version is found, it downloads and automatically restarts the backend, potentially killing ongoing sessions. A more problematic issue discovered by the reporter is that when the executive side stops the daemon, the updater continues to run for 70 seconds before being manually killed. In his words, it’s like removing the turret while leaving the automatic reloader in place.

Fourth, environment variables are set to lock the first session. The reporter used a packaging script to set up proxies for each session, but the daemon remembered the proxy settings of the first session. All subsequent sessions used that same proxy, and it couldn’t be changed.

The reporter’s expectations were modest: for command-line tools, the default setting should be least unexpected—the backend should follow the window’s life and death, run user-installed binaries, and not self-update in the background. A shared self-updating daemon is useful for remote control and desktop applications, where it can be enabled or when the user explicitly runs the startup command. He also suggested a temporary solution: disable automatic startup using codex features disable daemon_auto_start, then manually stop the daemon.

There’s another layer in the timeline. The version that introduced this behavior was 0.157.0, while the latest version on npm is 0.162.1 (October 13th registry data). Five minor versions were iterated between, and the issue remains open with no changes to the default setting announced.

Why “Default” Is the Biggest Problem

Looking at each item individually, we can find arguments for their existence: the daemon is designed for fast response, and automatic updates are for rapid iteration. The problem lies in the fact that all these features combine to form the default behavior, which is the behavior that most users will never change.

At the first level, there’s identity drift. One of the most insightful analyses in the comment section came from user aetherxeg-source, who pointed out a key issue: the CLI installed does not equal the execution identity of the daemon. The tool copies itself into the hosting directory, and the background updater can replace that copy at any time, so the version you installed may not be the same as the one actually running. In the context of supply chain security, this is a standard definition of attack surface: you audit the entry points, but cannot audit the actual code that’s executed.

At the second level, there are changes that cannot be audited. A persistent process that can change into another version every hour means that any security assessment is only valid for up to one hour. For developers who handle company code bases, this is not a matter of theoretical cleanliness; it’s a compliance issue.

At the third level, there’s the real cost of disk space and sovereignty. There are multiple independent reports in the HN comment section: user icantevenhold mentioned that related directories on his system occupied about 12GB; user rfgplk said that all old versions were kept in the release directory, with each binary being 300MB; user AgharaShyam counted 11 copies of about 300MB each in the cache. These numbers are reported by the commenters themselves and not official data, but they all point to the same trend: with self-updates and no deletion of old versions, the size only increases.

Official Position Does Not Match (Audit of Words and Deeds)

OpenAI’s external brand foundation is safety and alignment: from the commitment in its charter to “ensure AGI benefits humanity,” to regular releases of model specifications and security blogs, the core narrative has always been “we understand best how to make AI systems controllable and predictable.” The more grandiose this narrative is, the more striking this layer becomes: a persistent process that runs without consent, self-copies, self-upsdates, automatically restarts, and fixes environment variables, with official stop commands that don’t clean up properly, and no method to shut it down in the configuration documentation.

The lack of documentation was a claim made by user foma-agent on October 12th. According to his own account, he captured the complete official configuration reference page, which even included options for CLI startup check updates, but not a single line mentioning daemon_auto_start. This means that ordinary users cannot shut down this daemon in the official documentation.

Interesting is the reaction of passersby. Charliermarsh, a well-known open-source tool author (author of Ruff and uv, not an OpenAI employee), said in HN that he hadn’t touched the update subsystem, but this seems like a oversight, and he’s willing to fix it. An external open-source author couldn’t stand it, and in the issue of the company involved, there were no official members among the fifteen comments. This comparison itself is an audit result.

Let’s look at the horizontal comparison again. Some people in the comments section pointed out that Claude Code operates under the same model, and posted a similar issue from Anthropic’s repository; the details of this issue have not been independently verified, so we only record the fact that “a similar issue was posted in the comments.” If this is true, it’s not just a single vendor’s oversight, but rather a collective drift in the default behavior of the “AI coding tools” category. The ecosystem has already shown an immune response: the Nix packaging community has specifically patched the software, removing the daemon directly at the packaging level. Commenter whimblepop mentioned that Claude Code’s Nix package was also patched. The package manager community’s vote is clear: such behavior should not be installed on users’ machines.

What the comments say

The highly praised comments in the HN largely split into several factions, and below is a summary of them, not representing the stance of this article.

A minority believes that automatic updates are normal; since these tools evolve quickly, they should update automatically, just like browsers. This was immediately attacked: one user retorted that even my browser requires me to approve updates; another said that fast development doesn’t mean it’s going in the direction I want, nor does it mean I’m willing to be changed mid-project. Automatic updates are valuable, but they shouldn’t be the default for professional tools. Others said that package managers have the capability to update thousands of programs in the background without violating users’ sovereignty over their computers.

The most emotional comment came from user laurynas-karvelis, who directly stated that this is essentially the characteristics of malware and expressed that he didn’t think it was unintentional. User Logarithmus followed up, saying that using such tools to build a web proxy network to intercept web pages wouldn’t be surprising. Note that “malware” and “intentional” are all conclusions made by users in the comments section, not confirmed facts, which this article does not accept as truth.

The practical approach is more calm. User st396gt said that the documentation states that the entire host file system should be fully read and written, so he ran Codex on a hardened Raspberry Pi and connected it remotely, isolating it as an actual user solution. User alexklibisz independently confirmed the issue with environment variables: he used direnv to manage directory-level variables, and Codex running in one directory carried those variables away.

The most widespread comment was a sarcastic one from user jonplackett: the software that claims to end software is actually not very good software.

Three things ordinary users can do

First, if you’re using Codex CLI, turn off automatic startup first: use codex features to disable daemon_auto_start, then execute the daemon stop command, and confirm with the process list that the updater has stopped as well. The person reporting the issue noted that the stop command didn’t stop it completely, so manual review is needed.

Second, check the disk. See how much space the .codex packages folder in the user directory occupies; the numbers reported in the comments range from several hundred MB to 12GB. Older versions aren’t cleaned up automatically, so regularly manually delete unused version directories.

Third, do not run in sensitive environments without protection. For machines that handle company code or have internal network proxies, refer to the isolation solutions in the comment section: run them on dedicated hosts or virtual machines and connect remotely; or use patches from the Nix community, removing the daemon behavior at the packaging level. This principle is the same as when applying emergency brakes in episode 018: you can extend your tool hand, but the switch and the floor must be in your hands.

Conclusion

Prohibition of blame: This article does not accuse any company. Malware and intentional actions are determined by the sentiment in the comment section, which are only relayed and not accepted; verified facts are the actions themselves (as described by the issue reporter), the openness of the issue, and official silence. Negligence and intent are two different things in evidence, but auditing the behavior of this machine does not require a determination of motive: unauthorized permanent presence and self-updating, when applied to any company whose security alignment is its brand foundation, constitute a discrepancy between words and actions. Two points to watch: first, whether OpenAI will respond positively; if official member comments, blog explanations, or changes in default values appear under the issue, any of these will mark the entry into v2; second, if the similar issue posted in Anthropic’s repository is verified, the judgment of category drift will upgrade from “accusations in the comment section” to “facts from both vendors,” and will be updated accordingly.

Reference Sources

• First-hand issue: openai/codex#48195, GitHub API scraping (full body, all 15 comments, labels, state=open, created on 09-25T20:04Z, all commenters’ author_association is NONE)
• HN story 50060694: Algolia data, submitted at 10-12T18:29, snapshot 462▲/239💬 on 10-13 AM, the text uses “over 450▲” tone
• HN comment pool: Two-layer scraping of Algolia items API for 93 entries, representative samples have been entered into the fact package
• npm registry: @openai/codex latest version 0.162.1 (snapshot on 10-13)
• Charliermarsh identity: HN user profile self-proves (author of Ruff/uv, currently working at Spring Discovery), not an OpenAI employee
• Document missing accusation: HN/issue commenter foma-agent self-description (10-12), based on this comment description
• anthropics/claude-code#14980: HN comment posted, content not independently verified, the text is only treated as “similar issue posted in the comment section”
• 374MB/12GB/11 copies of 300MB and other numbers: respectively self-description of the issue reporter and self-reporting by HN users, neither are official data