Bug-ul OpenAI Codex care iti distruge SSD-ul: 640 TB de loguri pe an

OpenAI Codex, tool-ul AI de programare, are un bug care scrie cantitati uriase de loguri pe SSD-ul tau — aproximativ 640 TB pe an. Dupa doar 21 de zile de functionare, un utilizator a descoperit ca 37 TB fusesera deja scrisi pe disc. Un SSD de 1 TB are o garantie de ~600 TBW (terabytes written), asa ca bug-ul asta poate distruge fizic hardware-ul in mai putin de 12 luni.

Ce vei gasi in acest articol:

• Ce e exact bug-ul Codex si de ce logheaza totul la nivel TRACE intr-o baza SQLite
• Cat de grav e: date concrete — 37 TB in 21 de zile, 36.000 de insertii in 15 secunde
• Cum verifici daca esti afectat cu comenzi exacte pe care le poti rula acum
• Cum repari problema — actualizare la versiunea noua sau workaround cu trigger SQLite
• Ce inseamna TBW si de ce SSD-ul tau are o durata de viata limitata
• Reactia comunitatii — 598 de reactii si un raspuns intarziat de la OpenAI

Ce este OpenAI Codex si de ce conteaza acest bug

OpenAI Codex este un tool de programare bazat pe AI, accesibil din linia de comanda (CLI). Functioneaza similar cu Claude Code sau GitHub Copilot CLI — ii ceri sa scrie cod, sa repare bug-uri, sa analizeze proiecte, si el executa.

Bug-ul nu e o problema de cod gresit sau de calitate a raspunsurilor. E o problema de infrastructura — Codex logheaza tot ce face intr-o baza de date SQLite locala, la nivelul TRACE (cel mai detaliat nivel posibil), si face asta non-stop, fara oprire.

Fisierul problematic e ~/.codex/logs_2.sqlite, impreuna cu fisierele sale WAL (Write-Ahead Log): logs_2.sqlite-wal si logs_2.sqlite-shm. Aceste fisiere cresc continuu si scriu pe SSD-ul tau in ritm accelerat.

De ce conteaza? Pentru ca SSD-urile au o durata de viata masurata in TBW (terabytes written). Fiecare scriere pe SSD il uzeaza. La un moment dat, SSD-ul cedeaza — devine read-only sau pierde date. Bug-ul Codex consuma aceasta durata de viata de sute de ori mai repede decat ar trebui.

Cat de grav e: 640 TB pe an pe SSD-ul tau

Hai sa vedem numerele exacte, pentru ca sunt socante.

Ce s-a masurat

Un utilizator a monitorizat activitatea de scriere a Codex timp de 21 de zile. Rezultatul: 37 TB scrisi pe SSD. Daca extrapolezi la un an intreg, ajungi la aproximativ 640 TB/an.

Pentru context, un SSD de 1 TB de calitate medie are o garantie de 600 TBW. Asta inseamna ca producatorul garanteaza ca poti scrie 600 TB pe el inainte sa cedeze. Bug-ul Codex consuma toata aceasta garantie in mai putin de un an — doar din loguri.

Ce se logheaza

Nu e vorba de informatii utile. Baza de date SQLite contine:

Sursele principale ale logurilor:

Exemple de lucruri absurde care sunt logate:

• 128.764 de ori evenimentul „inotify event: … mask: OPEN, name: ld.so.cache”
• 37.982 de ori „inotify event: … mask: OPEN, name: locale.alias”
• 23.843 de ori „inotify event: … mask: OPEN, name: passwd”
• Mii de evenimente WebSocket interne (WouldBlock, poll_read, etc.)

Practic, Codex logheaza de sute de mii de ori cand deschizi un fisier de sistem. E ca si cum ai nota de fiecare data cand respiri.

Viteza de scriere

In doar 15 secunde, Codex a inserat 36.211 de randuri in baza de date. In acelasi timp, numarul de randuri pastrate a ramas constant — ceea ce inseamna ca se face un pattern de insert-and-prune: se scriu mii de randuri, apoi se sterg cele vechi, dar scrierea fizica pe SSD ramane.

Mai mult: 5,5 miliarde de ID-uri de randuri au fost alocate, dar doar ~681.000 sunt pastrate. Asta inseamna ca baza de date consuma ID-uri intr-un ritm ametitor, chiar daca nu le tine pe toate.

Cum functioneaza bug-ul — explicat simplu

