Codex-Kontextfenster-Fehler: So bin ich damit umgegangen

Bei einer langen Session in Codex CLI bin ich auf den Codex-Kontextfenster-Fehler gestoßen. Das ist ein anderes Problem als das 5-Stunden- und das Wochenlimit. Die Limits sind eine zeitliche Grenze, die der Tarif vorgibt. Dieser Fehler tritt auf, wenn die in einer Session angesammelten Tokens die Verarbeitungsgrenze des Modells überschreiten.

/compact hat das Problem nicht immer gelöst. Im Folgenden beschreibe ich, was ich damals konkret getan habe und nach welchen Kriterien ich die vier Befehle resume, fork, new und clear heute einsetze.

Wann der Codex-Kontextfenster-Fehler auftrat und bei welcher Aufgabe

Der Kontextfenster-Fehler von Codex taucht nicht plötzlich mitten in einem kurzen Chat auf. Er baut sich in langen Refactoring-Sessions auf, die zwischen mehreren Modulen hin und her springen, und zwar vor allem gegen Ende.

Bei mir ging es darum, bestehende Logik in einem Java/Spring-Multimodul-Repository aufzuräumen. Angefangen hat es als Änderung an zwei, drei Dateien. Dann wurde der Bereich, den ich untersuchen musste, immer größer, und gelesene Dateien und Diffs sammelten sich an. Den Zyklus Tests ausführen → Fehlerursache prüfen → Code ändern → erneut ausführen habe ich mehrfach wiederholt.

Die Session brach nicht von Anfang an plötzlich ab. Je weiter sie lief, desto öfter musste ich früher Festgelegtes erneut prüfen oder den Kontext aufräumen. Diese Vorzeichen wiederholten sich ein paar Mal, bis es schließlich zum Fehler kam.

Bei einem Skript mit nur einer Datei hätte sich der Kontext vermutlich nicht so schnell gefüllt. Wenn mehrere Module und Testdateien gleichzeitig im Spiel sind, erhöht schon diese Struktur das Tempo, mit dem der Kontext verbraucht wird.

Nicht mit den 5-Stunden- und Wochenlimits verwechseln

Dieser Fehler hat nichts mit aufgebrauchten Nutzungslimits zu tun. Die Limits setzen sich mit der Zeit zurück. Das Kontextfenster hängt dagegen von der Tokenmenge ab, die sich in der Session angesammelt hat. Der Fehler kann also auch auftreten, wenn Ihr Nutzungslimit noch nicht ausgeschöpft ist.

`/compact`: Was danach wirklich bleibt und was verloren geht

/compact ist kein Checkpoint, der das bisherige Gespräch unverändert speichert. Es ist ein Mittel, den Kontext zu verdichten, damit Sie in derselben Session weiterarbeiten können.

Das große Ziel, die wichtigsten Dateien und bereits getroffene Entscheidungen waren nach dem Compact noch da. Die Hintergründe einzelner Detailentscheidungen musste ich aber oft noch einmal erklären.

Auch /compact hat nicht alle Probleme gelöst. War die Session schon zu lang oder hatte sich die Arbeitsrichtung mehrmals geändert, musste ich auch nach dem Compact Erklärungen nachreichen. Heute versuche ich nicht mehr, mit wiederholtem /compact bis zum Schluss durchzuhalten. Sobald ich merke, dass der Aufwand für das Erklären des Kontexts wieder steigt, wechsle ich an diesem Punkt in eine neue Session.

/compact greift außerdem nicht jedes Mal automatisch. Die Fehlermeldung, wie sie in einem GitHub-Issue gemeldet wurde, lautet: Codex ran out of room in the model's context window. Start a new thread or clear earlier history before retrying. (GitHub-Issue #19269, 24. April 2026). Auch im OpenAI-Entwicklerforum gibt es Fälle, die dieselbe Meldung reproduzieren. Der Account OpenAI_Support hat dort nur nach Version, Modell und Logs gefragt. Eine grundlegende Lösung gibt es bisher nicht.

Die 5 Punkte, die ich nach einem Compact selbst neu festhalte

Nach einem Compact schreibe ich diese fünf Punkte jeweils in einem Satz erneut hin:

Das endgültige Ziel der aktuellen Aufgabe
Der Änderungsumfang dieser Session
Die Tests, die noch fehlschlagen
Die Ansätze, die ich ausprobiert und verworfen habe
Die Bereiche, die nicht angefasst werden dürfen

resume, fork, new, clear: Unterschiede und wann welcher Befehl passt

Mit resume führen Sie dieselbe Entscheidungslinie fort. Mit fork testen Sie aus demselben Kontext heraus eine andere Entscheidung, und mit new starten Sie neu, nur mit den Fakten, die bereits feststehen.

Wenn Sie die Befehle wahllos und zu jedem beliebigen Zeitpunkt einsetzen, gerät der Kontext eher noch mehr durcheinander. Nach Situation geordnet sieht es bei mir so aus:

