Hot Tracking 019｜Codex CLI installe par défaut un démon invisible : resté silencieux pendant deux semaines et demie avant d’exploser en tendance, OpenAI n’a toujours pas répondu

Définir d’abord les dates : cette fois encore, deux lignes. Le 25 septembre, l’utilisateur Yihua-Liu-1997 a soumis une issue #48195 dans le dépôt CLI de OpenAI, avec une demande claire : faire en sorte que le processus de garde se lance automatiquement soit un choix optionnel, car un processus de garde permanent et auto-updaté ne devrait pas être par défaut. Cette issue est restée silencieuse pendant deux semaines et demie, avec seulement quelques dizaines d’utilisateurs ayant commenté. Le 12 octobre, elle a été mise en avant sur Hacker News, et au matin du 13 octobre, plus de 450 votes de soutien et 239 commentaires avaient été reçus. De l’autre côté, il y a eu un silence : l’issue est toujours ouverte, et aucun des 15 commentaires n’est venu d’un membre d’OpenAI. À ce moment-là, l’équipe officielle n’a pas répondu directement. Les faits suivants sont basés sur le texte original de l’issue et les commentaires de Hacker News ; les opinions et les définitions sont marquées comme provenant de l’une ou l’autre source. Les chiffres sont basés sur le 13 octobre, et l’événement se produit dans la période de 48 heures suivant son déclenchement.

Que s’est-il passé

Selon le rapportant de l’issue, à partir de la version 0.157.0, vous ouvrez simplement une session Codex interactive, qui effectue quatre actions en arrière-plan.

Premièrement, un processus de garde permanent est lancé. Il fonctionne dans une session indépendante, sans interface de terminal ; vous fermez toutes les fenêtres Codex et il continue de fonctionner. Le processus est géré par le processus numéro 1 du système, jusqu’à ce que vous arrêtez manuellement ou redémarriez l’ordinateur.

Deuxièmement, une copie de tout le paquet de la plateforme est copiée dans un dossier caché dans le répertoire des utilisateurs. Le rapportant indique qu’elle mesure environ 374MB et contient le corps Codex et plusieurs outils associés. Cette copie est identique en taille à celle installée avec le gestionnaire de paquets, mais elle est désormais indépendante de la version CLI installée par l’utilisateur, chacune fonctionnant séparément.

Troisièmement, un outil d’update distinct est lancé. Une vérification des mises à jour a lieu au premier minute après le démarrage, puis toutes les heures. Lorsqu’une nouvelle version est trouvée, elle est téléchargée et le backend est redémarré automatiquement, interrompant la session en cours. Un problème supplémentaire découvert par le rapportant : lorsque l’ordre de stoppage est donné depuis l’administrateur, le processus de garde s’arrête, mais l’outil d’update continue de fonctionner pendant 70 secondes, jusqu’à ce qu’il soit nécessaire de l’arrêter manuellement. Selon lui, c’est comme si la tourelle avait été retirée, laissant le mécanisme d’armement en place.

Quatrièmement, les variables d’environnement de la première session sont définies. Le rapportant utilisait des scripts pour configurer les proxy une par une, mais le processus de garde a mémorisé les configurations du proxy de la première session, et toutes les connexions sortantes des sessions suivantes utilisaient ce même proxy, sans possibilité de modification.

Les attentes du rapportant étaient modérées : pour les outils commande ligne, le mode par défaut devrait être celui où le backend fonctionne avec la fenêtre, où les binaires installés par l’utilisateur sont exécutés et ne se mettent pas à jour en arrière-plan ; un processus de garde partagé pour l’auto-update est utile pour le contrôle distant et les applications de bureau, qui peuvent être activées là-bas ou lorsque l’utilisateur exécute manuellement l’ordre de démarrage. Il a également proposé une solution temporaire : désactiver l’automatique avec codex features disable daemon_auto_start, puis arrêter manuellement le processus de garde.

