Bug logging Codex dapat memicu penulisan data hingga skala TB ke SSD lokal dan mempercepat habisnya umur SSD

 (github.com/openai)
1 poin oleh GN⁺ 4 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Codex terus-menerus menulis data dalam jumlah besar ke DB log umpan balik SQLite lokal, dan pada satu lingkungan pengguna tercatat sekitar 37TB penulisan ke SSD utama setelah berjalan 21 hari
  • Jika dikonversi, ini setara sekitar 640TB per tahun, atau kira-kira 640 kali penulisan penuh drive per tahun untuk SSD 1TB, sehingga masa tulis bergaransi beberapa SSD konsumen (sekitar 600 TBW) bisa habis dalam waktu kurang dari 1 tahun
  • Baris yang dipertahankan hanya sekitar 500 ribu, tetapi penghitung AUTOINCREMENT sudah melampaui 5,5 miliar ID, sehingga ada selisih sekitar 10.000 kali antara baris yang tersimpan dan ID penyisipan kumulatif
  • Penyebabnya adalah sink log umpan balik SQLite dikonfigurasi dengan default TRACE global(Targets::new().with_default(Level::TRACE)), sehingga log internal dependensi dan bahkan payload protokol mentah berukuran besar ikut direkam secara permanen
  • Pada 22 Juni 2026, dua PR digabungkan dan memblokir sekitar 85% log, sehingga isu ini ditutup

Gejala utama dan cakupan dampak

  • Codex terus menghasilkan penulisan besar-besaran ke file berikut
    • ~/.codex/logs_2.sqlite
    • ~/.codex/logs_2.sqlite-wal
    • ~/.codex/logs_2.sqlite-shm
  • Setelah 21 hari berjalan, sekitar 37TB tercatat ditulis ke SSD utama, dan dari pemeriksaan per proses/per file terkonfirmasi bahwa log SQLite Codex adalah sumber utama penulisan berkelanjutan
  • Jika dihitung tahunan, angkanya sekitar 640TB, setara kurang lebih 640 kali penulisan penuh drive per tahun untuk SSD 1TB
  • Beberapa SSD konsumen memiliki rating sekitar 600 TBW, sehingga umur tulis bergaransi dapat habis dalam kurang dari 1 tahun

Data bukti

  • Evidence1 — amplifikasi tulis (write amplification)

    • Ukuran file logs_2.sqlite saat ini: 1.2 GiB
    • Baris yang saat ini dipertahankan: 506.149
    • Total row id yang pernah dialokasikan: 5.543.677.486
    • Terdapat selisih sekitar 10.000 kali antara baris yang dipertahankan (sekitar 0,5M) dan ID penyisipan kumulatif (5,5 miliar+); bahkan tanpa menghitung WAL, indeks, pruning, checkpoint, penulisan ulang halaman, dan amplifikasi di level perangkat, diperkirakan sudah terjadi churn log historis skala 10TB+

  • Evidence2 — distribusi level/target

    • Dari 681.774 baris yang dipertahankan, estimasi isi log tersimpan sekitar 1.035,6 MiB
    • Porsi per level: TRACE 70,7%, INFO 25,7%, DEBUG 3,0%, WARN 0,6%
    • Pasangan target+level terbesar
      • codex_api::endpoint::responses_websocket (TRACE) 527,4 MiB
      • codex_otel.log_only (INFO) 141,2 MiB
      • codex_otel.trace_safe (INFO) 121,2 MiB
      • log (TRACE) 97,4 MiB
    • Sumber teratas sebagian besar berasal dari log TRACE global, log telemetri yang dicerminkan, dan pencatatan payload websocket/SSE mentah
    • codex_otel.log_only + codex_otel.trace_safe menambah 25,3% lagi; jika kategori ini difilter, sekitar 96% byte log tersimpan pada sampel dapat dihilangkan
    • Sumber TRACE yang paling sering muncul (target=log) mencakup banyak item level rendah seperti inotify event (misalnya ld.so.cache 128.764 kali), panggilan internal tokio-tungstenite, WouldBlock, dan sejenisnya

  • Pengukuran amplifikasi tulis

    • Dalam sampel 15 detik, jumlah baris yang dipertahankan tetap 681.774, tetapi sekitar 36.211 baris disisipkan
    • Pola insert-and-prune yang berulang — penyisipan → pengindeksan → penulisan WAL → pruning — memicu amplifikasi tulis

