Hot Tracking 019｜Codex CLI installiert standardmäßig einen unsichtbaren Daemon: Nach zweieinhalb Wochen Stille auf die Trendliste gesprungen, OpenAI bis heute ohne Reaktion

Zuerst werden die Zeitangaben festgelegt, diesmal sind es ebenfalls zwei Linien. Am 25. September stellte der Benutzer Yihua-Liu-1997 einen Issue #48195 im Codex CLI-Repository von OpenAI ein. Der Titel des Issues war sehr direkt: Die automatische Startung des Wächteprozesses sollte als Option deaktiviert werden, ein persistentes, selbstaktualisierendes Hintergrundprozess sollte nicht standardmäßig eingeschaltet sein. Dieser Issue blieb zweiinhalb Wochen lang unbeachtet, nur wenige Dutzend Benutzer haben Kommentare hinterlassen. Am 12. Oktober wurde er auf Hacker News ins Rampenlicht gerückt, bis zum Morgen des 13. Oktober waren es bereits über 450 Unterstützungsstimmen und 239 Kommentare. Auf der anderen Seite der Verbreitung herrschte Stille: Der Issue ist bis heute offen geblieben, keiner der 15 Kommentare kam von Mitgliedern von OpenAI, und bis zum Zeitpunkt der Veröffentlichung gab es keine direkte Antwort seitens des Unternehmens. Die folgenden Fakten basieren auf dem Originaltext des Issues und den Kommentaren auf Hacker News; die Ansichten und Bewertungen sind entsprechend gekennzeichnet. Die Zahlen beziehen sich auf den 13. Oktober, die Ereignisse finden noch innerhalb der 48 Stunden nach der Weiterentwicklung statt.

Was geschah

Laut der Beschreibung des Reportierten begann ab der Version 0.157.0, wenn man eine interaktive Codex-Sitzung öffnet, vier Dinge zu geschehen:

Erstens: Ein persistenter Hintergrundprozess wird gestartet. Er läuft in einer separaten Sitzung ohne Terminaloberfläche und überlebt auch dann, wenn alle Codex-Fenster geschlossen werden. Der Prozess wird vom Systemprozess Nummer 1 verwaltet, bis man ihn manuell stoppt oder den Computer neu startet.

Zweitens: Eine Kopie des gesamten Pakets wird in eine versteckte Datei im Benutzerverzeichnis kopiert. Der Reporter schätzt die Größe auf etwa 374MB, das Inhalt ist die Codex-Datenbank und einige zusätzliche Tools. Diese Kopie ist genauso groß wie die, die mit dem Paketmanager installiert wurde, aber ab diesem Punkt sind die Backend-Version und die installierte CLI-Version getrennt, jede für sich.

Drittens: Ein separater Update-Manager wird gestartet. Nach 5 Minuten beim Start wird der erste Update überprüft, danach alle Stunden. Wenn eine neue Version verfügbar ist, wird der Backend automatisch neu gestartet, und die laufende Sitzung könnte direkt beendet werden. Ein weiterer Problempunkt, den der Reporter entdeckte, ist: Wenn der Befehl zum Stoppen des Executives ausgeführt wird, stoppt der Hintergrundprozess, aber der Update-Manager läuft weiterhin 70 Sekunden lang, bis er manuell beendet werden muss. Mit seinen eigenen Worten: Es ist, als würde man die Batterie entfernen, während der Automatische Ladevorgang weiterläuft.

Viertens: Die Variablen des ersten Termins werden festgelegt. Der Reporter benutzte eine Skriptdatei, um die Proxy-Konfigurationen nacheinander einzustellen. Dadurch merkte sich der Hintergrundprozess die Konfiguration des ersten Termins, und alle späteren Sitzungen nutzten denselben Proxy, was nicht geändert werden konnte.

Die Erwartungen des Reportierten waren bescheiden: Für die Befehlszeile sollte das Standardverhalten am wenigsten überraschend sein: Das Backend sollte mit dem Fenster leben und sterben, die von den Benutzern installierten Binärdateien sollten laufen, ohne sich selbst zu aktualisieren; ein gemeinsamer Hintergrundprozess für Updates wäre für Remote-Kontrolle und Desktop-Anwendungen nützlich, der dort aktiviert werden könnte oder wenn der Benutzer explizit den Startbefehl ausführt. Er schlug auch eine vorübergehende Lösung vor: Den automatischen Start mit codex features disable daemon_auto_start deaktivieren und anschließend den Hintergrundprozess manuell stoppen.

