- Dilaporkan ada masalah ketika Codex CLI berulang kali membuat Subagent dalam sesi jangka panjang yang di-
resume, sehingga file sesi JSONL di bawah~/.codex/sessionsmembesar secara tidak normal - Pada kasus publik, satu sesi induk yang di-
resumemenghasilkan 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
compactedserta 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-
resumeterus 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 resumedalam 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/sessionsdan 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
Saya juga sampai beli SSD eksternal karena kapasitas MacBook kurang,
sepertinya harus cek yang ini dulu 馃ゲ
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?