Perkiraan penyebab

  • Sink log umpan balik SQLite dipasang dengan default TRACE global(Targets::new().with_default(Level::TRACE))
  • Akibatnya, semua target termasuk log dependensi/internal dan payload protokol mentah berukuran besar disimpan permanen pada level TRACE

Arah perbaikan yang diusulkan

  • Pertahankan log umpan balik, tetapi persempit cakupan penyimpanan permanen secara default
    • Jangan gunakan TRACE global untuk sink log umpan balik SQLite
    • Naikkan ambang atau hilangkan noise bernilai rendah seperti target=log, hyper_util, internal tokio-tungstenite, spam inotify, dan log OpenTelemetry SDK level rendah
    • Alih-alih menyimpan seluruh payload websocket/SSE mentah, simpan ringkasan saja (jenis event, durasi, sukses/gagal, penggunaan token, panjang byte payload)
    • Hindari menyimpan event mirror codex_otel.log_only / codex_otel.trace_safe kecuali benar-benar berguna untuk debugging
    • Batas per thread saja tidak cukup, sehingga perlu ditambahkan batas global ukuran DB log/total penulisan
  • Opsi seperti sqlite_logs_enabled = false juga berguna, tetapi solusi inti tetap pemfilteran default yang lebih baik

Laporan reproduksi lintas platform

  • macOS

    • Pada lingkungan macOS 15.7.7 / Codex 26.616.51431, logs_2.sqlite berukuran 113M, MAX(id)=34.277.360, dengan 31.405 baris tersimpan; dari dua sampel 60 detik teramati sekitar 60 kali tulis per detik
    • Ada laporan bahwa proses codex menulis sekitar 50GB selama sesi 1–2 jam

  • Windows

    • Pada Codex Desktop Windows (codex.exe app-server --analytics-default-enabled), baris TRACE terus disisipkan meski tidak ada RUST_LOG=warn maupun pengaturan trace eksplisit
    • Sekitar 71 ribu baris dipertahankan, sementara nilai logs di sqlite_sequence melebihi 18,5 juta, menunjukkan banyak churn insert/prune di masa lalu
    • Dalam distribusi 10 menit, ada 1.812 baris TRACE, dengan target TRACE teratas termasuk codex_api::endpoint::responses_websocket (3,5MB+), dan codex_api::sse::responses
    • Perilaku yang diharapkan: saat RUST_LOG=warn, TRACE dependensi/internal dan payload besar tidak boleh disimpan secara permanen

Risiko tambahan dan mitigasi sementara

  • Risiko kehilangan data

    • Jika disk penuh lalu sistem direboot, Linux bisa gagal login
    • Mode /goal Codex dapat mencoba mengosongkan ruang disk dengan menghapus file/folder, sehingga berpotensi menyebabkan kehilangan data

  • Skrip mitigasi sementara

    • Tersedia trim-codex-wal.sh untuk memangkas WAL saat proses berjalan (PRAGMA wal_checkpoint(TRUNCATE)), dan bisa dijalankan via cron setiap 15 menit
    • fix-codex-wal.sh dapat segera mengosongkan ruang disk dengan menghapus file log/WAL lalu mengirim SIGTERM→SIGKILL ke proses terkait Codex
    • Menambahkan trigger SQLite (block_log_inserts) yang mengabaikan penyisipan ke tabel logs akan menghentikan pertumbuhan WAL; untuk membatalkannya gunakan DROP TRIGGER IF EXISTS block_log_inserts
      • Karena VACUUM menulis ulang DB, file berukuran besar bisa memicu satu kali penulisan besar; karena itu disarankan menjalankan DELETE/VACUUM setelah menambahkan trigger dan memastikan pertumbuhan WAL sudah berhenti
      • Karena ini memodifikasi skema SQLite privat, update/migrasi Codex di masa depan bisa saja membuat tabel ulang atau menghapus trigger tersebut
    • Sebelum perbaikan permanen tersedia, ada juga usulan menaruh DB tersebut di ramdisk untuk mencegah kerusakan SSD

