3 poin oleh click 17 jam lalu | 2 komentar | Bagikan ke WhatsApp
  • Dilaporkan ada masalah ketika Codex CLI berulang kali membuat Subagent dalam sesi jangka panjang yang di-resume, sehingga file sesi JSONL di bawah ~/.codex/sessions membesar secara tidak normal
  • Pada kasus publik, satu sesi induk yang di-resume menghasilkan 2.393 file sesi Subagent, dan file-file ini memakan sekitar 731.5GiB
  • Total data sesi Codex meningkat hingga sekitar 755GiB, dan penggunaan volume APFS 1.8TiB mencapai 99~100%
  • Bahkan pada sesi Subagent yang singkat, tercatat ratusan ribu event, dan pada sesi lain riwayat compacted serta output Tool disimpan berulang kali dalam ukuran ratusan MB
  • Masalah ini juga dikonfirmasi pada Codex CLI 0.144.6 dalam kasus terbaru, dan issue GitHub terkait masih terbuka per 20 Juli 2026

Gejala masalah

Codex CLI menyimpan percakapan dan riwayat eksekusi dalam format JSONL di jalur berikut agar sesi bisa dibuka kembali.

~/.codex/sessions/YYYY/MM/DD/rollout-*.jsonl  

Dalam kasus yang didaftarkan pada 18 Juli 2026, seluruh ~/.codex menggunakan sekitar 760GiB, dan ~/.codex/sessions di dalamnya memakai sekitar 755GiB, dengan sesi bulan Juli saja memakan sekitar 734GiB.

760G  ~/.codex  
755G  ~/.codex/sessions  
734G  ~/.codex/sessions/2026/07  

Data ini bukan cache, melainkan riwayat sesi yang dipakai oleh codex resume, sehingga jika file dihapus, ada kemungkinan sesi lama tidak lagi bisa dibuka kembali. Saat laporan dibuat, beberapa proses Codex juga masih membiarkan file JSONL tersebut tetap terbuka.

Seberapa cepat ukurannya bertambah

Direktori bulan Juli pada kasus tersebut memiliki sekitar 2.931 file sesi, dan 797 di antaranya masing-masing melebihi 400MiB. Tercatat bahwa pada 11 Juli dihasilkan sekitar 109.1GiB data sesi dalam sehari, dan pada 12 Juli sekitar 149.2GiB.

Tanggal       File sesi     Lebih dari 400MiB     Perkiraan ukuran  
10 Juli              50                    0              2.8GiB  
11 Juli             473                    0            109.1GiB  
12 Juli             506                    0            149.2GiB  
15 Juli             340                  265            108.6GiB  
16 Juli             355                  263            109.0GiB  
17 Juli             300                  189             81.7GiB  

Sebagian besar ukuran ini terkait dengan satu sesi induk yang di-resume. Sesi induk ini menghasilkan 2.393 file JSONL Subagent, dan ukuran logis gabungannya sekitar 731.5GiB. Pada saat investigasi, proses induk codex resume telah berjalan sekitar 23 jam.

Terjadi pada workload seperti apa

Workflow yang dilaporkan adalah sebagai berikut.

  • Menjalankan Codex TUI di proyek lokal
  • Bekerja dalam sesi jangka panjang yang menggunakan Subagent atau fitur kolaborasi
  • Melanjutkan sesi induk yang sudah ada dengan codex resume <thread-id>
  • Membiarkan proses yang di-resume terus berjalan selama berjam-jam
  • Sesi induk berulang kali membuat Subagent dengan depth 1

Dalam workflow ini, ratusan file JSONL anak dibuat per hari, dan banyak file membesar hingga 400~500MiB hanya dalam beberapa menit. Namun pelapor menegaskan bahwa ini bukan langkah reproduksi minimal, melainkan workflow reproduksi yang diamati di lingkungan nyata.

Karena itu, kombinasi kondisi penguat utama yang bisa dikonfirmasi dari materi publik saat ini adalah sebagai berikut.

Sesi induk yang berjalan lama  
+ codex resume  
+ pembuatan Subagent berulang  
+ Context Compaction  
+ penyimpanan permanen output Tool dan event sesi  

Kombinasi ini terkonfirmasi oleh data pada kasus publik, tetapi belum terbukti apakah salah satu faktor saja selalu cukup untuk memicu masalah.

Apa yang membesar di dalam satu file

Satu Subagent representatif berjalan hanya sekitar 3 menit 19 detik, tetapi mencatat 483,714,063 byte dan 353,255 record JSONL. Ini setara dengan sekitar 1.770 record per detik dan laju pencatatan sekitar 2.31MiB per detik.

