AI coding tool lu bisa kelihatan “diam”, tapi di belakang layar tetap bisa nulis log, nyentuh disk, makan CPU, dan bikin laptop kerja terus. Itu pelajaran paling penting dari issue Codex yang sempat ramai: masalahnya bukan cuma token atau prompt, tapi resource lokal yang jarang dipantau.

Artikel ini membahas kenapa bug logging Codex relevan buat developer yang mulai membiarkan AI agent jalan lama di laptop. Intinya sederhana: AI agent tetap software biasa. Kalau logging, cache, retry, dan background process-nya nggak punya batas yang jelas, workflow yang harusnya bantu produktif bisa berubah jadi beban operasional. Buat gua, ini sinyal bahwa resource guardrail perlu jadi kebiasaan baru di era AI coding.

Apa yang terjadi di issue Codex logging?

Di GitHub issue OpenAI Codex, seorang user melaporkan file SQLite lokal seperti ~/.codex/logs_2.sqlite, logs_2.sqlite-wal, dan logs_2.sqlite-shm terus ditulis dalam jumlah besar. Dari observasi di mesin dia, total write SSD mencapai puluhan TB dalam beberapa minggu, lalu diekstrapolasi bisa mendekati ratusan TB per tahun.

Yang bikin cerita ini menarik: issue tersebut bukan cuma komplain abstrak. Ada detail soal database log, jumlah row, write amplification, file WAL SQLite, dan perbandingan dengan rating TBW SSD konsumen. Issue itu juga sudah ditutup setelah dua pull request digabung pada 22 Juni 2026 untuk mengurangi log yang terlalu berisik.

Jadi framing yang sehat bukan “semua pengguna Codex pasti merusak SSD”. Itu terlalu fearmongering. Framing yang lebih berguna: bug ini mengingatkan bahwa AI coding tool lokal juga butuh observability dan batas resource, sama seperti service backend kecil yang lu deploy ke server.

Kenapa logging bisa jadi masalah?

Logging itu fitur penting. Tanpa log, developer susah debug. Tapi logging tanpa budget bisa berubah jadi bug operasional.

Dari pull request perbaikan Codex, problem utamanya terlihat di area log event yang terlalu ramai. Salah satu PR menyebut setiap successful Responses WebSocket event sempat menghasilkan beberapa record lokal: payload TRACE, OpenTelemetry log event, dan OpenTelemetry trace event. Di thread yang sibuk, record seperti ini bisa memenuhi partisi log kecil dalam hitungan detik dan memicu pola insert-and-prune SQLite terus-menerus.

PR lain memfilter target log yang noisy dari persistent logs. Artinya, bukan semua observability harus disimpan ke disk lokal terus-menerus. Beberapa data cukup jadi counter, metrics, atau error log. Detail payload sukses yang berulang ribuan kali sering kali nggak sebanding dengan biaya write-nya.

Definisi singkat: resource guardrail itu apa?

Resource guardrail adalah batas operasional untuk mencegah tool atau agent memakai resource secara berlebihan. Kalau prompt guardrail mengatur “AI boleh dan nggak boleh ngapain”, resource guardrail mengatur “AI boleh memakai berapa banyak disk, CPU, waktu, network, token, dan file write”.

Contohnya:

  • batas ukuran log dan retensi log;
  • timeout untuk task yang terlalu lama;
  • limit jumlah file yang boleh disentuh agent;
  • budget token atau biaya per task;
  • permission network yang eksplisit;
  • monitoring disk write, cache, dan folder kerja AI tool.

Ini terdengar seperti urusan DevOps, tapi sekarang mulai masuk ke laptop developer. Karena AI agent lokal bukan cuma editor plugin. Dia bisa jalan lama, loop, membuat file, membaca repo, memanggil tool, dan menyimpan histori kerja.

SQLite WAL bukan musuhnya, pola write-nya yang perlu dijaga

SQLite punya mode Write-Ahead Logging atau WAL. Secara sederhana, WAL membantu database menulis perubahan ke file log sebelum checkpoint ke database utama. Ini desain normal dan banyak dipakai. Dokumentasi SQLite juga menjelaskan konsep checkpoint dan cara menghindari WAL file yang tumbuh berlebihan.

Masalahnya muncul ketika aplikasi menulis event terlalu sering, lalu database melakukan insert, prune, checkpoint, atau rewrite secara terus-menerus. Di level aplikasi, developer mungkin cuma melihat “log disimpan”. Di level disk, efeknya bisa jadi jauh lebih besar karena ada WAL, indeks, page rewrite, filesystem, dan device-level write amplification.

Pelajaran praktisnya: jangan langsung menyalahkan SQLite. Database kecil seperti SQLite justru sering pilihan yang bagus untuk log lokal. Yang perlu dicek adalah volume event, level log default, retention policy, dan apakah log sukses yang repetitif benar-benar perlu persist ke disk.