Penyelesaian dan penutupan

  • Pada 22 Juni 2026, dua PR digabungkan dan mengurangi log sekitar 85%, sehingga isu dinyatakan selesai
    • Penghentian seluruh logging event Responses WebSocket (#29432)
    • Pemfilteran target noise dari log permanen (#29457)
  • Dalam patch usulan terpisah, penyimpanan default diubah dari TRACE global menjadi INFO+, sementara codex_otel.log_only, codex_otel.trace_safe, hyper_util, log, opentelemetry_sdk, dan lainnya dinaikkan ke WARN+
  • Perbaikan ini dirilis dalam rust-v0.142.0

Bacaan terkait

1 komentar

 
GN⁺ 4 jam lalu
Komentar Hacker News

  • Menurut saya Codex adalah salah satu contoh paling buruk dari slopware
    Di macOS, bahkan hanya dengan membiarkan jendelanya tetap terlihat saja GPU bisa terpakai 100% cuma untuk menampilkan pesan spinner
    Di MBP M5, hanya karena pesan spinner saja GPU bisa tembus 100%, dan kipas berputar kencang selama sebagian besar waktu menunggu model, jadi perlu hati-hati saat memakai baterai
    Isu ini sudah ada di GitHub hampir 6 bulan, dan kemungkinan besar muncul sejak rongsokan hasil vibe coding ini dirilis
    Bahkan kalau ingin memperbaikinya sendiri pun tidak bisa, karena entah kenapa source-nya tertutup
    Ada banyak perdebatan soal model mana yang lebih baik dan apakah vibe coding itu memungkinkan, tapi menurut saya inilah level yang bisa dicapai vibe coding bahkan di salah satu perusahaan dengan dana, tenaga, dan kapabilitas model paling besar
    Dalam situasi ketika CEO sudah terang-terangan bilang mereka “fokus pada coding”, kesalahan separah ini terlihat seperti sinyal bahwa ada sesuatu yang benar-benar rusak di dalam perusahaan, dan di Polymarket pun hampir tidak ada orang yang menganggap OpenAI akan segera merilis model terdepan
    Ini tragis, karena dunia membutuhkan pesaing bagi Anthropic

    • Claude Code juga ada tepat di sebelahnya, jadi jangan sampai dikeluarkan dari daftar contoh slopware
    • Kalau AI benar-benar memberi produktivitas 10x dan sudah mendekati AGI atau ASI, saya tidak paham bagaimana produk seperti Codex atau Claude Code CLI masih bisa seburuk ini
      Rasanya “revolusi AI agen” seharusnya sudah menyelesaikan masalah seperti ini
      Masa iya di internal mereka masih muncul pesan seperti “sedang diproses, harap tunggu” atau “tugas ini terlalu sulit”
    • Saat bekerja di organisasi yang pada dasarnya membuka source untuk semuanya, termasuk side project, hanya ada satu alasan untuk tetap menutup sesuatu. Rasa malu
      Tidak ada yang mau menjadi wajah publik dari codebase sampah
      Kalau dengan code seperti itu mereka juga berusaha membenarkan harga yang tidak masuk akal, bebannya terasa jadi tiga kali lipat
    • Bukan cuma Codex, aplikasi ChatGPT di macOS juga kalau dibiarkan terbuka beberapa jam akan naik sampai memakan 60GB RAM dan membunuh semua aplikasi lain
      Saya benar-benar tidak paham
      Bahkan saat mencoba memakai Google AI Studio di browser, CPU bisa 100%
      Jadinya terasa seperti semua harus dibuat jadi aplikasi native sendiri
    • Dulu orang bilang dunia butuh Anthropic sebagai pesaing ChatGPT, dan sekarang rasanya sudah berputar penuh

  • Di X ada solusi sementara untuk masalah ini[1]
    sqlite3 ~/.codex/logs_2.sqlite "CREATE TRIGGER IF NOT EXISTS block_log_inserts BEFORE INSERT ON logs BEGIN SELECT RAISE(IGNORE); END;"
    Selain itu, menjalankan VACUUM FULL pada file sqlite tersebut di laptop membuat ukurannya turun dari 27GB menjadi 73MB[2]
    [1]: https://xcancel.com/bdsqlsz/status/2067964486615810369
    [2]: https://xcancel.com/jeethu/status/2068087449469780434

    • Sekali lagi, aturan di level database menyelamatkan keadaan
    • Solusi yang sebenarnya adalah berhenti memakainya dan pindah ke Pi

  • Semua orang sedang mengkritik OpenAI, dan memang pantas, tetapi perlu diingat bahwa tidak seperti Claude Code, Codex secara resmi bisa dikustomisasi: https://github.com/openai/codex
    Cukup mudah juga untuk dipatch

    • Itu adalah CLI, bukan aplikasi Codex proprietari yang dibicarakan di sini

  • Ini mengejutkan
    Sudah seminggu sejak isu ini dibuka, dan dari yang saya lihat OpenAI hanya diam
    Saya kira vendor seperti ini akan sangat sensitif terhadap masalah semacam ini, jadi saya tidak mengerti
    Tentu saja mereka sudah memasang banyak agen untuk memantau isu potensial di GitHub dan mengusulkan perbaikan, kan? …kan?
    Menjalankan tool mereka sendiri untuk memperbaiki isu GitHub secara real time seharusnya jadi hal yang sepele

    • OpenAI tampaknya cukup lemah dalam memperbaiki isu
      Contoh favorit saya secara pribadi adalah #2472; mereka mendemonstrasikan bahwa itu sudah “diperbaiki” di panggung peluncuran GPT-5, tetapi tiketnya masih terbuka dan “perbaikan” itu juga belum di-merge
      Postingan asli yang menyoroti hal ini ada di https://blog.tymscar.com/posts/openaiunmergeddemo/ dan isunya ada di https://github.com/openai/openai-python/issues/2472
    • Ada isu GitHub untuk masalah yang sama sejak April
      Saya cukup sering memakai Codex dan sangat puas dengan performanya (UX dan output), tetapi sulit dipahami bahwa masalah ini masih belum diperbaiki

  • Masalah ini tampaknya sudah diperbaiki[0], dan kemungkinan akan masuk ke rilis berikutnya
    [0] https://github.com/openai/codex/commit/e98d43ac372ddf7f513c0...

  • Vibe coding membawa “bergerak cepat dan merusak” ke level yang sama sekali berbeda

    • Di perusahaan kami sekarang, kami sedang menangani insiden besar karena sampah hasil vibe coding seseorang mengalami masalah serius
    • Sekarang bahkan hal-hal yang bisa dirusak pun makin menipis
    • Jika tidak ada utang teknis, vibe coding umumnya berguna untuk pembuatan prototipe
      Untuk produk nyata, software engineer sungguhan tidak akan pernah benar-benar tergantikan

  • Agak keluar topik, tetapi perusahaan-perusahaan ini harus berhenti mengotori folder root repositori dengan Claude.md atau copilot.md
    Mereka perlu duduk bersama dan menetapkan struktur folder yang sudah dikenal seperti docs/llm/*

  • Saat Claude Code berantakan karena latensi pada akhir tahun lalu, OpenAI nyaris menyia-nyiakan kemenangan yang sudah di tangan
    Belakangan ini Codex mengalami lag mengetik sejak awal, sementara Claude Code walau kadang macet, umumnya kalau saya menekan tombol… ya benar-benar… muncul sesuai yang saya tekan

    • Bagi saya justru kebalikannya
    • Claude Code terasa nyaris tidak bisa dipakai
      Kalau harus mengetik lebih dari beberapa kata, saya selalu harus mengetiknya di neovim

  • Ini sebenarnya kesalahan yang sangat klasik
    Mereka merilis dengan log pelacakan/debug aktif untuk semuanya, hanya saja menariknya dampaknya tidak muncul dengan cara yang biasa
    Dulu, developer menyalakan logging level trace lalu aplikasi jadi sangat lambat dan langsung diperbaiki di update berikutnya, tetapi sekarang memori, CPU, dan kecepatan disk sudah jauh lebih cepat sehingga kita sampai di titik di mana dampak seperti itu tidak langsung terlihat, dan itu gila

    • Pekerjaan agen dilakukan di sisi server, jadi fakta bahwa klien tipis ini bisa menghabiskan resource lokal juga ikut berperan

  • Semoga ada yang mau menyumbangkan token untuk startup pemberani ini. Mereka kelihatannya butuh bantuan