Befehl	Funktion	Wann einsetzen	Was bleibt, was geht verloren
`/compact`	Verdichtet den Kontext innerhalb derselben Session	Die Session läuft noch, aber der Aufwand, den Kontext erneut zu erklären, beginnt gerade zu steigen	Großes Ziel, wichtige Dateien und Entscheidungen bleiben; die Hintergründe im Detail müssen Sie unter Umständen erneut erklären
`codex resume --last`	Setzt dieselbe Session unverändert fort	Die Richtung der Entscheidungen stimmt noch, es geht nur im Detail weiter	Der bisherige Verlauf bleibt erhalten. Ist der Kontext aber schon voll, kann der Fehler erneut auftreten
`codex fork --last`	Startet aus demselben Kontext einen neuen Zweig	Sie wollen den bisherigen Kontext behalten, aber einen anderen Ansatz testen	Der vorhandene Kontext bleibt, der weitere Verlauf trennt sich je Zweig
`/new`	Startet eine neue Session	Hypothesen und gescheiterte Ansätze haben sich gestapelt, der Kontext selbst ist verunreinigt	Die Details des bisherigen Kontexts gehen verloren; bestätigte Fakten müssen Sie selbst wieder eingeben

/clear ist kein Befehl, den ich oft benutze. Dazu habe ich keinen konkreten Fall, deshalb halte ich hier nur fest, dass ich ihn selten verwende.

Das Kriterium in einem Satz

Das Signal für eine neue Session ist der Moment, in dem das erneute Erklären des Kontexts mehr kostet als das Verdichten und Weiterführen. Dass der Kontext lang ist, ist an sich kein Problem.

Ich halte es nicht für immer vorteilhaft, möglichst viel Kontext zu behalten. Gerade bei Aufgaben wie Refactoring, bei denen sich Zwischenentscheidungen ständig ändern, war es stabiler, ab einem gewissen Punkt nur die bestätigten Fakten herauszuziehen und in eine neue Session mitzunehmen, statt alten Kontext komprimiert immer weiter mitzuschleppen.

Das Kriterium, um diesen Moment zu erkennen, ist einfach.

Wenn Sie auch nach einem Compact immer häufiger Erklärungen nachreichen, ist der Aufwand fürs Weiterführen bereits größer als der für einen Neustart.

Warum ich Auto-Compact in den aktuellen Versionen nicht zu 100 % vertraue

Wie zuverlässig die automatische Verdichtung (Auto-Compact) arbeitet, hat sich von Version zu Version geändert. Besser ist es, zuerst in den GitHub-Issues zu prüfen, ob Ihr Symptom eine bekannte Regression ist.

In den GitHub-Issues sind außerdem gesondert Regressionen gemeldet, bei denen Auto-Compact in bestimmten Versionen gar nicht auslöst.

Die Schwelle für Auto-Compact ist kein Wert aus der offiziellen Dokumentation, sondern internes Verhalten, das sich über GitHub-Issues nachvollziehen lässt. Laut GitHub-Issue #11805 wird seit v0.100.0 die vom Nutzer festgelegte Compact-Schwelle zwangsweise auf 90 % des Kontextfensters begrenzt (eröffnet am 14. Februar 2026, inzwischen mit dem Status „not planned“ geschlossen). Auch eine Regression, bei der Auto-Compact überhaupt nicht ausgeführt wird, wurde gemeldet: ein Issue, laut dem Compact in v0.42.0 bei großen Änderungssätzen nicht automatisch startet.

Dieser Abschnitt gibt den Stand zum Zeitpunkt des Schreibens wieder (September 2026). Ob sich das Verhalten seitdem stabilisiert hat, muss erneut geprüft werden.

Häufige Fragen

Der Kontextfenster-Fehler bleibt auch nach `/compact`. Was kann ich tun?

Es kann sich um eine Regression handeln, bei der Auto-Compact nicht auslöst. Dann ist es stabiler, nicht immer wieder zu komprimieren, sondern Ziel, Änderungsumfang und fehlschlagende Tests in je einem Satz festzuhalten und in eine neue Session zu wechseln.

Bleibt die bisherige Arbeit mit `codex resume --last` oder `fork --last` unverändert erhalten?

Mit resume läuft der Verlauf unverändert weiter, aber wenn der Kontext schon voll ist, kann der Fehler erneut auftreten. Mit fork entsteht ein neuer Zweig, der den bisherigen Kontext übernimmt, dabei bleiben aber nicht alle Details vollständig erhalten.

Es gibt doch Auto-Compact. Warum sollte ich manuell eingreifen?

Es wurden Versionen gemeldet, in denen Auto-Compact nicht auslöst. Besser ist es, zuerst zu prüfen, ob Ihr Symptom eine bekannte Regression ist, und manuelles Eingreifen zur Regel zu machen, statt sich auf die Automatik zu verlassen.

Quellen

GitHub-Issue #19269 – Referenzfall (Primärquelle) für die Fehlermeldung „Codex ran out of room…“ (2026-04-24, Codex CLI v0.124.0)
Thread im OpenAI-Entwicklerforum – Reproduktion desselben Fehlers und offizielle Antwort von OpenAI_Support (ohne grundlegende Lösung)
GitHub-Issue #11805 – Beleg dafür, dass die Auto-Compact-Schwelle seit v0.100.0 zwangsweise auf 90 % des Kontextfensters begrenzt ist (2026-02-14, mit dem Status „not planned“ geschlossen)
GitHub-Issue #4363 – Meldung einer Regression, bei der Compact in v0.42.0 bei großen Änderungssätzen nicht automatisch startet

Dieser Artikel wurde auf Basis des koreanischen Originals lokalisiert: https://jjeongil.tistory.com/3568.