Ca sa intelegi de ce se intampla asta, trebuie sa stii cateva lucruri despre cum functioneaza logarea in aplicatii.

Ce e SQLite

SQLite e o baza de date mica, incorporata direct in aplicatii. Nu ai nevoie de un server separat — aplicatia scrie direct intr-un fisier pe disc. E folosita peste tot: in browsere, aplicatii mobile, sisteme de operare. Codex foloseste SQLite pentru a tine un istoric al activitatii sale.

Ce inseamna nivelul TRACE

Aplicatiile logheaza informatii la diferite niveluri, de la cel mai putin detaliat la cel mai detaliat:

1. ERROR — doar erorile critice
2. WARN — avertizari
3. INFO — informatii generale
4. DEBUG — detalii pentru dezvoltatori
5. TRACE — tot absolut totul, inclusiv detalii interne

Bug-ul Codex e ca nivelul default a fost setat la TRACE global. Adica logheaza TOT — fiecare eveniment WebSocket, fiecare acces de fisier, fiecare operatiune interna. Nu doar erorile sau avertismentele, ci si „am citit fisierul ld.so.cache” — de 128.764 de ori.

De ce e asa de rau cu SSD-ul

SSD-urile functioneaza diferit fata de hard disk-urile clasice. Cand scrii un fisier pe un SSD, nu scrii doar datele noi — SSD-ul trebuie sa stearga si sa rescrie blocuri intregi de memorie flash. Asta se numeste write amplification: SSD-ul scrie mai mult fizic decat ii trimiti tu.

Cand Codex scrie 36.000 de randuri in 15 secunde, apoi le sterge si altele noi, SSD-ul nu doar scrie acele randuri — trebuie sa gestioneze intern stergerea, realocarea si uzura. La scara a 640 TB/an, asta inseamna uzura accelerata cu un factor de 2-3x din cauza write amplification-ului.

Pattern-ul insert-and-prune

Codex foloseste un pattern toxic: insereaza mii de randuri, apoi sterge cele vechi pentru a tine baza de date la o dimensiune rezonabila. Problema e ca scrierea fizica pe SSD ramane chiar si dupa ce randurile sunt sterse. Nu poti „un-scrie” pe un SSD.

Rezultul: baza de date are ~1,2 GiB si ~681.000 de randuri la un moment dat, dar sub capota se intampla o activitate de scriere de sute de ori mai mare.

Cum verifici daca esti afectat

Daca folosesti OpenAI Codex, trebuie sa verifici imediat. Iata pasii exacti:

Comenzi exacte

Verificare versiune Codex:

codex --version

Verificare dimensiune loguri:

ls -lh ~/.codex/logs_2.sqlite*

Daca vezi fisiere mai mari de cateva zeci de MB, ai o problema. Fisierele de 1+ GiB sunt deja un semn grav.

Verificare spatiu disc:

df -h

Daca partitia cu home directory e plina sau aproape plina, logurile Codex pot fi cauza.

Verificare uzura SSD (Linux):

sudo smartctl -a /dev/sda | grep "Total_LBAs_Written"

Inlocuieste /dev/sda cu discul tau (poti afla cu lsblk). Convertește LBA-uri in TB: inmulteste cu 512 (bytes per LBA) si imparte la 1.099.511.627.776 (bytes per TB).

Verificare uzura SSD (NVMe):

nvme smart-log /dev/nvme0n1

Monitorizare activitate in timp real:

sudo iotop -a

Daca vezi procesul Codex scriind continuu MB sau GB, bug-ul e activ.

Cum repari: actualizare + workaround

OpenAI a recunoscut problema si a lansat fix-uri. Ai doua optiuni.

codex --version

npm install -g @openai/codex@latest

codex --version

rm ~/.codex/logs_2.sqlite*

warn,codex_api=info,codex_app_server=info,codex_core=info,codex_mcp=info,codex_state=info,codex_tui=info

sqlite3 ~/.codex/logs_2.sqlite "CREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;"

rm ~/.codex/logs_2.sqlite*

Ce este TBW si de ce ar trebui sa iti pasa de uzura SSD

TBW inseamna Terabytes Written — cat de mult poti scrie pe un SSD inainte ca acesta sa cedeze. E garantia producatorului ca SSD-ul va functiona corect pana la acel numar de TB scrisi.

Cum functioneaza SSD-urile

