OpenAI Codex rencontre une erreur de journalisation excessive : risque d’endommager les SSD en moins d’un an.
L'outil Codex CLI d'OpenAI écrit silencieusement jusqu'à 640 To de données par an sur des disques durs en raison de mauvaises configurations, dépassant largement la capacité de charge des SSD courants actuels.
Une faille grave vient d'être découverte dans l'interface en ligne de commande (CLI) d'OpenAI Codex, susceptible de réduire la durée de vie des SSD à un rythme alarmant. Au lieu de fonctionner comme un outil de programmation classique, la CLI de Codex est accusée de « torturer » silencieusement le matériel des utilisateurs en écrivant continuellement des données sur le système.
Le mécanisme nuisible résultant d'une configuration de journalisation incorrecte.
Le problème a été initialement signalé par un utilisateur GitHub nommé 1996fanrui, qui a constaté une activité d'écriture disque anormalement élevée sur son ordinateur personnel. Après investigation, il s'est avéré que Codex écrivait en continu des journaux de diagnostic dans une base de données SQLite locale, stockée à l'emplacement suivant :~/.codex/logs_2.sqlite.
D'après l'analyse, après environ 21 jours de fonctionnement, le disque dur avait accumulé près de 37 To de données écrites. Sur une année complète, ce chiffre atteint environ 640 To, une capacité considérable pour un périphérique de stockage grand public.
Pourquoi 640 To/an est-il un chiffre alarmant ?
Pour bien comprendre la gravité du problème, il faut la comparer à la capacité d'écriture (TBW) des SSD courants. Un SSD grand public de 1 To affiche généralement une capacité d'écriture d'environ 600 To. Cela signifie que si l'erreur Codex CLI persiste, votre disque pourrait tomber en panne ou perdre sa garantie en moins de 12 mois.
| Paramètres de comparaison | valeur réelle |
|---|---|
| Perte de données due à une erreur du Codex | ~640 To/an |
| Durée de vie moyenne d'un SSD de 1 To (TBW) | ~600 TB |
| Durée estimée avant la panne du disque dur | Moins d'un an |
Le problème technique sous-jacent réside dans la configuration de la journalisation. L'interface de ligne de commande Codex semble avoir été livrée avec la journalisation TRACE globale activée par défaut. Il s'agit du niveau de journalisation le plus détaillé, enregistrant tout, des données brutes WebSocket aux plus petits événements système comme l'ouverture de fichiers.mot de passebienld.so.cachePlus inquiétant encore, cet outil ignore les variables d'environnement standard.RUST_LOGCela ne laisse aux utilisateurs aucun moyen simple de réduire le niveau de journalisation.
Effet d'amplification d'écriture
Le problème ne se limite pas à l'augmentation de la taille du fichier journal. Du fait du fonctionnement des bases de données SQLite, le système effectue des dizaines de milliers d'opérations d'insertion et de suppression par minute. Ce processus crée un effet d'amplification d'écriture, ce qui fait que la quantité réelle de données écrites sur les puces de mémoire flash du SSD est bien supérieure à la taille du fichier affichée par le système d'exploitation.
Solution de contournement temporaire pour les utilisateurs
Bien qu'OpenAI ait récemment publié des mises à jour concernant la stabilité de SQLite dans ses journaux de modifications, le problème des vitesses d'écriture de données excessivement élevées demeure. En attendant un correctif officiel, les utilisateurs de Linux et macOS peuvent mettre en œuvre la solution temporaire suivante :
- Utilisez des liens symboliques (symlinks) pour rediriger les fichiers.
~/.codex/logs_2.sqlitedans le dossier/tmp/. - Dossier
/tmp/Les données sont généralement stockées dans la RAM (tmpfs), les données écrites n'affecteront donc pas le SSD physique. - Ce fichier ne contenant aucune donnée de conversation critique, la perte de données lors du redémarrage de l'ordinateur ne présente aucun risque.
Il est conseillé aux utilisateurs qui utilisent des outils CLI basés sur l'IA de vérifier régulièrement l'activité de leur disque dur afin d'éviter tout dommage matériel inutile.