Il y a aussi une autre étape dans l’histoire. La version qui introduit cette fonctionnalité est 0.157.0, tandis que la dernière version sur npm est 0.162.1 (données du registre du 13 octobre). Il y a eu 5 versions intermédiaires, mais l’issue reste ouverte et aucune modification du mode par défaut n’a été annoncée.

Pourquoi « par défaut » est le plus grand problème

Si l’on examine chacun des éléments, on trouve des arguments en faveur de ces pratiques : le processus de surveillance est conçu pour répondre rapidement, et les mises à jour automatiques visent à assurer une iterabilité rapide. Le problème réside dans le fait que tous ces éléments se superposent pour former un comportement par défaut, qui est celui que la plupart des utilisateurs ne modifieront jamais.

Premièrement, il y a le phénomène de dérive identitaire. Un analyseur de la section des commentaires, aetherxeg-source, a souligné une limite dans l’établissement de la trace : l’identité du CLI installé n’est pas équivalente à l’identité d’exécution du processus de surveillance. L’outil se copie dans le répertoire géré par le serveur, et le module de mise à jour peut remplacer cette copie à tout moment, ce qui signifie que la version installée et celle qui est réellement exécutée ne sont pas toujours identiques. Dans le contexte de la sécurité de la chaîne d’approvisionnement, c’est précisément la définition standard de l’espace d’attaque : vous auditez l’entrée, mais vous ne pouvez pas auditer le code qui est réellement exécuté.

Deuxièmement, il y a les changements imprévisibles. Un processus permanent qui peut se transformer en une autre version toutes les heures signifie que la durée d’efficacité de toute évaluation de sécurité n’est que d’une heure. Pour les développeurs qui travaillent sur des bibliothèques de code d’entreprise, ce n’est pas une question de pureté théorique, mais une question de conformité.

Troisièmement, il y a le coût réel de la réserve de données et du contrôle des variables. Plusieurs rapports indépendants ont été publiés dans la section des commentaires de HN : l’utilisateur icantevenhold affirme que les répertoires concernés occupent environ 12 Go sur son système ; l’utilisateur rfgplk dit que le répertoire de publication conserve toutes les versions anciennes, avec chacun des fichiers en 300 Mo ; l’utilisateur AgharaShyam indique qu’il y a 11 copies d’environ 300 Mo dans la réserve de données. Ces chiffres sont fournis par les commentateurs eux-mêmes et ne sont pas des données officielles, mais ils montrent une tendance constante : avec les mises à jour automatiques sans suppression des versions anciennes, la taille du système ne cesse d’augmenter.

Le discours officiel ne correspond pas aux faits (audit des actions et paroles)

Le fondement de la marque OpenAI est la sécurité et l’alignement sur les objectifs humanitaires : depuis la promesse de « garantir que l’AGI bénéficie à l’humanité » dans ses statuts, jusqu’aux normes de modèles publiées régulièrement et aux blogs de sécurité, l’histoire principale est toujours celle de « nous savons comment rendre les systèmes d’IA contrôlables et prévisibles ». Plus cette histoire est grandiose, plus cette contradiction devient évidente : un processus permanent sans consentement, se copiant, se mettant à jour, se réinitialisant automatiquement, fixant les variables d’environnement, avec des commandes officielles qui ne cessent pas de fonctionner, et sans méthode officielle pour arrêter le système dans les documents de configuration.

L’absence de documents officiels est une accusation formulée par l’utilisateur foma-agent le 12 octobre ; selon ses propres dires, il a collecté la page complète de référence de configuration officielle, où même les options d’actualisation du CLI sont mentionnées, mais pas une seule ligne mentionnant daemon_auto_start. Cela signifie que les utilisateurs ordinaires ne trouvent pas de moyen d’arrêter ce processus de surveillance dans les documents officiels.

