OpenClaw und Codex: Wer in langen Agentenläufen den Kontext hält

Wenn ein langer Agentenlauf nach mehreren Werkzeugaufrufen plötzlich den Faden verliert, ist „Kontext weg“ keine ausreichende Diagnose. Bei OpenAI-Modellen kann die Ursache im sichtbaren OpenClaw-Verlauf liegen – oder im nativen Thread, den der Codex-Harness fortführt und komprimiert. Das sind zwei unterschiedliche Fehlerdomänen.

Für den Betrieb zählt deshalb zuerst das beobachtbare Symptom. Fehlt eine Nachricht nur im Kanal? Bricht eine Werkzeugkette ab? Oder verändert sich die Antwort erst nach einer Kontextverdichtung? Wer diese Fragen vermischt, sucht an der falschen Stelle und ändert womöglich Einstellungen, die den betroffenen Lauf gar nicht erreichen.

Zwei Zuständigkeiten, ein Agentenlauf

Der Codex-Harness hält den nativen Thread-Zustand, setzt Werkzeuge innerhalb dieses Threads fort und komprimiert Kontext. Die Ausführung läuft über den App-Server. OpenClaw steuert dagegen die Umgebung: Kanäle, Sitzungsdaten, Modellauswahl, Freigaben, dynamische Werkzeuge, Medien und den sichtbaren Transkriptspiegel.

In einem Support-Lauf kann das sehr konkret werden: Nach mehreren Dateianhängen und Werkzeugaufrufen antwortet der Agent anders als zu Beginn. Der Chatverlauf sieht vollständig aus, obwohl die Thread-Fortsetzung bereits mit verdichtetem Kontext arbeitet. Umgekehrt kann eine Nachricht im Kanal fehlen oder verkürzt erscheinen, ohne dass der native Thread seinen Zusammenhang verloren hat.

Hilfreich ist, Kanaltranskript und Verhalten der Werkzeugfortsetzung getrennt anzusehen. Bei einem reinen Darstellungsproblem sollte der Thread unverändert weiterlaufen. Verändert sich die Fortsetzung selbst nach einer Verdichtung, gehört die Untersuchung zur Codex-Seite.

Komprimierung folgt dem Codex-Laufweg

Lokale Overrides für ein Komprimierungsmodell werden bei Codex-gestützten Agenten zur Laufzeit nicht angewendet. Die Verdichtung erfolgt im Thread-Zustand des Codex-App-Servers.

Das betrifft lange Aufgaben mit vielen Werkzeugschritten besonders deutlich. Eine Komprimierung entscheidet, welche Informationen die Fortsetzung noch erhält. Wenn sie in der nativen Runtime stattfindet, lassen sich Zeitpunkt, Format und Inhalt nicht automatisch über lokale OpenClaw-Einstellungen beeinflussen.

Auch bei einem entfernten Codex-App-Server bleibt die Zuständigkeit getrennt: Für Anhänge prüft OpenClaw den konfigurierten Workspace-Bezug und überträgt relevante Dateidaten über die App-Server-Verbindung. Eine gemeinsam synchronisierte Festplatte ist damit nicht für jeden entfernten Lauf nötig. Bei fehlenden Anhängen lohnt sich deshalb der Blick auf Workspace-Bezug und Übertragungsweg, bevor pauschal der Kontext verdächtigt wird.

Wo die Fehlersuche bei Codex-Läufen beginnt

OpenClaw behält Kanäle, Persona, Memory, Sitzungen, Cron, Medien, Browser, Gateway und eigene Werkzeuge. Codex übernimmt den OpenAI-nahen Ablauf mit Thread-Zustand, Werkzeugfortsetzung, Komprimierung, Code-Modus und dynamischer Werkzeugsuche.

Werkzeugschemata werden bei der dynamischen Suche erst geladen, wenn ein Agent sie benötigt. Das hält den Anfangskontext kleiner, besonders in Installationen mit vielen Werkzeugen. Für lange Läufe ist das kein Freifahrtschein: Wenn ein Tool nicht wie erwartet verfügbar ist, sollte der Betrieb prüfen, ob die Suche ausgelöst wurde und ob die Fortsetzung im selben Thread stattfindet.

Für mich ist genau diese Trennung der nützlichste Teil der Architektur. Sie verhindert, dass ein sichtbarer Kanalfehler vorschnell als Modell- oder Kontextproblem behandelt wird. Erst Kanal, Modellwahl und Freigaben prüfen. Dann vergleichen, ob die Werkzeugfortsetzung im nativen Thread noch vorhanden ist. Tritt die Abweichung erst nach einer Verdichtung auf, ist das der entscheidende Befund. Tritt sie nur im Kanal auf, bleibt die Codex-Thread-Diagnose zunächst Nebensache.

Die Mindestregel für lange Läufe

Der sichtbare Verlauf beantwortet, was Nutzerinnen und Nutzer gesehen haben und welche Entscheidungen im Betrieb zulässig waren. Der native Thread erklärt, wie der OpenAI-Agent seine Arbeit innerhalb eines längeren Laufs fortsetzt. Beide Ebenen hängen zusammen, sind aber nicht identisch.

Vor einer Konfigurationsänderung braucht es deshalb eine präzise Fehlerbeschreibung: Tritt das Problem nach einer Verdichtung auf? Ist nur ein Kanal betroffen? Fehlt die Werkzeugfortsetzung selbst oder nur ihre Darstellung? Daraus wird eine prüfbare Hypothese. Die Mindestregel lautet: Erst die betroffene Schicht benennen, dann dort messen und erst danach Einstellungen verändern.