Les CLI IA ne devraient pas installer de daemons par défaut

Un développeur lance npm install -g @openai/codex pour essayer un assistant de codage IA, et se retrouve avec un daemon persistant, auto-mis à jour, qu'il n'a jamais demandé. C'est la situation qui a fait scandale récemment, quand des utilisateurs de Codex CLI d'OpenAI ont découvert que l'outil démarre automatiquement un processus en arrière-plan, écrit des fichiers pid et lock dans ~/.codex, conserve d'anciennes versions du binaire sur le disque (un utilisateur en a signalé environ 12 Go) et se met à jour sans rien demander. Ce n'est pas l'histoire du bug d'une seule entreprise. C'est l'histoire d'un modèle de confiance sur lequel l'outillage développeur s'appuie depuis des décennies, et de la façon discrète dont on est en train de l'abandonner.

J'ai passé des années dans l'infrastructure et la réponse aux incidents, et le schéma ici m'est familier : dans les adwares, dans les agents de build compromis, dans les services de mise à jour « utiles » livrés par les fabricants de matériel. Examinons donc les défenses habituelles de cette conception et testons-les une à une, car la plupart ne résistent pas à la réalité des environnements de production.

Mythe n°1 : « C'est juste un outil de mise à jour, les navigateurs font pareil »

C'est l'argument le plus courant, et il semble raisonnable. Chrome et Firefox se mettent à jour en permanence. VS Code et Slack aussi. Pourquoi un harnais CLI ferait-il exception ?

Parce que le contexte de confiance est totalement différent. Un navigateur est une application graphique avec une expérience de premier lancement, une page de paramètres visible, un installeur signé et, point crucial, un canal de mise à jour durci et audité depuis plus de dix ans. Le programme de mise à jour de Chrome est l'un des logiciels les plus attaqués au monde, et Google dédie des équipes à le sécuriser. Quand vous installez Chrome, la mise à jour fait partie du contrat que vous avez accepté explicitement.

Un CLI installé via npm porte un contrat implicite différent. Les développeurs s'attendent à ce qu'il s'exécute quand on l'appelle et s'arrête une fois sa tâche terminée. Cette attente n'a rien de nostalgique : elle est structurante. Les pipelines CI, les conteneurs, les serveurs de build partagés et les revues de sécurité supposent tous que npm i -g some-tool fournit un binaire qui s'exécute à la demande. Un daemon en arrière-plan qui survit à la déconnexion, se relance tout seul et remplace son propre binaire viole toutes ces hypothèses. J'ai personnellement participé à des incidents où « pourquoi existe-t-il un processus qu'on ne peut pas identifier ? » a transformé une alerte banale en une enquête forensique de trois heures. Une persistance non identifiée est indiscernable d'une compromission tant qu'on n'a pas prouvé le contraire.

Il y a aussi une différence pratique sur le rayon d'impact. Votre navigateur affiche les pages web dans un bac à sable. Un harnais de codage IA exécute des commandes shell, lit votre arborescence de sources et détient souvent des clés d'API et des identifiants cloud dans son environnement. Lui donner un composant auto-modifiable et toujours actif représente un risque sans commune mesure avec une mise à jour de navigateur.

Mythe n°2 : « Les utilisateurs n'ont qu'à désactiver ça avec un indicateur de configuration »

C'est techniquement vrai, et pratiquement dénué de sens. Oui, il existe un indicateur de fonctionnalité :

# ~/.codex/config.toml
[features]
daemon_auto_start = false

Le problème, c'est qu'il n'était pas documenté au moment où les utilisateurs l'ont cherché. Une option de désactivation que personne ne connaît n'est pas un consentement, c'est un piège. Et regardez le plan B de la communauté : supprimer les fichiers pid et lock, les lier symboliquement vers /dev/null et les marquer immuables avec chattr +i, pour que le daemon plante au démarrage si l'indicateur vient à disparaître. Quand des utilisateurs piègent leur propre répertoire personnel pour se défendre de votre logiciel, vous n'avez pas conçu un système de configuration. Vous avez créé une relation antagoniste.

J'ai déjà écrit sur cette dynamique à propos des applis de fitness qui fuitent des données de localisation : le schéma est toujours le même. La fonctionnalité est activée par défaut, l'interrupteur est enfoui ou non documenté, et la charge de la vigilance retombe sur l'utilisateur. Les valeurs par défaut sont une politique. Une valeur par défaut qui installe une persistance dit beaucoup de qui le logiciel sert réellement.