Intéressant est la réaction des passants. Charliermarsh, auteur de logiciels open source renommé (auteur de Ruff et uv, mais pas membre d’OpenAI), a déclaré sur HN qu’il n’avait jamais manipulé le sous-système de mise à jour, mais cela semble être une négligence qu’il est prêt à corriger. Un auteur open source extérieur ne peut pas supporter cette situation, et le cinquantième commentaire sous l’issue de l’entreprise concernée ne contient aucun membre officiel. Cette comparaison elle-même est un résultat d’audit.

Regard cela horizontalement. Certains ont souligné dans les commentaires que Claude Code utilise le même modèle de fonctionnement, et ont posté une question similaire dans le dépôt d’Anthropic ; le contenu exact de cette question n’a pas été vérifié indépendamment, donc ici, nous enregistrons simplement le fait que « une question similaire a été postée dans les commentaires ». Si cela est vrai, ce n’est pas une négligence d’un seul fournisseur, mais plutôt un comportement par défaut de la catégorie des « outils de codage AI » qui se diffuse collectivement. L’écosystème a déjà montré une réaction immunitaire : la communauté de paquetage Nix a spécialement patché le logiciel, en retirant directement le processus de protection au niveau du paquetage. Le commentateur whimblepop a mentionné que le paquet Nix de Claude Code avait également été patché. La communauté des gestionnaires de paquets exprime clairement son opinion : ce genre de comportement ne devrait pas être par défaut sur les machines des utilisateurs.

Qu’en disent les commentaires

Les commentaires très populaires sur HN se divisent principalement en plusieurs groupes, et voici leur résumé, sans représenter la position de cet article.

Une minorité pense que l’automatisation de l’update est normale, car avec une rapidité d’évolution, il est logique que le logiciel s’actualise automatiquement, comme c’est le cas pour les navigateurs. Cela a immédiatement été critiqué : un utilisateur a répondu en disant que même son navigateur nécessite sa validation pour les mises à jour ; un autre a dit que la rapidité avec laquelle le produit fonctionne ne signifie pas qu’il se dirige vers la direction souhaitée par l’utilisateur, et encore moins qu’il est acceptable de changer de logiciel au milieu du projet. L’automatisation de l’update est utile, mais elle ne devrait pas être par défaut pour un outil professionnel ; d’autres ont dit que les gestionnaires de paquets sont entièrement capables de mettre à jour plusieurs milliers de programmes en arrière-plan sans violer la souveraineté de l’utilisateur sur son ordinateur.

Le commentaire le plus émotionnel vient de l’utilisateur laurynas-karvelis, qui a déclaré que cela ressemblait aux caractéristiques d’un logiciel malveillant et a souligné qu’il ne pensait pas que cela avait été fait intentionnellement. L’utilisateur Logarithmus a continué en disant que, selon cette logique, il n’aurait rien eu de surprenant de construire une réseau de proxy pour capturer les pages web avec ces logiciels. Notez que « logiciel malveillant » et « fait intentionnellement » sont des définitions des commentateurs, pas des conclusions confirmées, et cet article ne les accepte pas comme faits.

Les partisans de la pratique plus calmes. L’utilisateur st396gt a dit que le document indiquait que le système de fichiers entier du ordinateur devait être lu et écrit complètement, donc il a exécuté Codex sur un Raspberry Pi renforcé et l’a connecté en distance, ce qui est devenu la stratégie utilisateur réelle. L’utilisateur alexklibisz a confirmé indépendamment le problème des variables d’environnement : il a utilisé direnv pour gérer les variables au niveau du répertoire, et Codex lancé dans un seul répertoire a emporté ces variables.

La remarque la plus répandue est une satire, venant de l’utilisateur jonplackett : les logiciels prétendus pour mettre fin aux logiciels ne sont en réalité pas très bons.

Trois choses que les utilisateurs ordinaires peuvent faire

