Codex CLI’nin Subagent oturum günlüklerinin yüzlerce GB’a büyüyerek diski doldurması sorunu

Codex CLI’nin resume edilmiş uzun süreli oturumlarda tekrar tekrar Subagent oluştururken ~/.codex/sessions altındaki JSONL oturum dosyalarının anormal biçimde büyüdüğü bildirildi
Kamuya açık bir vakada, resume edilmiş tek bir üst oturumdan 2.393 Subagent oturum dosyası oluşturuldu ve bu dosyalar yaklaşık 731,5GiB yer kapladı
Toplam Codex oturum verisi yaklaşık 755GiB’a kadar büyüdü ve 1,8TiB APFS biriminin kullanım oranı %99~100’e ulaştı
Kısa Subagent oturumlarında bile yüz binlerce olay kaydedildi; başka oturumlarda ise compacted geçmişi ve Tool output yüzlerce MB düzeyinde tekrar tekrar saklandı
Sorun, son vakadaki Codex CLI 0.144.6 sürümünde de doğrulandı ve ilgili GitHub issue’su 20 Temmuz 2026 itibarıyla açık durumda

Sorunun belirtileri

Codex CLI, oturumların yeniden açılabilmesi için konuşma ve çalıştırma geçmişini JSONL biçiminde şu yola kaydeder.

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

18 Temmuz 2026’da kaydedilen vakada ~/.codex toplamda yaklaşık 760GiB, bunun içinde ~/.codex/sessions yaklaşık 755GiB kullanıyordu; yalnızca Temmuz oturumları ise yaklaşık 734GiB yer kaplıyordu.

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

Bu veri önbellek değil, codex resume için kullanılan oturum geçmişi olduğundan dosyaların silinmesi geçmiş oturumların yeniden açılamamasına yol açabilir. Bildirim sırasında da birden fazla Codex süreci ilgili JSONL dosyalarını açık tutmaya devam ediyordu.

Ne kadar hızlı büyüdü?

Söz konusu vakanın Temmuz dizininde yaklaşık 2.931 oturum dosyası vardı ve bunların 797’si ayrı ayrı 400MiB’ı aşıyordu. 11 Temmuz’da bir gün içinde yaklaşık 109,1GiB, 12 Temmuz’da ise yaklaşık 149,2GiB oturum verisi üretildiği hesaplandı.

Tarih       Oturum dosyası     400MiB üstü     Yaklaşık boyut  
10 Temmuz       50                  0              2,8GiB  
11 Temmuz      473                  0            109,1GiB  
12 Temmuz      506                  0            149,2GiB  
15 Temmuz      340                265            108,6GiB  
16 Temmuz      355                263            109,0GiB  
17 Temmuz      300                189             81,7GiB

Hacmin büyük bölümü resume edilmiş tek bir üst oturumla bağlantılıydı. Bu üst oturum 2.393 Subagent JSONL dosyası oluşturmuştu ve bunların mantıksal boyutu toplamda yaklaşık 731,5GiB idi. İnceleme anında üst codex resume süreci yaklaşık 23 saattir çalışıyordu.

Hangi workload’da ortaya çıktı?

Bildirilen workflow şöyleydi.

Yerel projede Codex TUI çalıştırma
Subagent veya iş birliği özelliklerini kullanan uzun süreli oturum işi
Mevcut üst oturumu codex resume <thread-id> ile sürdürme
Resume edilmiş süreci saatlerce çalışır tutma
Üst oturumun depth 1 Subagent’ları tekrar tekrar oluşturması

Bu workflow’da günde yüzlerce çocuk JSONL dosyası oluşturuldu ve birçok dosya dakikalar içinde 400~500MiB’a kadar büyüdü. Ancak bildiren kişi bunun minimal yeniden üretim adımları değil, gerçek ortamda gözlemlenen yeniden üretilebilir workflow olduğunu belirtti.

Dolayısıyla kamuya açık mevcut verilerle doğrulanan başlıca büyütme koşulları şu kombinasyondur.

Uzun süre çalışan üst oturum  
+ codex resume  
+ tekrarlanan Subagent oluşturma  
+ Context Compaction  
+ Tool output ve oturum olaylarının kalıcı olarak saklanması

Bu kombinasyon kamuya açık vakanın verileriyle doğrulanıyor; ancak unsurlardan herhangi birinin tek başına her zaman soruna yol açtığı henüz kanıtlanmış değil.

Tek bir dosyanın içinde ne büyüdü?