La solution est simple, et l'a toujours été : demander une fois, au premier lancement. Codex runs a background service to keep itself updated. Enable it? [y/N] Des outils comme apt, Homebrew et la plupart des daemons Linux fonctionnent sur une activation explicite depuis des décennies. systemctl enable existe précisément parce que lancer quelque chose au démarrage est censé être un acte délibéré.

Mythe n°3 : « Aller vite exige des mises à jour silencieuses »

Cet argument a une part de vérité, et je veux le défendre sérieusement. Les harnais IA évoluent réellement très vite. Un CLI vieux de trois semaines peut mal se comporter face à une API modifiée, et un client bogué en production représente une vraie charge pour le support. Une équipe qui développe un IDE pour la legaltech a raconté avoir envisagé un daemon, puis choisi une vérification stricte à chaque lancement : si l'application est obsolète, elle vous le signale et se met à jour au démarrage, et si ça ne vous plaît pas, vous arrêtez de l'utiliser. C'est un choix de conception légitime.

Mais « nous avons besoin de mises à jour » n'implique pas « nous avons besoin d'un daemon persistant qui se met à jour pendant que vous ne regardez pas ». Il existe un large entre-deux :

• Vérifier à l'appel. Comparer les versions au démarrage du CLI, afficher un avertissement et mettre à jour au lancement suivant. Homebrew, gh et bien d'autres font ainsi.
• Mettre à jour via le gestionnaire de paquets. Vous avez installé via npm : mettez à jour via npm. L'utilisateur dispose déjà d'un mécanisme qu'il comprend et qu'il peut figer, auditer et verrouiller.
• Daemon en option, désactivé par défaut. Pour les utilisateurs qui veulent une fraîcheur sans friction, proposez le daemon comme choix documenté.
• Élaguer les anciennes versions. Conserver chaque binaire précédent jusqu'à grignoter 12 Go du disque de quelqu'un n'est pas une stratégie de mise à jour, c'est une fuite.

La vraie raison pour laquelle les équipes adoptent des mises à jour silencieuses n'est pas la vitesse, c'est le contrôle. Une mise à jour par le gestionnaire de paquets respecte le lockfile, les miroirs et le circuit d'approbation de l'utilisateur. Un auto-updater contourne tout cela. Quand un éditeur insiste sur la voie de l'auto-mise à jour, il vous dit qu'il préfère son pipeline de déploiement à votre gestion des changements. Dans une entreprise qui a déjà des angles morts dans ses journaux, c'est ainsi qu'on finit par exécuter du code non relu sous les identifiants des développeurs.

Mythe n°4 : « C'est open source, vous pouvez lire le code »

L'open source aide, mais ne résout pas le vrai problème, qui est le décalage entre ce que vous avez relu et ce qui tourne réellement. Tout l'intérêt d'un daemon auto-mis à jour, c'est que le binaire présent sur votre machine aujourd'hui n'est pas celui que vous avez installé. Lire le code de la version 0.157.0 ne vous dit rien du build récupéré mardi prochain. Tant que vous ne vérifiez pas les signatures et les builds reproductibles à chaque mise à jour silencieuse, et personne ne le fait, « c'est open source » reste une couverture de confort.

Il y a un second problème, plus subtil : l'enchevêtrement entre état et configuration. Des utilisateurs qui tentaient de gérer Codex de façon déclarative (l'un d'eux a raconté l'échec sous nix-darwin) ont constaté que l'outil mélange configuration et état d'exécution mutable dans le même répertoire. Impossible donc de figer, comparer ou auditer ce qui a changé. Les bons outils Unix le savent depuis toujours : configuration dans ~/.config, état dans ~/.local/state, cache dans ~/.cache, et jamais d'outil qui modifie sa propre configuration. Si vous voulez comprendre pourquoi le chemin audité compte, l'écart entre spécification et implémentation est précisément le lieu où ces surprises se cachent.

Si vous voulez vérifier ce qui tourne réellement sur votre machine en ce moment, cela prend trente secondes :

# What AI-tool daemons are alive right now?
ps auxww | grep -Ei 'codex|claude' | grep -v grep
# What's been accumulating on disk?
du -sh ~/.codex ~/.local/share/claude 2>/dev/null
# What launchd/systemd units did tools register?
ls ~/Library/LaunchAgents 2>/dev/null   # macOS
systemctl --user list-units --type=service | grep -Ei 'codex|claude'  # Linux

Lancez-la sur quelques portables de développeurs de votre organisation. Je vous garantis qu'au moins une personne sera surprise par le résultat.

