Les utilisateurs des outils OpenAI rencontrent un problème préoccupant aux conséquences potentiellement coûteuses. Il s'avère que l'interface en ligne de commande Codex CLI, très répandue, génère un nombre considérable d'opérations d'écriture sur les SSD. D'après des rapports publiés sur GitHub, ce bug non résolu pourrait entraîner l'écriture de jusqu'à 640 To de données par an. Pour de nombreux SSD grand public, cela signifie dépasser la durée de vie déclarée par le fabricant avant la fin de l'année. L'affaire a été révélée lorsqu'un utilisateur de GitHub, « 1996fanrui », a constaté une activité disque anormalement élevée lors de l'utilisation de Codex CLI. Après investigation, il a découvert que l'application écrivait constamment d'énormes quantités de données dans une base de données SQLite locale située dans le répertoire de l'utilisateur. En seulement 21 jours d'utilisation, l'outil aurait généré environ 37 To d'écritures, soit un total de 640 To sur une année complète. Ce chiffre est très préoccupant. De nombreux SSD de 1 To populaires affichent une endurance (TBW, Total Bytes Written) d'environ 600 To. Cela signifie qu'une utilisation intensive de l'interface de ligne de commande Codex, dans sa version actuelle, pourrait épuiser la durée de vie garantie du disque en moins de douze mois.

Le problème provient du système de journalisation de Codex CLI. L'analyse du code a révélé que l'outil enregistre les données de diagnostic via le module SQLite fonctionnant au niveau TRACE, le plus détaillé disponible. En pratique, il consigne en permanence une grande quantité d'informations techniques, notamment les données brutes transférées par WebSocket et les opérations système courantes liées aux fichiers. Ce mécanisme est particulièrement problématique car il ignore la variable d'environnement standard RUST_LOG, utilisée pour contrôler le niveau de journalisation dans les applications Rust. Par conséquent, les utilisateurs ne disposent d'aucun moyen simple de limiter le nombre d'entrées de journal générées. D'après les analyses, environ 71 % de tous les enregistrements sont des informations de niveau TRACE, qui n'ont aucune valeur diagnostique pratique pour l'utilisateur moyen. Le problème ne se limite pas à la base de données croissante. Les utilisateurs constatent que l'interface de ligne de commande de Codex effectue également un grand nombre d'opérations d'insertion et de suppression. Par conséquent, le nombre réel d'écritures effectuées sur le support physique est bien supérieur à ce que la taille du fichier de base de données SQLite pourrait laisser supposer. Des dizaines de milliers d'opérations par minute entraînent une usure importante des cellules de mémoire NAND des SSD.

D'après les discussions sur GitHub, des problèmes similaires ont déjà été signalés. Les premiers signes d'activité disque excessive remontent au mois d'avril. OpenAI a amélioré la fiabilité de sa base de données SQLite dans ses dernières mises à jour, mais le problème d'écriture excessive persiste. À l'heure où nous écrivons ces lignes, le problème est toujours ouvert sur GitHub. On ignore également quand le fabricant publiera une mise à jour pour corriger cette vulnérabilité. La communauté a déjà proposé une solution de contournement pour les utilisateurs de Linux et macOS. Ils peuvent créer un lien symbolique vers le fichier « ~/.codex/logs_2.sqlite » dans le répertoire « /tmp/ » afin de rediriger les journaux vers la mémoire vive. Ce fichier ne contenant pas de données de conversation, sa perte après un redémarrage n'est pas problématique. En attendant la publication d'un correctif officiel, les utilisateurs intensifs de Codex CLI doivent surveiller l'activité de leur disque et être attentifs à toute activité d'écriture anormalement élevée.