Örnek bir Subagent yaklaşık 3 dakika 19 saniye çalışmasına rağmen 483.714.063 bayt ve 353.255 JSONL kaydı yazdı. Bu, saniyede yaklaşık 1.770 kayıt ve yaklaşık 2,31MiB yazım hacmine karşılık geliyor.

Bu dosyada büyük paya sahip kayıtlar şunlardı.

event_msg/token_count        185.461 adet    yaklaşık 139,3MB  
compacted                      1.618 adet    yaklaşık 121,6MB  
event_msg/patch_apply_end     36.295 adet    yaklaşık 110,7MB  
event_msg/agent_message      104.653 adet     yaklaşık 41,6MB  
response_item/message          9.947 adet     yaklaşık 34,4MB  
world_state                      607 adet     yaklaşık 18,6MB  
turn_context                   5.322 adet     yaklaşık 11,0MB

Dosyanın büyük kısmını tek bir dev JSON kaydı oluşturmuyordu; kısa çalışma süresi içinde birçok türden olayın binlerce ila yüz binlerce kez kaydedildiği bir yapı söz konusuydu. Bildiren kişi bunu ciddi bir event amplification olarak analiz etti.

Başka bir örnek dosya yaklaşık 925,6MB idi; 175 adet compacted kaydı yaklaşık 571,6MB, 27.848 adet custom_tool_call_output ise yaklaşık 211,7MB kaplıyordu. Bu dosya, kapasite artışına yalnızca olay sayısının değil, büyük Compaction ve Tool output payload’larının tekrar tekrar korunmasının da katkı verdiğine kanıt olarak sunuldu.

Sebep nedir?

Şu anda GitHub issue’sunda OpenAI tarafından doğrulanmış bir Root Cause Analysis yayımlanmış değil. Bu nedenle aşağıdakiler, oturum dosyalarını inceleyen bildirim sahibinin verilerinden çıkarılan tahmini nedenlerdir.

1. Subagent başına olay büyütmesi

Yaklaşık 3 dakika çalışan tek bir Subagent’a 180 binden fazla token_count, 100 binden fazla agent_message, 30 binden fazla patch_apply_end kaydedildi. Normal kullanıcıya görünür activity’den daha fazla olayın çocuk oturum writer’ına iletilmiş veya tekrarlı kaydedilmiş olabileceği öne sürüldü.

2. Compaction history’nin tekrar tekrar saklanması

Büyük oturumlarda compacted kayıtları dosyanın büyük bölümünü kapladı. Ayrı Codex Issue #24948’de de Context Compaction’ın replacement_history ve orijinal Tool output’u tekrar tekrar saklamasıyla tek bir JSONL’in 732MB’a, tüm sessions dizininin yaklaşık 91GB’a büyüdüğü bir vaka bildirildi. Bu issue Codex CLI 0.118.0 ve macOS arm64 ortamında yeniden üretildi ve 28 Mayıs 2026’da kaydedildi.

3. Resume sırasında geçmişin yinelenmiş materialization’ı

Windows Codex App’in ayrı Issue #29531’inde, 2GB’tan fazla büyümüş mevcut bir oturum resume edilince yeni tarih dizininde tekrar 2,3~2,4GB boyutunda rollout dosyalarının oluşturulduğu bir vaka bildirildi. Bildiren kişi, yeni dosyanın yalnızca artımlı olayları kaydetmediğini, mevcut historical context’i kopyaladığını veya replay ettiğini tahmin ediyor.

4. Subagent dosyası başına üst durumun veya çıktının yinelenmesi

Issue #34061’de tek bir üst oturumdan oluşturulan 2.393 çocuk oturum yaklaşık 731,5GiB yer kapladı ve çocuk dosyalarda compacted, Tool output ve yüksek frekanslı olaylar tekrar tekrar gözlemlendi. Buna dayanarak üst durumun veya event stream’in Subagent başına JSONL dosyalarına yinelenerek yazılmasının temel büyütme etkenlerinden biri olduğu tahmin ediliyor. Bu, mevcut kamuya açık verilerle yapılan bir çıkarımdır; OpenAI tarafından doğrulanmış neden değildir.

Mevcut düzeltme durumu

En büyük Subagent disk kullanımı sorununu ele alan Issue #34061, 20 Temmuz 2026 itibarıyla açık durumda; issue’da belirtilen yeniden üretim sürümü Codex CLI 0.144.6.

Compaction ve Tool output sorununu ele alan Issue #24948 de şu anda açık; Resume yineleme sorununu ele alan Issue #29531 de açık durumda.