Record yang mengambil porsi besar pada file ini adalah sebagai berikut.

event_msg/token_count        185,461    sekitar 139.3MB  
compacted                      1,618    sekitar 121.6MB  
event_msg/patch_apply_end     36,295    sekitar 110.7MB  
event_msg/agent_message      104,653     sekitar 41.6MB  
response_item/message          9,947     sekitar 34.4MB  
world_state                      607     sekitar 18.6MB  
turn_context                   5,322     sekitar 11.0MB  

Bukan satu record JSON raksasa yang memenuhi sebagian besar file, melainkan berbagai jenis event yang dicatat ribuan hingga ratusan ribu kali dalam waktu eksekusi singkat. Pelapor menganalisis ini sebagai event amplification yang serius.

File representatif lain berukuran sekitar 925.6MB, dengan 175 record compacted memakan sekitar 571.6MB dan 27,848 custom_tool_call_output memakan sekitar 211.7MB. File ini diajukan sebagai bukti bahwa bukan hanya jumlah event, tetapi juga pelestarian berulang payload Compaction dan output Tool berukuran besar ikut mendorong pembengkakan ukuran.

Apa penyebabnya

Saat ini belum ada Root Cause Analysis yang telah dikonfirmasi OpenAI dan dipublikasikan di issue GitHub. Karena itu, isi berikut adalah dugaan penyebab yang ditarik dari data investigasi file sesi oleh pelapor.

1. Amplifikasi event per Subagent

Pada satu Subagent yang berjalan sekitar 3 menit, tersimpan lebih dari 180 ribu token_count, lebih dari 100 ribu agent_message, dan lebih dari 30 ribu patch_apply_end. Muncul dugaan bahwa event yang jumlahnya melebihi aktivitas yang terlihat oleh pengguna dikirim ke writer sesi anak atau dicatat berulang kali.

2. Penyimpanan berulang riwayat Compaction

Pada sesi besar, record compacted memenuhi sebagian besar file. Dalam Codex Issue #24948 yang terpisah, juga dilaporkan kasus di mana replacement_history dari Context Compaction dan output Tool asli disimpan berulang kali, sehingga satu JSONL membesar menjadi 732MB dan seluruh direktori sessions mencapai sekitar 91GB. Issue tersebut direproduksi pada Codex CLI 0.118.0 dan lingkungan macOS arm64, serta didaftarkan pada 28 Mei 2026.

3. Materialisasi duplikat riwayat lama saat Resume

Dalam Issue #29531 yang terpisah untuk Windows Codex App, dilaporkan bahwa ketika sesi yang sudah membesar lebih dari 2GB di-resume, file rollout baru berukuran 2.3~2.4GB kembali dibuat di direktori tanggal yang baru. Pelapor menduga bahwa file baru ini tidak hanya mencatat event inkremental, tetapi juga menyalin atau me-replay konteks historis yang sudah ada.

4. Duplikasi status atau output induk di tiap file Subagent

Dalam Issue #34061, 2.393 sesi anak yang dibuat dari satu sesi induk memakan sekitar 731.5GiB, dan pada file anak berulang kali teramati compacted, output Tool, serta event berfrekuensi tinggi. Berdasarkan ini, diduga bahwa pencatatan duplikat status induk atau stream event ke JSONL tiap Subagent menjadi salah satu faktor amplifikasi utama. Ini adalah inferensi dari data publik yang tersedia saat ini, bukan penyebab final yang telah dikonfirmasi OpenAI.

Status perbaikan saat ini

Issue #34061 yang menangani masalah penggunaan disk terbesar oleh Subagent masih berstatus Open per 20 Juli 2026, dan versi reproduksi yang tercantum pada issue adalah Codex CLI 0.144.6.

Issue #24948 yang membahas masalah Compaction dan output Tool juga masih Open, begitu pula Issue #29531 yang membahas duplikasi saat Resume.

Karena itu, jika hanya berdasarkan status issue yang dipublikasikan saat ini, belum ada rilis resmi yang bisa dipastikan telah menyelesaikan keseluruhan masalah pembengkakan JSONL sesi. Juga belum dipastikan apakah masing-masing issue berasal dari cacat kode yang sama atau dari beberapa masalah persistence yang saling bergabung.

Cara memeriksa

Memeriksa ukuran total sesi:

du -sh ~/.codex/sessions  

Memeriksa ukuran per tahun-bulan:

du -sh ~/.codex/sessions/*/*  

Memeriksa file JSONL terbesar:

find ~/.codex/sessions \  
  -type f \  
  -name '*.jsonl' \  
  -exec du -h {} + |  
sort -hr |  
head -30  

Memeriksa jumlah file per bulan:

find ~/.codex/sessions/2026/07 \  
  -type f \  
  -name '*.jsonl' |  
wc -l  

Pada kasus yang mirip dengan Issue #34061, jumlah file pada bulan tertentu bisa melonjak tajam, atau ratusan hingga ribuan file sesi anak berukuran ratusan MB bisa ditemukan.

Penanganan sementara

Sebelum ada konfirmasi perbaikan resmi, masuk akal untuk mengurangi workload berikut sebagai penanganan sementara.

  • Jangan mempertahankan satu sesi induk dengan codex resume dalam waktu sangat lama
  • Jangan membuat Subagent dalam jumlah besar pada sesi jangka panjang yang di-resume
  • Jangan mengembalikan output perintah berukuran besar langsung ke context; simpan ke file lalu ambil hanya bagian yang diperlukan
  • Periksa secara berkala ukuran bulanan ~/.codex/sessions dan file JSONL yang besar

Ini adalah langkah pencegahan untuk menghindari kondisi amplifikasi yang diamati pada Issue #24948, #29531, dan #34061, dan bukan workaround yang telah divalidasi secara resmi.

Menghapus file sesi memang bisa mengosongkan ruang disk, tetapi ada kemungkinan sesi tersebut tak lagi bisa dibuka lewat codex resume. Lebih aman menghentikan proses Codex terlebih dahulu, mencadangkan sesi yang diperlukan, lalu menghapusnya.

Issue terpisah terkait: amplifikasi penulisan log feedback SQLite

Masalah ini berbeda dari logs_2.sqlite masalah logging berlebihan yang pernah diperkenalkan di GeekNews, baik dari lokasi penyimpanan maupun perannya.

Issue sebelumnya adalah masalah yang terus menyimpan log diagnostik dan feedback tingkat TRACE global ke file berikut, sehingga memperbesar jumlah penulisan ke SSD.

~/.codex/logs_2.sqlite  
~/.codex/logs_2.sqlite-wal  
~/.codex/logs_2.sqlite-shm  

Masalah tersebut dilaporkan pada 14 Juni 2026 sebagai GitHub Issue #28224, dan diringkas bahwa PR yang mengurangi event WebSocket dan log berisik telah digabungkan sehingga log berkurang sekitar 85%. Sebagian perbaikan masuk ke Codex 0.142.0 dan perbaikan tambahan dicatat untuk rilis 0.143.0.

Sebaliknya, masalah kali ini menargetkan ~/.codex/sessions/**/rollout-*.jsonl yang menyimpan riwayat sesi yang bisa di-Resume, dan Context Compaction, Resume, serta session persistence Subagent diamati sebagai kondisi amplifikasi utama. Tidak ada bukti bahwa perbaikan log feedback SQLite saja menyelesaikan masalah JSONL sesi.

Ringkasan

Penyimpanan sesi Codex CLI dapat membesar secara tidak normal pada workload ketika sesi induk yang di-resume dalam waktu lama berulang kali membuat Subagent. Pada kasus publik terbesar, 2.393 sesi anak yang dibuat dari satu sesi induk memakan sekitar 731.5GiB, dan seluruh direktori sessions membesar hingga sekitar 755GiB.

Di dalam sesi, teramati event amplification berupa ratusan ribu event yang tercatat dalam waktu singkat, bersama penyimpanan berulang riwayat compacted dan output Tool. Juga dilaporkan kasus terpisah di mana riwayat multi-GB yang sudah ada dibuat ulang ke file rollout baru saat Resume.

Masalah ini dilaporkan dalam skala terbesar pada Codex CLI di macOS, tetapi duplikasi sesi serupa juga dikonfirmasi pada Windows Codex App, dan per 20 Juli 2026 issue utama terkait masih terbuka. Sampai ada konfirmasi perbaikan resmi, penggunaan Resume jangka panjang dan Subagent dalam jumlah besar perlu dibatasi, dan ukuran ~/.codex/sessions perlu diperiksa secara berkala.

2 komentar

 
moderato 4 jam lalu

Saya juga sampai beli SSD eksternal karena kapasitas MacBook kurang,
sepertinya harus cek yang ini dulu 馃ゲ

 
click 17 jam lalu

Belakangan ini saya sering mendapat notifikasi bahwa kapasitas MacBook hampir habis, lalu setelah dicek ternyata penyebabnya Codex CLI. Di kondisi saya yang serba terbatas, ini juga memakan puluhan GB, jadi saya sedang mempertimbangkan untuk menghapus riwayat lama. Bagaimana kalian menanganinya?