Checklist buat developer yang pakai AI coding tool lokal

Kalau lu pakai Codex, Claude Code, Cursor, tool agent lokal, atau automation lain yang jalan lama, ini checklist ringan yang bisa lu pakai hari ini:

  1. Cek folder log dan cache. Cari folder seperti ~/.codex, ~/.cache, folder app support, atau workspace internal tool. Lihat ukuran file yang tumbuh cepat.
  2. Pantau proses yang banyak nulis disk. Di macOS, Activity Monitor bisa bantu lihat disk writes per process. Di Linux, tools seperti iotop atau iostat bisa membantu kalau tersedia.
  3. Update tool secara rutin. Issue Codex ini sudah punya PR fix. Banyak bug operasional seperti ini selesai lewat update kecil, bukan lewat setting prompt.
  4. Matikan agent saat nggak dipakai. Jangan biarkan agent, watcher, atau dev server jalan semalaman kalau lu nggak butuh.
  5. Batasi scope kerja agent. Jalankan agent di repo/folder spesifik. Jangan kasih akses ke seluruh home directory kalau task-nya cuma satu project.
  6. Review setting telemetry dan logging. Kalau tool menyediakan pilihan log level, pilih default yang wajar. TRACE biasanya bukan buat persist harian semua user.
  7. Perlakukan AI tool seperti service kecil. Kalau dia bisa jalan lama dan punya side effect, dia perlu restart policy, log rotation, timeout, dan update routine.

Pelajaran buat builder: default logging harus punya budget

Kalau lu bikin aplikasi desktop, CLI, agent, atau extension developer tool, bug ini punya pesan yang jelas: logging sukses yang terlalu detail bisa lebih mahal daripada yang lu kira.

Default yang lebih aman biasanya seperti ini:

  • error dan warning disimpan lebih lama;
  • event sukses yang sangat ramai cukup jadi counter atau metrics;
  • payload besar jangan otomatis dipersist;
  • TRACE hanya aktif saat debug eksplisit;
  • log lokal punya size cap dan retention cap;
  • pruning jangan bikin churn write yang lebih mahal daripada data yang dibuang;
  • user punya cara mudah melihat dan menghapus cache/log.

Gua suka melihat ini sebagai versi lokal dari prinsip production engineering. Di server, developer sudah biasa bicara soal log budget, retention, sampling, dan cardinality. Di laptop, banyak tool masih diperlakukan seperti mainan kecil. Era AI agent bikin asumsi itu mulai usang.

Ini bukan alasan buat anti-AI tool

Gua tetap pakai AI tool karena value-nya nyata. Tapi value nyata nggak berarti bebas dari operational cost. Justru kalau sebuah tool mulai jadi bagian kerja harian, standar ekspektasi kita harus naik.

AI coding tool yang bagus bukan cuma pintar menjawab. Dia juga harus hemat resource, jelas observability-nya, aman default-nya, dan gampang dimatikan kalau ada yang aneh. Buat user, tugas kita bukan panik. Tugas kita adalah punya kebiasaan audit kecil: cek versi, cek log, cek cache, cek disk write, lalu update.

Takeaway praktis

  • AI coding tool bukan cuma makan token; dia juga bisa makan resource lokal.
  • Logging itu penting, tapi logging tanpa batas bisa jadi bug operasional.
  • Codex issue ini sudah ditutup setelah PR perbaikan, jadi ambil pelajarannya tanpa fearmongering.
  • Developer perlu resource guardrail: disk, CPU, timeout, network, token, dan scope file.
  • Builder tool AI perlu mendesain log budget sejak awal, bukan setelah user menemukan disk write yang aneh.

FAQ singkat

Apakah Codex pasti merusak SSD?

Nggak bisa disimpulkan begitu. Issue ini adalah laporan spesifik dengan kondisi tertentu, dan perbaikannya sudah digabung. Yang penting: cek update dan pantau resource lokal kalau lu sering menjalankan AI coding tool.

Apakah SQLite WAL berbahaya?

Nggak. WAL adalah mekanisme normal SQLite. Yang berbahaya adalah pola write yang terlalu ramai tanpa log budget, retention yang sehat, atau filtering event yang jelas.

Apa bedanya prompt guardrail dan resource guardrail?

Prompt guardrail mengatur perilaku model lewat instruksi. Resource guardrail mengatur batas operasional: disk, CPU, waktu jalan, token, network, dan file system scope. Untuk AI agent kerja nyata, dua-duanya perlu.

Referensi / Bacaan Lanjut

Tags:
#AI Coding#Developer Tools#Reliability#Software Engineering#Developer Productivity