Problem: Subagent-Sitzungslogs von Codex CLI wachsen auf Hunderte GB an und füllen den Datenträger

Es wurde ein Problem gemeldet, bei dem JSONL-Sitzungsdateien unter ~/.codex/sessions abnormal anwachsen, wenn Codex CLI in fortgesetzten Langzeitsitzungen wiederholt Subagents erzeugt
In einem öffentlich dokumentierten Fall wurden in einer einzigen fortgesetzten übergeordneten Sitzung 2.393 Subagent-Sitzungsdateien erzeugt, die zusammen etwa 731,5GiB belegten
Die gesamten Codex-Sitzungsdaten wuchsen auf etwa 755GiB an, und die Auslastung eines 1,8TiB-APFS-Volumes erreichte 99–100 %
Selbst in kurzen Subagent-Sitzungen wurden Hunderttausende Events aufgezeichnet; in anderen Sitzungen wurden compacted-Verläufe und Tool-Output wiederholt in Größenordnungen von Hunderten MB gespeichert
Das Problem wurde auch in Codex CLI 0.144.6 aus dem jüngsten Fall bestätigt; das zugehörige GitHub-Issue ist mit Stand 20. Juli 2026 weiterhin offen

Symptome des Problems

Codex CLI speichert Unterhaltungen und Ausführungsverläufe im JSONL-Format unter folgendem Pfad, damit Sitzungen erneut geöffnet werden können.

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

In dem am 18. Juli 2026 gemeldeten Fall belegte ~/.codex insgesamt etwa 760GiB, davon ~/.codex/sessions etwa 755GiB und allein die Juli-Sitzungen etwa 734GiB.

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

Diese Daten sind kein Cache, sondern der für codex resume verwendete Sitzungsverlauf. Werden die Dateien gelöscht, kann es daher sein, dass sich frühere Sitzungen nicht mehr erneut öffnen lassen. Zum Zeitpunkt der Meldung hielten außerdem mehrere Codex-Prozesse die betreffenden JSONL-Dateien weiterhin geöffnet.

Wie schnell wuchs das an?

Im Juli-Verzeichnis dieses Falls lagen etwa 2.931 Sitzungsdateien, davon 797 mit jeweils mehr als 400MiB. Für den 11. Juli wurden etwa 109,1GiB neu erzeugte Sitzungsdaten ermittelt, für den 12. Juli etwa 149,2GiB.

Datum        Sitzungsdateien   über 400MiB     ungefähre Größe  
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

Der Großteil des Volumens war mit einer einzigen fortgesetzten übergeordneten Sitzung verknüpft. Diese übergeordnete Sitzung erzeugte 2.393 Subagent-JSONL-Dateien mit einer gesamten logischen Größe von etwa 731,5GiB. Zum Zeitpunkt der Untersuchung lief der übergeordnete codex resume-Prozess bereits seit etwa 23 Stunden.

Bei welcher Workload trat es auf?

Der gemeldete Workflow sah wie folgt aus.

Start von Codex TUI in einem lokalen Projekt
Arbeit in einer Langzeitsitzung mit Nutzung von Subagent- oder Kollaborationsfunktionen
Fortsetzen einer bestehenden übergeordneten Sitzung mit codex resume <thread-id>
Weiterlaufen des fortgesetzten Prozesses über mehrere Stunden
Die übergeordnete Sitzung erzeugt wiederholt Subagents mit Tiefe 1

In diesem Workflow wurden pro Tag Hunderte JSONL-Dateien von Kind-Sitzungen erzeugt, und viele davon wuchsen innerhalb weniger Minuten auf 400–500MiB an. Der Melder stellte jedoch klar, dass es sich nicht um minimale Reproduktionsschritte handelt, sondern um einen in einer realen Umgebung beobachteten Reproduktions-Workflow.

Daher lassen sich aus den aktuell öffentlich verfügbaren Daten folgende wesentliche Verstärkungsbedingungen ableiten.

eine lange laufende übergeordnete Sitzung  
+ codex resume  
+ wiederholte Erzeugung von Subagents  
+ Context Compaction  
+ persistente Speicherung von Tool-Output und Sitzungs-Events

Diese Kombination ist durch die Daten des öffentlichen Falls belegt, aber es ist noch nicht nachgewiesen, dass jedes einzelne Element für sich genommen das Problem immer auslöst.

Was wuchs innerhalb einer einzelnen Datei an?