Auf der Zeitachse gibt es noch einen weiteren Schritt. Die Version, in der dieses Verhalten eingeführt wurde, war 0.157.0, während die neueste Version auf npm 0.162.1 ist (Daten vom 13. Oktober). Zwischenzeitlich wurden 5 kleinere Versionen iteriert, der Issue ist immer noch offen, und es gibt keine Ankündigung über eine Änderung des Standardwerts.

Warum „Standard“ das größte Problem ist

Wenn man jedes einzelne Element betrachtet, findet man Verteidigungsargumente: Der Wächterprozess dient der schnellen Reaktion, die automatische Aktualisierung der Schnelligkeit der Iteration. Das Problem liegt darin, dass sie alle zusammen das Standardverhalten bilden, und dieses Standardverhalten ist das Verhalten, das die meisten Nutzer niemals ändern werden.

Erstens, Identitätsverschiebung. Die tiefgründigste Analyse im Kommentarbereich stammt von dem Benutzer aetherxeg-source, der einen Trennstrich zwischen der installierten CLI-Identität und der Ausführungsidentität des Wächterprozesses aufzeigt. Das Tool kopiert sich in den Host-Verzeichnis, und der Hintergrund-Updater kann jederzeit diese Kopie ersetzen, sodass die installierte Version nicht immer mit der tatsächlich laufenden Version übereinstimmt. Im Kontext der Supply-Chain-Sicherheit ist dies genau die Definition einer Angriffsfläche: Wenn man den Eingang überprüft, kann man den eigentlichen ausführenden Code nicht überprüfen.

Zweitens, unüberprüfbare Veränderungen. Ein dauerhaft laufender Prozess, der jede Stunde zu einer anderen Version werden kann, bedeutet, dass die Gültigkeitsdauer jeder Sicherheitsprüfung maximal eine Stunde beträgt. Für Entwickler, die mit diesem Prozess arbeiten und Unternehmenscodebibliotheken verarbeiten, handelt es sich nicht um theoretische Präzisionstoleranz, sondern um Konformitätsprobleme.

Drittens, der tatsächliche Preis von Festplatten und Sovereignty. Im HN-Kommentarbereich gibt es mehrere unabhängige Berichte: Der Benutzer icantevenhold behauptet, dass die entsprechenden Verzeichnisse auf seinem System insgesamt etwa 12GB einnehmen; der Benutzer rfgplk sagt, dass das Veröffentlichungsverzeichnis alle alten Versionen speichert, wobei jeder Binärdatei 300MB zustehen. Der Benutzer AgharaShyam gibt an, dass im Cache 11 Kopien von etwa 300MB vorhanden sind. Diese Zahlen stammen von den Kommentatoren selbst und sind keine offiziellen Daten, aber die Richtung ist dieselbe: Mit Selbstaktualisierung und ohne Löschung der alten Versionen nimmt das Volumen nur zu.

Die offizielle Position stimmt nicht überein (Audit der Worte und Taten)

Das Markenfundament von OpenAI im Ausland ist Sicherheit und Zielorientierung: Von dem Verpflichtung in der Satzung „Sicherstellen, dass AGI zum Wohle der Menschheit eingesetzt wird“ bis hin zu regelmäßigen Veröffentlichungen von Modellstandards und Sicherheits-Blogs, ist die Kernbotschaft immer gewesen: „Wir verstehen am besten, wie AI-Systeme kontrollierbar und vorhersehbar gemacht werden können.“ Je größer diese Botschaft ist, desto deutlicher wird dieser Aspekt für die offizielle Stelle: Ein dauerhaft laufender Prozess ohne Zustimmung, der sich selbst kopiert, selbst aktualisiert, automatisch startet und Eigenschaften festlegt, wobei die offiziellen Stopp-Befehle nicht ordentlich beendet werden können und in den Konfigurationsdokumenten keine Methode zum Schließen gefunden wird.

Die fehlenden Dokumente sind ein Vorwurf, den der Benutzer foma-agent am 12. Oktober im Kommentarbereich vorbrachte. Nach seinen Angaben: Er hat die vollständige offizielle Konfigurationsseite abgerufen, in der sogar die Startprüfung und Aktualisierungsoptionen für die CLI selbst beschrieben sind, aber nicht eine Zeile über daemon_auto_start erwähnt. Das bedeutet, dass gewöhnliche Nutzer keinen Weg finden, diesen Wächterprozess zu schließen, da es in den offiziellen Dokumenten keinen Weg gibt.

