OpenAI Codex présente un bug susceptible d'endommager votre SSD en moins d'un an

Si vous utilisez la CLI Codex d'OpenAI et que vous la laissez tourner pendant de longues périodes, votre SSD risque d’être mis à rude épreuve.

Un utilisateur de GitHub nommé 1996fanrui a signalé le problème le 14 juin après avoir remarqué une activité disque anormalement élevée sur sa machine. Après quelques recherches, il a découvert que Codex bombardait en continu une base de données SQLite locale (stockée dans ~/.codex/logs_2.sqlite) d’écritures de journaux de diagnostic. Sur une période de 21 jours de fonctionnement, le disque avait enregistré environ 37 To d’écritures. Sur une base annuelle, cela représente environ 640 téraoctets par an. Un SSD grand public classique de 1 To a une durée de vie nominale d’environ 600 TBW ; ce bug, s’il n’est pas corrigé, pourrait donc épuiser toute l’endurance garantie de votre disque en moins d’un an.

Le coupable est une configuration de journalisation que personne n’avait probablement l’intention de fournir aux utilisateurs finaux. Le collecteur de données SQLite de Codex fonctionne par défaut au niveau TRACE global — le paramètre le plus « bruyant » possible. Il consigne tout, des charges utiles brutes WebSocket aux événements banals du système de fichiers tels que l’ouverture des fichiers « passwd » et « ld.so.cache ». Il ignore également la variable d’environnement standard RUST_LOG, il n’existe donc aucun moyen évident de le désactiver. Environ 71 % des données enregistrées constituent du bruit de niveau TRACE qui n’a aucune utilité diagnostique réelle, du moins pour l’utilisateur lambda.

Ce qui aggrave encore la situation, c’est l’amplification des écritures. Non seulement la base de données ne cesse de grossir, mais elle effectue également des dizaines de milliers d’opérations d’insertion et de suppression par minute. Elle écrit physiquement bien plus sur le disque que ne le laisse supposer la taille des fichiers.

Il s’agit en réalité d’un problème connu sous diverses formes depuis au moins le mois d’avril, avec plusieurs rapports connexes déposés tout au long de l’année. Le journal des modifications récent d’OpenAI a abordé certaines corrections de fiabilité de SQLite, mais n’a pas traité le problème du taux d’écriture. La question reste donc en suspens.

En attendant, Linux et macOS peuvent créer un lien symbolique entre « ~/.codex/logs_2.sqlite » et « /tmp/ » afin de rediriger les écritures vers la mémoire vive. Ce fichier ne contient aucune donnée de conversation ; vous pouvez donc le perdre sans problème lors du redémarrage.