Ein repräsentativer Subagent lief nur etwa 3 Minuten und 19 Sekunden, schrieb dabei jedoch 483.714.063 Byte und 353.255 JSONL-Records. Das entspricht etwa 1.770 Records pro Sekunde und einem Schreibvolumen von rund 2,31MiB pro Sekunde.

In dieser Datei entfiel ein großer Anteil auf folgende Record-Typen.

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

Nicht ein einzelner riesiger JSON-Record belegte den Großteil der Datei, sondern viele verschiedene Event-Typen wurden während einer kurzen Laufzeit Tausende bis Hunderttausende Male geschrieben. Der Melder analysierte dies als schwerwiegende Event-Amplification.

Eine andere repräsentative Datei war etwa 925,6MB groß; darin belegten 175 compacted-Records etwa 571,6MB und 27.848 custom_tool_call_output-Records etwa 211,7MB. Diese Datei wurde als Beleg angeführt, dass nicht nur die Anzahl der Events, sondern auch die wiederholte Aufbewahrung großer Compaction- und Tool-Output-Payloads zum Größenwachstum beiträgt.

Was ist die Ursache?

Im aktuellen GitHub-Issue wurde noch keine von OpenAI bestätigte Root Cause Analysis veröffentlicht. Daher beruhen die folgenden Punkte auf vermuteten Ursachen, die aus den vom Melder untersuchten Sitzungsdateien abgeleitet wurden.

1. Event-Amplification pro Subagent

In einem rund drei Minuten laufenden Subagent wurden über 180.000 token_count-, über 100.000 agent_message- und über 30.000 patch_apply_end-Einträge gespeichert. Es wird vermutet, dass mehr Events als normale für Nutzer sichtbare Aktivität an den Writer der Kind-Sitzung weitergegeben oder wiederholt geschrieben wurden.

2. Wiederholte Speicherung der Compaction-Historie

In großen Sitzungen machten compacted-Records den Großteil der Datei aus. In Codex Issue #24948 wurde ebenfalls ein Fall gemeldet, in dem replacement_history der Context Compaction und ursprünglicher Tool-Output wiederholt gespeichert wurden, wodurch eine einzelne JSONL-Datei auf 732MB und das gesamte sessions-Verzeichnis auf etwa 91GB anwuchs. Dieses Issue wurde mit Codex CLI 0.118.0 unter macOS arm64 reproduziert und am 28. Mai 2026 eingereicht.

3. Doppelte Materialisierung alter Historie beim Resume

In dem separaten Issue #29531 der Windows-Codex-App wurde gemeldet, dass nach dem Fortsetzen einer bestehenden Sitzung, die bereits auf über 2GB angewachsen war, im Verzeichnis eines neuen Datums erneut Rollout-Dateien von 2,3–2,4GB erzeugt wurden. Der Melder vermutete, dass die neuen Dateien nicht nur inkrementelle Events aufzeichnen, sondern bestehenden historischen Kontext kopieren oder erneut abspielen.

4. Duplizierung des Zustands oder Outputs der übergeordneten Sitzung pro Subagent-Datei

In Issue #34061 belegten 2.393 in einer einzigen übergeordneten Sitzung erzeugte Kind-Sitzungen etwa 731,5GiB; in den Kind-Dateien wurden wiederholt compacted, Tool-Output und hochfrequente Events beobachtet. Daraus wird abgeleitet, dass die mehrfache Aufzeichnung des Zustands oder Event-Streams der übergeordneten Sitzung in jeder Subagent-JSONL eine der zentralen Verstärkungsursachen sein könnte. Das ist eine Schlussfolgerung auf Basis der aktuell öffentlichen Daten und keine von OpenAI bestätigte Ursache.

Aktueller Stand des Fixes

Issue #34061, das das größte bekannte Subagent-Datenträgerproblem behandelt, ist mit Stand 20. Juli 2026 offen; als betroffene Version ist dort Codex CLI 0.144.6 angegeben.

Auch Issue #24948 zum Problem mit Compaction und Tool-Output ist derzeit offen, ebenso Issue #29531 zum Resume-Duplikationsproblem.

Legt man nur den öffentlich sichtbaren Status dieser Issues zugrunde, lässt sich derzeit keine offizielle Release-Version bestätigen, in der das gesamte JSONL-Wachstumsproblem der Sitzungen behoben wäre. Ebenfalls ungeklärt ist, ob alle Issues auf denselben Codefehler zurückgehen oder ob mehrere Persistenzprobleme zusammenwirken.