Spre deosebire de hard disk-urile clasice (HDD), care scriu date pe discuri magnetice rotative, SSD-urile folosesc memorie flash — chip-uri NAND care stocheaza date ca sarcina electrica. Problema e ca aceste chip-uri se degradeaza cu fiecare scriere. Dupa un anumit numar de cicluri de scriere/stergere, celulele flash nu mai pot retine date corect.

TBW pentru diferite SSD-uri

Ce inseamna asta in practica

Un utilizator normal de calculator scrie pe SSD aproximativ 10-30 TB pe an. Asta include instalari de aplicatii, actualizari de sistem, fisiere temporare, browsing, etc. La un SSD de 1 TB cu 600 TBW, asta inseamna 20-60 de ani de utilizare normala.

Bug-ul Codex scrie 640 TB/an — de 20-60 de ori mai mult decat utilizarea normala. Asta reduce durata de viata a SSD-ului de la decenii la mai putin de un an.

Ce se intampla cand TBW-ul e depasit

Cand un SSD depaseste TBW-ul garantat:

• Poate deveni read-only — poti citi datele, dar nu mai poti scrie
• Poate incepe sa piarda date — celulele flash nu mai retin corect informatia
• Poate esua complet — devine inaccesibil

De obicei, SSD-ul nu moare instant. Incepe cu erori sporadice, apoi devine din ce in ce mai instabil. Dar cand TBW-ul e depasit, nimeni nu-ti garanteaza ca datele sunt in siguranta.

Cum iti verifici TBW-ul consumat

Pe Linux, SMART-ul iti arata exact cat ai scris pe SSD:

# Pentru SATA SSD-uri
sudo smartctl -a /dev/sda | grep "Total_LBAs_Written"

# Pentru NVMe SSD-uri
nvme smart-log /dev/nvme0n1 | grep "data_units_written"

Pe macOS, poti folosi aplicatii precum DriveDx sau smartmontools. Pe Windows, CrystalDiskInfo iti arata uzura SSD-ului.

Cat consuma alte aplicatii comparativ

Diferenta e halucinanta. Codex cu bug scrie de 30-60 de ori mai mult decat intregul sistem de operare cu tot cu toate aplicatiile.

Reactia comunitatii si raspunsul OpenAI

Bug-ul a fost raportat pe 14 iunie 2026 pe GitHub, sub issue-ul #28224. Reactia comunitatii a fost masiva si furioasa.

Cifrele

• 598 de reactii pe GitHub
• 145 de comentarii
• Un comentariu cu 246 de reactii: „WTF this is ridiculous. PLEASE have more respect for your users.”
• Un comentariu cu 76 de reactii care subliniaza riscul de pierdere de date: „Codex in /goal mode will actively delete files and folders on your disk in a vain attempt to gain disk space.”

Ce a facut OpenAI

OpenAI a raspuns prin cod, nu prin comunicare oficiala. Trei PR-uri au fost merge-uite intre 14 si 23 iunie 2026:

1. PR #29432 — redus logarea TRACE pentru modulele principale
2. PR #29457 — scos OpenTelemetry mirror events din logare
3. PR #29599 — setat nivelul default la WARN pentru cele mai multe module

Aceste fix-uri au fost incluse in versiunile 0.142.0 si 0.143.0 si reduc aproximativ 85% din loguri. Problema nu e complet eliminata — inca se mai logheaza la nivel INFO pentru anumite module — dar e substantial redusa.

Ce nu a facut OpenAI

• Nu a anuntat public problema
• Nu a emis un advisory sau o avertizare pentru utilizatori
• Nu a oferit un tool de curatare a logurilor vechi
• Nu a explicat de ce nivelul TRACE a fost setat ca default de la inceput

Aceasta lipsa de transparenta e o problema separata. Utilizatorii care nu verifica GitHub-ul regulat pot continua sa ruleze versiunea veche si sa-si uzeze SSD-ul fara sa stie.

Contextul mai larg

Asta nu e prima problema cu OpenAI Codex. Am mai scris despre cum GPT-5.5 Codex se degradeaza si produce cod mai slab — o alta problema care afecteaza calitatea tool-ului.

Daca vrei alternative de AI pentru programare, poti vedea:

• Cum folosesti Copilot API gratuit — acces gratuit la GPT pe Windows
• Modele AI locale pentru programare — rulezi AI pe calculatorul tau, fara abonament
• Subscriptie AI coding la 10$/luna — acces la mai multe modele la pret mic

Intrebari frecvente