Interessant ist die Reaktion der Passanten. Der bekannte Autor öffentlicher Tools, charliermarsh (Autor von Ruff und uv, nicht Mitglied von OpenAI), sagte im HN-Bereich, dass er das Aktualisierungssystem nie angefasst habe, aber das scheint eine Vernachlässigung zu sein, und er ist bereit, dies zu korrigieren. Ein externer öffentlicher Autor konnte es nicht ertragen, während die fünfzehnte Kommentar unter dem Issue der betroffenen Firma keine offiziellen Mitglieder erwähnt. Diese Kontrastierung selbst ist ein Auditresultat.

Schauen wir uns das Querformat noch einmal an. In der Kommentarbereich haben einige darauf hingewiesen, dass Claude Code denselben Betriebsmodus hat, und ein ähnliches Problem aus dem Anthropic-Repository gezeigt. Der genaue Inhalt dieses Problems wurde nicht unabhängig überprüft, hier wird nur die Tatsache festgehalten, dass „ähnliche Probleme in der Kommentarbereich gezeigt wurden“. Wenn dies wahr ist, dann handelt es sich nicht um eine einzelne Nachlässigkeit eines Herstellers, sondern um eine kollektive Veränderung des Verhaltens in der Kategorie „AI-Code-Werkzeuge“. Das Ökosystem zeigt bereits eine Immunreaktion: Die Nix-Packaging-Community hat Patches vorgenommen und die Schutzprozesse direkt im Packaging-Schritt entfernt. Der Kommentator whimblepop erwähnte, dass auch der Nix-Paket von Claude Code gepatcht wurde. Die Community des Paketmanagers hat ihre Meinung klar geäußert: Solches Verhalten sollte nicht auf den Rechnern der Nutzer installiert werden.

Was sagen die Kommentare

Die hochbewerteten Kommentare in HN lassen sich grob in mehrere Gruppen einteilen. Im Folgenden wird eine Zusammenfassung gegeben, die nicht die Position dieses Artikels repräsentiert.

Die Minderheit glaubt, dass automatische Updates normal sind. Da solche Tools schnell entwickelt werden, sollten sie automatisch aktualisiert werden, genau wie bei den Browsern. Dies wurde sofort kritisiert: Ein Nutzer antwortete, dass sein Browser auch die Aktualisierung erfordert; ein anderer sagte, dass die Schnelligkeit des Produkts nicht bedeutet, dass es in die richtige Richtung läuft, und noch weniger bedeutet, dass man bereit ist, im Laufe des Projekts geändert zu werden. Automatische Updates sind wertvoll, aber sie sollten nicht als Standard für professionelle Tools gelten. Ein anderer sagte, dass der Paketmanager vollkommen in der Lage ist, tausende von Programmen im Hintergrund zu aktualisieren, ohne die Souveränität des Nutzers über seinen Computer einzuziehen.

Der emotionalste Kommentar kam von dem Nutzer laurynas-karvelis. Er sagte offen, dass dies eher den Merkmalen von Schadsoftware entspricht, und meinte, dass er das nicht absichtlich getan habe. Der Nutzer Logarithmus fuhr fort, dass es nicht verwunderlich wäre, wenn man mit diesen Tools eine Web Proxy-Netzwerk zu bauen würde, um Webseiten zu blockieren. Beachten Sie, dass „Schadsoftware“ und „absichtliches Handeln“ nur die Bewertungen der Kommentatoren sind, keine bewiesenen Schlussfolgerungen, die in diesem Artikel als Fakten angenommen werden.

Die Pragmatiker waren ruhiger. Der Nutzer st396gt sagte, dass in den Dokumenten steht, dass das gesamte Host-System-Dateisytem vollständig lesbar und schreibbar sein soll. Deshalb läuft er Codex auf einem gepanzerten Raspberry Pi und verbindet ihn über das Netzwerk, was eine isolierte Ausführung zur tatsächlichen Maßnahme des Nutzers macht. Der Nutzer alexklibisz bestätigte das Problem mit Variablen: Er verwendet direnv, um Variablen auf der Ebene der Ordner zu verwalten, und Codex, der in einem Ordner läuft, nimmt die Variablen mit.

Der weit verbreitetste Kommentar war ein Spott, vom Nutzer jonplackett: Die Software, die behauptet, Software zu beenden, ist selbst keine besonders gute Software.

Drei Dinge, die normale Nutzer tun können