So lässt es sich prüfen

Gesamte Sitzungsgröße prüfen:

du -sh ~/.codex/sessions

Größe nach Jahr und Monat prüfen:

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

Größte JSONL-Dateien finden:

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

Anzahl der Dateien pro Monat prüfen:

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

In Fällen ähnlich zu Issue #34061 kann die Dateizahl eines bestimmten Monats sprunghaft ansteigen oder es können Hunderte bis Tausende Kind-Sitzungsdateien von mehreren Hundert MB gefunden werden.

Vorläufige Gegenmaßnahmen

Bis ein offizieller Fix bestätigt ist, erscheint es sinnvoll, die folgende Workload zu reduzieren.

Eine einzelne übergeordnete Sitzung nicht über lange Zeit mit codex resume am Leben halten
In fortgesetzten Langzeitsitzungen nicht massenhaft Subagents erzeugen
Große Befehlsausgaben nicht unverändert in den Kontext zurückgeben, sondern in Dateien speichern und nur benötigte Teile abrufen
Die monatliche Größe von ~/.codex/sessions und große JSONL-Dateien regelmäßig prüfen

Dies sind Vorsichtsmaßnahmen, um die in Issue #24948, #29531 und #34061 beobachteten Verstärkungsbedingungen zu vermeiden; es handelt sich nicht um offiziell validierte Workarounds.

Das Löschen von Sitzungsdateien kann zwar Speicherplatz freigeben, aber möglicherweise verhindern, dass sich die betreffende Sitzung erneut mit codex resume öffnen lässt. Sicherer ist es, zuerst die Codex-Prozesse zu beenden, benötigte Sitzungen zu sichern und sie erst danach zu löschen.

Separates verwandtes Issue: Schreibamplification bei SQLite-Feedback-Logs

Dieses Problem unterscheidet sich in Speicherort und Funktion von dem auf GeekNews vorgestellten Problem mit übermäßigem Logging in logs_2.sqlite.

Beim früheren Issue wurden globale TRACE-Level-Diagnose- und Feedback-Logs fortlaufend in die folgenden Dateien geschrieben, was die SSD-Schreiblast verstärkte.

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

Dieses Problem wurde am 14. Juni 2026 als GitHub Issue #28224 gemeldet; ein PR zur Reduzierung von WebSocket-Events und Rausch-Logs wurde gemergt, wodurch die Logs laut Zusammenfassung um etwa 85 % zurückgingen. Ein Teil der Fixes wurde in Codex 0.142.0 aufgenommen, weitere Fixes sind für Release 0.143.0 vermerkt.

Das aktuelle Problem betrifft dagegen ~/.codex/sessions/**/rollout-*.jsonl, das fortsetzbare Sitzungsverläufe speichert; als wesentliche Verstärkungsbedingungen wurden Context Compaction, Resume und die Persistenz von Subagent-Sitzungen beobachtet. Es gibt keinen Beleg dafür, dass der Fix für die SQLite-Feedback-Logs das JSONL-Problem der Sitzungen mitbehebt.

Zusammenfassung

Das Sitzungs-Storage von Codex CLI kann bei Workloads, in denen eine lange fortgesetzte übergeordnete Sitzung wiederholt Subagents erzeugt, abnormal anwachsen. Im größten öffentlich dokumentierten Fall belegten 2.393 in einer einzigen übergeordneten Sitzung erzeugte Kind-Sitzungen etwa 731,5GiB, und das gesamte sessions-Verzeichnis wuchs auf etwa 755GiB an.

Innerhalb der Sitzungen wurden sowohl Event-Amplification mit Hunderttausenden aufgezeichneten Events in kurzer Zeit als auch die wiederholte Aufbewahrung von compacted-Historie und Tool-Output beobachtet. Zusätzlich wurde ein separater Fall gemeldet, in dem beim Resume bestehende mehrgigabytegroße Historie erneut in neuen Rollout-Dateien erzeugt wurde.

Das Problem wurde in größtem Umfang unter macOS mit Codex CLI gemeldet, aber ähnliche Sitzungsduplikation wurde auch in der Windows-Codex-App bestätigt; mit Stand 20. Juli 2026 sind die wichtigsten zugehörigen Issues weiterhin offen. Bis ein offizieller Fix bestätigt ist, sollte die Nutzung von langem Resume und vielen Subagents begrenzt und die Größe von ~/.codex/sessions regelmäßig überprüft werden.