Mythe n°5 : « Tout le monde le fait, donc ça doit être correct »

Claude Code conserve lui aussi les versions précédentes des binaires et exécute des tâches en arrière-plan : des utilisateurs de la même discussion l'ont confirmé. Oui, c'est un schéma propre à l'industrie, pas le faux pas d'un seul éditeur. Mais « tout le monde le fait » n'a jamais été un argument de sécurité : c'est ainsi que les mauvaises normes se figent. Les incidents liés à la chaîne d'approvisionnement de ces dernières années auraient dû nous apprendre que les machines des développeurs sont la cible la plus vulnérable et la plus précieuse de la plupart des organisations : elles détiennent des identifiants cloud, des clés de signature et des accès en écriture, et exécutent une quantité stupéfiante de code non audité avec ces privilèges.

Chaque composant persistant, connecté au réseau et auto-modifiable que vous ajoutez à cette machine est une surface d'attaque qui mène tout droit à vos identifiants les plus sensibles. Un canal de mise à jour compromis pour un outil de développement populaire est un scénario cauchemar, précisément parce que le mécanisme de mise à jour est implicitement approuvé. Plus les éditeurs normalisent les daemons silencieux, plus chacun devient une cible précieuse.

Et le niveau de qualité compte. Des utilisateurs ont signalé que le daemon de Codex corrompait les permissions pendant la mise à jour automatique, laissant les répertoires .git en lecture seule et bloquant des dépôts de travail. Un daemon bogué ne se contente pas de rester là : il casse activement des choses avec des privilèges que vous n'avez jamais consciemment accordés. « Tout le monde le fait » plus « c'est bogué », ce n'est pas rassurant. C'est un pronostic.

À quoi ressemble un mécanisme de mise à jour respectueux du consentement

C'est un problème déjà résolu. Nous n'avons pas besoin de nouvelle technologie, seulement que les éditeurs choisissent la réponse la plus classique. Si je rédigeais le cahier des charges de n'importe quel CLI IA livré aujourd'hui, il ressemblerait à ceci :

1. Pas de persistance par défaut. L'outil s'exécute à l'appel et s'arrête une fois terminé. Tout composant en arrière-plan est optionnel et demandé explicitement au premier lancement.
2. Interrupteurs d'arrêt documentés et stables. Un indicateur de configuration et une variable d'environnement (par ex. CODEX_NO_DAEMON=1) documentés, testés, et qui ne disparaissent pas en silence.
3. Mises à jour par le canal d'installation. Les outils installés via npm se mettent à jour via npm. Signaler à l'appel ; ne jamais modifier votre propre binaire à l'insu de l'utilisateur.
4. Versions signées et publiées avec des changelogs. Si vous livrez un programme de mise à jour, signez les artefacts et laissez les utilisateurs figer les versions et auditer les changements.
5. Espace disque borné et séparation nette de l'état. Ne conserver qu'une version précédente au maximum, séparer configuration et état, et respecter les conventions XDG.
6. Respecter le modèle des distributions. Comme le notait un commentateur, les paquets de distribution existent pour que les mainteneurs testent les logiciels et retirent les fioritures avant qu'ils n'atteignent les utilisateurs. Ne vous battez pas contre ça : publiez-y.

Rien de tout cela ne ralentit sérieusement une équipe qui avance vite. Cela place simplement le consentement au début de l'interaction, là où il doit être.

La conclusion

La vérité inconfortable, c'est que les outils de codage IA demandent plus de confiance que n'importe quel outil de développement de l'histoire (accès shell, vos identifiants, toute votre arborescence de sources), tout en adoptant les pratiques de mise à jour d'un adware de 2008. Ces deux faits ne peuvent pas coexister en toute sécurité. Un CLI qui installe par défaut un daemon persistant et auto-mis à jour a pris une décision à votre place, et cette décision est que le confort de l'éditeur passe avant votre contrôle sur votre propre machine.

Réagissez. Désactivez les indicateurs, auditez vos machines, ouvrez des tickets et privilégiez les outils dont les valeurs par défaut vous respectent. Le même réflexe qui pousse les gens vers la liberté du sideloading plutôt que vers les plateformes verrouillées s'applique ici. Les outils que nous laissons tourner sans surveillance sur les portables des développeurs aujourd'hui deviendront les rapports d'incidents de la chaîne d'approvisionnement de demain. Le consentement n'est pas un bonus dans la conception des mises à jour : c'est tout le mécanisme.