Premièrement, si vous utilisez le Codex CLI, désactivez d’abord l’automatisation de l’update : utilisez codex features disable daemon_auto_start, puis exécutez la commande pour arrêter le processus de protection, et vérifiez avec la liste des processus que l’actualisateur est également arrêté. Les personnes qui rapportent des problèmes soulignent que la commande d’arrêt ne fonctionne pas correctement, il faut vérifier manuellement.

Deuxièmement, examinez le disque. Vérifiez combien de place occupe le répertoire packages .codex dans le répertoire des utilisateurs. Les chiffres rapportés dans les commentaires varient de quelques centaines de MB à 12 GB ; les versions anciennes ne sont pas supprimées automatiquement, il faut donc supprimer manuellement les répertoires des versions inutilisées.

Troisièmement, ne vous aventurez pas dans des environnements sensibles sans protection. Pour les machines qui utilisent le code de l’entreprise ou des proxies interne, consultez les solutions de quarantaine proposées dans la section des commentaires : exécution sur un serveur dédié ou une machine virtuelle, ou utilisation de paquets correctement patchés de la communauté Nix, en supprimant le comportement de gestion du processus à l’étape de l’emballage. La règle est la même que lors d’une freinage d’urgence dans le numéro 018 : vous pouvez tendre la main vers les outils, mais le bouton et le sol doivent être entre vos mains.

Conclusion

Précision : cette article ne condamne aucune entreprise. Les accusations de logiciels malveillants ou intentionnelles sont une caractérisation émotionnelle dans la section des commentaires, et cet article ne prend en compte que les faits rapportés ; les faits vérifiés sont ceux décrits par le rapporteur de l’incident, l’état ouvert de l’incident et le silence officiel. La négligence et la malveillance sont deux choses différentes sur la base des preuves, mais une vérification du comportement d’une entreprise ne nécessite pas de détermination de la motivation : une présence permanente sans consentement et des mises à jour automatiques constituent une contradiction entre les paroles et les actes pour toute entreprise dont la sécurité est le fondement de sa marque. Deux points à surveiller : premièrement, si OpenAI répond positivement, y compris des commentaires d’administrateurs officiels, des explications sur le blog ou des changements dans les valeurs par défaut, tout cela constitue une évolution vers la version 2 ; deuxièmement, si le problème similaire publié dans le repository d’Anthropic est vérifié, le jugement de dérive de catégorie passera de « accusations dans la section des commentaires » à « faits entre deux fabricants », et un même ajustement sera effectué à ce moment-là.

Sources de référence

• Informations directes sur l’incident : openai/codex#48195, récupération via l’API GitHub (texte complet du corps, 15 commentaires en entier, étiquettes, state=open, créé le 25-09T20:04Z, tous les auteurs des commentaires étant NONE)
• HN story 50060694 : Données Algolia, soumis le 18:29-10-12T, snapshot du matin 462▲/239💬, le texte est présenté avec la terminologie « plus de 450▲ »
• Banque de commentaires HN : Récupération à deux niveaux de l’API d’items Algolia pour 93 articles, les échantillons représentatifs ont été inclus dans le paquet de faits
• Répertoire npm : @openai/codex version la plus récente 0.162.1 (snapshot du 13-10)
• Identité charliermarsh : Présentation personnelle de l’utilisateur HN (auteur de Ruff/uv, actuellement en poste chez Spring Discovery), non membre d’OpenAI
• Accusations manquantes de documentation : Compte rendu de foma-agent sur HN/incident (12-10), basé sur ce commentaire
• anthropics/claude-code#14980 : Commentaire publié sur HN, le contenu n’a pas été vérifié indépendamment, le texte est simplement traité comme « un problème similaire publié dans la section des commentaires »
• Nombres tels que 374MB/12GB/11 versions de 300MB : Résultats respectivement rapportés par le rapporteur de l’incident et signalés par l’utilisateur HN, ni l’un ni l’autre ne sont des données officielles