OpenClaw schließt Bug zu gekürzten Custom-Model-Fenstern als Fehlalarm

Ein vermeintlicher OpenClaw-Bug zu isolierten Codex-Runtimes war nach einem Tag schon wieder erledigt. Laut GitHub-Issue #93765 wurde der Bericht am 16. Juni 2026 eröffnet und am 17. Juni zurückgezogen; nach Angaben des ursprünglichen Melders handelte es sich um einen Fehlalarm.

Für Betreiber ist der Vorgang trotzdem nützlich. Im Raum stand ein Szenario, das bei langen Agenten-Sessions teuer werden kann: Ein Custom-Modell mit großem Kontextfenster sollte in einer isolierten Codex-Umgebung mit den hinterlegten Metadaten laufen, wurde im Report aber wie ein unbekanntes Modell behandelt. Bestätigt wurde dieser Produktfehler am Ende nicht. Der Fall zeigt aber ziemlich sauber, wo du bei ähnlichen Symptomen zuerst nachsehen solltest.

Der Verdacht sah zunächst gefährlich aus

Laut dem GitHub-Issue ging es um ein benutzerdefiniertes OpenAI-Responses-Modell, das in OpenClaw mit sehr großem Kontextfenster konfiguriert war. Der Melder beschrieb, dass OpenClaw zwar die Modell-ID an thread/start und thread/resume weiterreiche, aber nicht die zugehörigen Katalogdaten für das isolierte CODEX_HOME.

Der Report nannte dazu zwei konkrete Beobachtungen: In der isolierten codex-home/config.toml fehlten laut Beschreibung sowohl ein Custom-Provider als auch model_catalog_json. Außerdem tauchte das konfigurierte Modell nach Darstellung des Melders nicht in models_cache.json auf. Die vermutete Folge war klar: Codex behandle das Modell als unbekannt und falle deshalb auf Default-Metadaten für unbekannte Modelle zurück.

Genau dort wird das Thema operativ relevant. Wenn ein Modell mit deutlich größerem Fenster konfiguriert ist, die isolierte Runtime dieses Wissen aber nicht sauber übernimmt, kann eine Session früher komprimiert werden als erwartet. Das betrifft nicht nur Komfort, sondern direkt Kosten, Laufzeitverhalten und die Stabilität längerer Arbeitskontexte.

Warum der Fehlalarm trotzdem lehrreich ist

Interessant war der Verdacht nicht deshalb, weil jemand vage ein Problem vermutete. Nach Angaben im Ticket war die Beweiskette ungewöhnlich konkret: Der Bericht verwies auf OpenClaw-Komponenten wie auth-bridge.ts und thread-lifecycle.ts und verband das mit der Fallback-Logik von Codex für unbekannte Modelle.

Genau das macht solche Fälle im Betrieb heikel. Wenn Modell-ID, Katalogwissen und Laufzeitverhalten auseinanderlaufen, sieht ein Fehlalarm schnell wie ein sauber eingegrenzter Runtime-Bug aus. Wer nur auf den Modellnamen schaut, kann leicht übersehen, dass das eigentliche Problem tiefer in der Übergabe von Metadaten liegen könnte.

Für Betreiber ist das die eigentliche Lehre aus dem Vorgang: Nicht die Konfiguration allein entscheidet, sondern der komplette Pfad bis zur isolierten Runtime. Erst wenn dort dieselben Modellinformationen ankommen, ist ein großes Kontextfenster mehr als nur ein Eintrag auf dem Papier.

Dann fiel der Fall wieder in sich zusammen

Im weiteren Verlauf drehte sich die Diskussion laut GitHub bereits um mögliche Reparaturrichtungen. Im Thread stand die Frage im Raum, ob ein schmaler Override für Fallback-Metadaten genügen würde oder ob eine größere Integration nötig wäre, die Provider-, Base-URL- und Auth-Informationen vollständig in den Codex-Katalog einbindet.

Dazu kam es nicht mehr. Am 17. Juni zog der ursprüngliche Melder den Bericht selbst zurück. Nach Angaben der GitHub-API steht das Ticket auf closed, der Schließungsgrund auf not_planned. Aus dem belegten Material ergibt sich damit kein bestätigter Produktfehler und auch kein angekündigter Fix.

Das ist mehr als eine Randnotiz. Gerade bei Runtime-Problemen rund um Kontextfenster und Modellkataloge wirken Symptome oft überzeugend, obwohl die Ursache am Ende woanders liegt. Der Fall taugt deshalb nicht als Bug-Bestätigung, aber sehr wohl als Reality-Check für eine Diagnose, die zunächst plausibel genug klang, um Zeit und Aufmerksamkeit zu binden.

Was du für ähnliche Fälle prüfen solltest

Wenn ein Custom-Modell in OpenClaw auffällig früh komprimiert oder verdichtet, lohnt es sich, drei Dinge strikt auseinanderzuhalten: die ausgewählte Modell-ID, die tatsächlich in der isolierten Umgebung verfügbaren Metadaten und das beobachtete Verhalten der laufenden Session.

Genau darin steckt der Wert dieses zurückgezogenen Reports. Wenn ein Modell laut Konfiguration ein sehr großes Fenster haben soll, reicht ein Blick in die Oberfläche oder in die Modellwahl nicht aus. Entscheidend ist, ob die isolierte Runtime dieses Wissen wirklich übernimmt und ob sich das später im Verhalten der Session wiederfindet.

Der Fall sagt deshalb etwas Wichtiges, obwohl er kein Bug war: Bei isolierten Codex-Runtimes zählt nicht nur, welches Modell du auswählst, sondern welches Modellwissen am Ende tatsächlich ankommt. Dort solltest du zuerst suchen, wenn lange Sessions früher als erwartet komprimiert werden.

Unterm Strich bleibt also keine neue OpenClaw-Störung, sondern ein brauchbares Diagnosemuster. Nach dem aktuellen Quellenstand lässt sich kein bestätigter Produktfehler ableiten. Sehr wohl ableiten lässt sich aber, worauf du bei ähnlichen Symptomen achten solltest: auf die vollständige Metadaten-Kette, nicht nur auf den Modellnamen.