CLI AI Jangan Pasang Daemon Latar Belakang secara Default

Seorang developer menjalankan npm install -g @openai/codex untuk mencoba asisten coding AI, dan malah mendapati daemon latar belakang yang terus berjalan dan memperbarui dirinya sendiri, padahal tidak pernah diminta. Hal inilah yang belakangan ramai dibahas saat pengguna OpenAI Codex CLI menemukan bahwa tool tersebut otomatis menjalankan proses latar belakang, menulis file pid dan lock ke ~/.codex, menyimpan versi binary lama di disk (salah satu pengguna melaporkan sekitar 12 GB), dan memperbarui dirinya sendiri tanpa bertanya. Ini bukan sekadar bug satu perusahaan. Ini tentang model kepercayaan yang sudah dipegang tooling developer selama puluhan tahun, dan bagaimana model itu diam-diam ditinggalkan.

Saya sudah bertahun-tahun menggeluti infrastruktur dan respons insiden, dan pola ini sudah pernah saya lihat sebelumnya — di adware, di build agent yang dikompromikan, dan di layanan updater ‘membantu’ yang dikirim vendor hardware. Jadi mari kita uji satu per satu pembelaan umum terhadap desain ini, karena sebagian besar tidak bertahan saat berhadapan dengan cara kerja environment production yang sebenarnya.

Mitos 1: “Ini cuma updater — browser juga begitu”

Ini pembelaan paling umum, dan terdengar masuk akal. Chrome dan Firefox terus memperbarui diri. Begitu juga VS Code dan Slack. Kenapa CLI harness tidak boleh?

Karena konteks kepercayaannya sangat berbeda. Browser adalah aplikasi GUI dengan pengalaman first-run, halaman pengaturan yang terlihat, installer yang ditandatangani, dan — yang paling penting — kanal update yang sudah diperkeras dan diaudit selama lebih dari satu dekade. Updater Chrome termasuk salah satu software paling sering diserang di dunia, dan Google punya tim khusus untuk menjaganya tetap aman. Saat kamu memasang Chrome, update adalah bagian dari kesepakatan yang kamu setujui secara jelas.

CLI yang dipasang lewat npm membawa kontrak tersirat yang berbeda. Developer mengharapkan tool itu berjalan saat dipanggil dan berhenti saat selesai. Harapan ini bukan sekadar nostalgia — ia menopang banyak hal. Pipeline CI, container, build server bersama, dan security review semuanya berasumsi bahwa npm i -g some-tool memberimu binary yang dieksekusi sesuai permintaan. Daemon latar belakang yang tetap hidup setelah logout, menghidupkan ulang dirinya sendiri, dan menukar binary-nya sendiri melanggar semua asumsi itu. Saya pernah ikut incident call di mana pertanyaan ‘kenapa ada proses yang tidak bisa kami lacak?’ mengubah alert rutin menjadi latihan forensik tiga jam. Persistensi yang tidak bisa dipertanggungjawabkan tidak bisa dibedakan dari kompromi sampai kamu membuktikan sebaliknya.

Ada juga perbedaan praktis dalam blast radius. Browser kamu merender halaman web di dalam sandbox. Harness coding AI menjalankan perintah shell, membaca source tree kamu, dan sering menyimpan API key serta kredensial cloud di environment-nya. Memberi komponen yang bisa memodifikasi dirinya sendiri dan selalu aktif itu risiko yang jauh lebih besar dibanding update browser.

Mitos 2: “Pengguna tinggal mematikannya lewat config flag”

Secara teknis benar, tapi secara praktis tidak berarti apa-apa. Ya, ada feature flag-nya:

# ~/.codex/config.toml
[features]
daemon_auto_start = false

Masalahnya, flag itu tidak terdokumentasi saat pengguna mencarinya. Opt-out yang tidak diketahui siapa pun bukanlah persetujuan — itu jebakan. Dan perhatikan rencana cadangan yang dibuat komunitas: hapus file pid dan lock, symlink ke /dev/null, lalu tandai sebagai immutable dengan chattr +i supaya daemon crash saat startup jika flag itu suatu saat hilang. Saat pengguna harus memasang jebakan di home directory mereka sendiri untuk melindungi diri dari software kamu, itu bukan sistem konfigurasi. Itu hubungan yang sudah berubah menjadi adversarial.

Saya pernah menulis tentang dinamika ini dalam konteks aplikasi fitness yang membocorkan data lokasi: polanya selalu sama. Fitur dikirim dalam kondisi aktif secara default, toggle-nya disembunyikan atau tidak didokumentasikan, dan beban kewaspadaan jatuh ke pengguna. Default adalah kebijakan. Default yang memasang persistensi adalah pernyataan tentang siapa sebenarnya software itu melayani.