Erstens, wenn Sie den Codex CLI verwenden, schalten Sie bitte das automatische Starten ab: Verwenden Sie codex features disable daemon_auto_start, führen Sie dann den Befehl zur Stoppung des Daemon aus und überprüfen Sie mit der Prozessliste, ob auch der Aktualisierer gestoppt wurde. Die Lektion für die Berichterstatter ist, dass der Stopp-Befehl nicht ordentlich stoppt, und man muss manuell überprüfen.

Zweitens, schauen Sie sich den Festplattenträger an. Überprüfen Sie, wie viel Speicher der .codex-Paket-Folder im Benutzerordner einnimmt. Die Zahlen, die in der Kommentarbereich angegeben wurden, variieren von einigen hundert MB bis 12 GB. Alte Versionen werden nicht automatisch gelöscht, also löschen Sie regelmäßig die nicht mehr benötigten Versionen manuell.

Drittens: In sensiblen Umgebungen soll man nicht offen herumlaufen. Bei Geräten, die Firmencode verarbeiten oder über eine internes Proxy-System verfügen, sollte man sich an die Isolationstrategien im Kommentarbereich halten: Entweder läuft es auf einem speziellen Host oder in einer virtuellen Maschine, und man verbindet es über die Ferne; oder man verwendet eine gepatchte Paketversion von der Nix-Community, indem man die Aufgaben des Wartungsprozesses entfernt. Das Prinzip ist genauso wie in der 018-Ausgabe, als es zu einem Notstop kam: Die Hand des Tools kann ausgestreckt werden, aber der Schalter und der Boden müssen in deinen Händen sein.

Schlussfolgerung

Warnung: In diesem Artikel wird keine Firma beschuldigt. Malware oder vorsätzliche Handlungen sind eine subjektive Beurteilung im Kommentarbereich, die hier nur wiedergegeben werden, nicht akzeptiert. Die bereits überprüften Fakten sind die Handlungen selbst (gemäß der Beschreibung des Berichterstatters), der offene Status des Issues und das Schweigen der offiziellen Stelle. Versäumnisse und Absicht sind zwei verschiedene Dinge, aber eine Überprüfung der eigenen Handlungen erfordert keine Motivationsfeststellung: Unbefugte dauerhafte Anwesenheit und selbstständige Aktualisierung stellen bei jeder Firma, deren Sicherheitsausrichtung ihr Markenprinzip ist, eine Diskrepanz zwischen Wort und Tat dar. Zwei Punkte, auf die man achten sollte: Erstens, ob OpenAI eine positive Reaktion zeigt. Wenn offizielle Kommentare von Mitgliedern, Blogbeschreibungen oder Änderungen der Standardwerte im Issue auftauchen, ist dies ein Anzeichen für eine V2-Version; zweitens, wenn die in Anthropics’ Repository geposteten Ähnlichkeiten mit dem Issue überprüft wurden, wird die Beurteilung der Kategorieverschiebung von „Kommentarbereichsanklage“ auf „Fakten beider Anbieter“ erhöht, und dann wird ebenfalls aktualisiert.

Referenzquellen

• Erste Quelle für den Issue: openai/codex#48195, GitHub API-Aufzeichnung (Volltext des Körpers, alle 15 Kommentare, Labels, state=open, erstellt am 09-25T20:04Z, alle Autoren des Kommentars sind NONE)
• HN Story 50060694: Algolia-Daten, eingereicht am 10-12T18:29, Snapshot am 10-13 Uhr 462▲/239💬, der Text mit „über 450▲“ angegeben
• HN-Kommentarpool: Algolia-items-API-Aufzeichnung von 93 Einträgen, repräsentative Beispiele wurden in die Faktenpakete eingetragen
• npm Registry: @openai/codex neueste Version 0.162.1 (Snapshot vom 10-13)
• Charliermarsh Identität: HN-Benutzerprofil bestätigt sich selbst (Autor von Ruff/uv, derzeit bei Spring Discovery tätig), nicht Mitglied von OpenAI
• Dokumentationslücken bei der Anklage: HN/Issue-Kommentator foma-agent selbst erklärt (10-12), basierend auf diesem Kommentar
• anthropics/claude-code#14980: HN-Kommentar gepostet, der Inhalt wurde nicht unabhängig überprüft, der Text wird nur als „Ähnlichkeiten mit dem Issue im Kommentarbereich“ behandelt
• 374MB/12GB/11 Versionen von 300MB und ähnliche Zahlen: Sowohl die Selbstbeschreibung des Issue-Berichterstatters als auch die Selbstanzeige eines HN-Benutzers sind keine offiziellen Daten