Dolayısıyla yalnızca kamuya açık issue durumlarına bakıldığında, oturum JSONL büyümesi sorununun tamamının çözüldüğü bir resmi sürüm doğrulanmış değil. Her bir issue’nun aynı kod kusurundan mı kaynaklandığı, yoksa birden fazla persistence sorununun birleşimi mi olduğu da henüz kesinleşmiş değil.

Kontrol yöntemi

Toplam oturum boyutunu kontrol etme:

du -sh ~/.codex/sessions

Yıl/ay bazında boyutu kontrol etme:

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

En büyük JSONL dosyalarını kontrol etme:

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

Aylık dosya sayısını kontrol etme:

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

Issue #34061’e benzer durumlarda belirli bir ayın dosya sayısı hızla artabilir veya yüzlerce MB boyutunda yüzlerce~binlerce çocuk oturum dosyası bulunabilir.

Geçici önlemler

Resmi düzeltme doğrulanmadan önce aşağıdaki workload’u azaltmak makul bir geçici önlemdir.

Tek bir üst oturumu uzun süre codex resume ile açık tutmamak
Resume edilmiş uzun süreli oturumlarda çok sayıda Subagent oluşturmamak
Büyük komut çıktısını olduğu gibi context’e döndürmek yerine dosyaya kaydedip yalnızca gereken bölümleri sorgulamak
~/.codex/sessions dizininin aylık boyutunu ve büyük JSONL dosyalarını düzenli kontrol etmek

Bunlar Issue #24948, #29531, #34061’de gözlemlenen büyütme koşullarından kaçınmaya yönelik önlemlerdir; resmi olarak doğrulanmış workaround değildir.

Oturum dosyalarını silmek disk alanını geri kazandırabilir, ancak ilgili oturumun codex resume ile tekrar açılamaması ihtimali vardır. Önce Codex süreçlerini sonlandırıp gerekli oturumları yedekledikten sonra silmek daha güvenlidir.

İlgili ayrı issue: SQLite geri bildirim günlüğü yazma büyütmesi

Bu sorun, GeekNews’te tanıtılan logs_2.sqlite aşırı loglama sorunu ile depolama konumu ve rol açısından farklıdır.

Önceki issue, aşağıdaki dosyalara global TRACE düzeyinde diagnostic ve feedback log’larının sürekli kaydedilerek SSD yazma hacmini büyütmesi sorunuydu.

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

Bu sorun 14 Haziran 2026’da GitHub Issue #28224 olarak bildirildi; WebSocket olaylarını ve gürültülü log’ları azaltan PR merge edildi ve log’ların yaklaşık %85 azaldığı özetlendi. Bazı düzeltmeler Codex 0.142.0’a dahil edildi, ek düzeltmeler ise 0.143.0 sürüm hedefi olarak kaydedildi.

Buna karşılık bu sorun, resume edilebilir oturum geçmişini saklayan ~/.codex/sessions/**/rollout-*.jsonl dosyalarını hedef alıyor; başlıca büyütme koşulları olarak Context Compaction, Resume ve Subagent session persistence gözlemlendi. SQLite feedback log düzeltmesinin session JSONL sorununu çözdüğüne dair kanıt yok.

Özet

Codex CLI’nin oturum deposu, uzun süre resume edilmiş bir üst oturumun tekrar tekrar Subagent oluşturduğu workload’da anormal biçimde büyüyebilir. En büyük kamuya açık vakada tek bir üst oturumdan oluşturulan 2.393 çocuk oturum yaklaşık 731,5GiB yer kapladı ve tüm sessions dizini yaklaşık 755GiB’a kadar büyüdü.

Oturum içinde kısa sürede yüz binlerce olayın kaydedildiği event amplification ile compacted history ve Tool output’un tekrar tekrar korunması birlikte gözlemlendi. Resume sırasında mevcut multi-GB history’nin yeni rollout dosyasına tekrar oluşturulduğu ayrı bir vaka da bildirildi.

Sorun en büyük ölçekte macOS Codex CLI’de bildirilmiş olsa da Windows Codex App’te de benzer session duplication doğrulandı; 20 Temmuz 2026 itibarıyla başlıca ilgili issue’lar açık durumda. Resmi düzeltme doğrulanana kadar uzun süreli Resume ve yoğun Subagent kullanımını sınırlamak ve ~/.codex/sessions boyutunu düzenli kontrol etmek gerekiyor.