Solusinya sangat mudah dan memang selalu begitu: tanya sekali, saat first run. Codex runs a background service to keep itself updated. Enable it? [y/N]. Tool seperti apt, Homebrew, dan sebagian besar daemon Linux sudah beroperasi dengan aktivasi eksplisit selama puluhan tahun. systemctl enable ada justru karena menjalankan sesuatu saat boot seharusnya menjadi tindakan yang disengaja.

Mitos 3: “Bergerak cepat butuh self-update diam-diam”

Argumen ini ada benarnya, dan saya ingin membelanya dengan versi terkuatnya. Harness AI memang bergerak cepat. CLI yang sudah tiga minggu tidak diperbarui bisa salah perilaku terhadap API yang berubah, dan client yang bermasalah di lapangan adalah beban support yang nyata. Sebuah tim yang membangun IDE legal-tech pernah bercerita bahwa mereka sempat mempertimbangkan daemon, lalu memilih mengecek update secara ketat di setiap kali aplikasi dijalankan: jika aplikasi sudah usang, ia memberi tahu dan memperbarui saat startup, dan jika kamu tidak suka, kamu berhenti menjalankannya. Itu desain yang sah.

Tapi ‘kami butuh update’ tidak berarti ‘kami butuh daemon persisten yang memperbarui dirinya saat kamu tidak melihat’. Ada banyak jalan tengah:

• Cek saat dipanggil. Bandingkan versi saat CLI dijalankan, tampilkan pemberitahuan, dan perbarui pada run berikutnya. Homebrew, gh, dan banyak lainnya melakukan ini.
• Perbarui lewat package manager. Kamu memasangnya via npm — perbarui via npm. Pengguna sudah punya mekanisme yang mereka pahami dan bisa di-pin, diaudit, serta dikunci.
• Daemon opt-in, nonaktif secara default. Untuk pengguna yang ingin kesegaran tanpa hambatan, tawarkan daemon sebagai pilihan yang terdokumentasi.
• Pangkas versi lama. Menyimpan setiap binary sebelumnya sampai memakan 12 GB disk seseorang bukanlah strategi update; itu kebocoran.

Alasan sebenarnya tim meraih self-updater diam-diam bukanlah kecepatan — melainkan kontrol. Update package manager menghormati lockfile, mirror, dan alur persetujuan pengguna. Self-updater memotong semua itu. Ketika vendor bersikeras memakai jalur self-update, mereka sebenarnya bilang bahwa mereka lebih menghargai pipeline deployment mereka daripada change management kamu. Di perusahaan yang sudah punya titik buta logging, inilah yang membuat kode tanpa review berjalan di bawah kredensial developer.

Mitos 4: “Ini open source — kamu bisa baca kodenya”

Open source memang membantu, tapi tidak menyelesaikan masalah utamanya, yaitu perbedaan antara apa yang sudah kamu review dan apa yang sedang berjalan. Inti dari daemon yang memperbarui dirinya sendiri adalah bahwa binary di mesin kamu hari ini bukan binary yang kamu pasang dulu. Membaca source versi 0.157.0 tidak memberi tahu apa pun tentang build yang akan diunduh Selasa depan. Kecuali kamu memverifikasi signature dan reproducible build di setiap update diam-diam — dan tidak ada yang melakukannya — ‘ini open source’ hanyalah selimut penenang.

Ada masalah kedua yang lebih halus: keterikatan antara state dan konfigurasi. Pengguna yang mencoba mengelola Codex secara deklaratif (ada yang melaporkan gagal melakukannya di nix-darwin) menemukan bahwa tool ini mencampur konfigurasi dengan state runtime yang bisa berubah di direktori yang sama. Akibatnya, mustahil untuk melakukan pin, diff, atau audit terhadap apa yang berubah. Tool Unix yang baik sudah lama memahami hal ini: konfigurasi di ~/.config, state di ~/.local/state, cache di ~/.cache, dan tool tidak pernah boleh memodifikasi konfigurasinya sendiri. Jika kamu ingin memahami mengapa jalur yang bisa diaudit itu penting, celah antara spesifikasi dan implementasi adalah tempat kejutan semacam ini bersembunyi.

Jika kamu ingin mengecek apa yang sebenarnya berjalan di mesinmu saat ini, hanya butuh tiga puluh detik:

# What AI-tool daemons are alive right now?
ps auxww | grep -Ei 'codex|claude' | grep -v grep
# What's been accumulating on disk?
du -sh ~/.codex ~/.local/share/claude 2>/dev/null
# What launchd/systemd units did tools register?
ls ~/Library/LaunchAgents 2>/dev/null   # macOS
systemctl --user list-units --type=service | grep -Ei 'codex|claude'  # Linux

Jalankan itu di beberapa laptop developer di organisasimu. Saya jamin setidaknya satu orang akan terkejut dengan hasilnya.

Mitos 5: “Semua orang melakukannya, jadi pasti aman”

Claude Code juga menyimpan versi binary sebelumnya dan menjalankan background task — pengguna di diskusi yang sama mengonfirmasinya. Jadi memang ini pola industri, bukan kelalaian satu vendor. Tapi ‘semua orang melakukannya’ tidak pernah menjadi argumen keamanan; justru begitulah norma buruk mengeras. Insiden supply chain beberapa tahun terakhir seharusnya mengajarkan kita bahwa mesin developer adalah target bernilai tinggi yang paling lunak di kebanyakan organisasi: mereka menyimpan kredensial cloud, signing key, dan akses push, dan menjalankan kode tak teraudit dalam jumlah luar biasa dengan hak-hak tersebut.

Setiap komponen persisten, terhubung jaringan, dan memodifikasi dirinya sendiri yang kamu tambahkan ke mesin itu adalah attack surface yang mengarah langsung ke kredensial paling sensitifmu. Kanal update yang dikompromikan untuk tool dev populer adalah skenario mimpi buruk justru karena mekanisme update dipercaya secara implisit. Semakin banyak vendor menormalisasi daemon diam-diam, semakin bernilai setiap daemon sebagai target.

Dan standar kualitasnya penting. Pengguna melaporkan daemon Codex merusak permission saat auto-update — meninggalkan direktori .git dalam kondisi read-only dan mengunci repo kerja. Daemon yang buggy tidak hanya diam di tempat; ia aktif merusak sesuatu dengan hak akses yang tidak pernah kamu berikan secara sadar. ‘Semua orang melakukannya’ ditambah ‘ini buggy’ bukanlah jaminan. Itu ramalan.

Seperti apa mekanisme update yang menghormati persetujuan

Ini masalah yang sudah terpecahkan. Kita tidak butuh teknologi baru; kita hanya butuh vendor memilih jawaban yang membosankan. Jika saya yang menulis dokumen requirement untuk CLI AI apa pun yang dirilis hari ini, isinya akan seperti ini:

1. Tanpa persistensi secara default. Tool berjalan saat dipanggil dan keluar saat selesai. Komponen latar belakang apa pun bersifat opt-in, diminta secara eksplisit saat first run.
2. Kill switch yang terdokumentasi dan stabil. Config flag dan environment variable (misalnya CODEX_NO_DAEMON=1) yang terdokumentasi, teruji, dan tidak akan hilang diam-diam.
3. Update lewat kanal instalasi. Tool yang dipasang via npm diperbarui via npm. Beri tahu saat dipanggil; jangan pernah memodifikasi binary sendiri di belakang pengguna.
4. Rilis bertanda tangan dan berversi dengan changelog. Jika kamu memang mengirim updater, tandatangani artefak dan biarkan pengguna mem-pin versi serta mengaudit perubahan.
5. Disk terbatas dan pemisahan state yang bersih. Simpan paling banyak satu versi sebelumnya, pisahkan konfigurasi dari state, dan ikuti konvensi XDG.
6. Hormati model distro. Seperti kata salah satu komentator, packaging distro ada agar maintainer menguji software dan membuang keanehan sebelum sampai ke pengguna. Jangan melawan itu — publikasikan ke sana.

Tidak satu pun hal ini memperlambat tim yang bergerak cepat secara berarti. Ia hanya memindahkan persetujuan ke bagian depan interaksi, tempat seharusnya ia berada.

Kesimpulannya

Kebenaran yang tidak nyaman adalah bahwa tool coding AI meminta lebih banyak kepercayaan daripada tool developer mana pun dalam sejarah — akses shell, kredensialmu, seluruh source tree-mu — sambil mengadopsi kebersihan update ala adware tahun 2008. Dua fakta ini tidak bisa hidup berdampingan dengan aman. CLI yang memasang daemon persisten dan self-updating secara default telah mengambil keputusan atas namamu, dan keputusan itu adalah bahwa kenyamanan vendor lebih penting daripada kendalimu atas mesinmu sendiri.

Lawan itu. Atur flag-nya, audit mesinmu, ajukan issue, dan pilih tool yang default-nya menghormatimu — naluri yang sama dengan yang membuat orang memilih kebebasan sideloading daripada platform yang terkunci juga berlaku di sini. Tool yang kita biarkan berjalan tanpa pengawasan di laptop developer hari ini akan menjadi laporan insiden supply chain esok hari. Persetujuan bukan fitur tambahan dalam desain update. Itulah seluruh mekanismenya.