OpenClaw-PR schlägt besseren Recovery-Hinweis für Legacy-Codex-Modelle vor

Ein Gateway meldet ein unbekanntes Modell. Der naheliegende Reflex: Provider-Eintrag ergänzen, neu starten, weiterarbeiten. Im gemeldeten Legacy-Codex-Fall führte genau dieser Schritt in die nächste Validierungsstörung.

Das GitHub-Issue #100066 und der vorgeschlagene Pull Request #100161 beschreiben mehr als eine Textkorrektur, denn die Recovery-Anweisung soll bei bestimmten openai-codex/*-Fehlern nicht länger in ein Custom-Provider-Overlay weisen. Ob und in welcher Version der PR ausgeliefert wurde, muss vor einer produktiven Änderung gegen die aktuelle Release-Dokumentation geprüft werden.

Das Fehlerbild: Eine Reparatur erzeugt den nächsten Fehler

Im Issue wird ein Upgrade-Fall mit openai-codex/gpt-5.4 beschrieben. Das Modell war in agents.defaults.models referenziert, zur Laufzeit erschien dennoch ein FailoverError. Die damalige Recovery-Anweisung legte nahe, unter models.providers["openai-codex"].models[] einen Eintrag zu ergänzen.

Danach scheiterte der Gateway-Start mit einer Validierungsfehlermeldung zu models.providers.openai-codex.baseUrl.

Die Diagnose hätte beim fehlenden Legacy-Codex-Zugang ansetzen müssen. Stattdessen führte der Hinweis den Betreiber in das Schema eines Custom Providers, dessen unvollständiges Overlay der Validator anschließend zurückwies. Aus einem Auth- oder Routing-Problem wurde so ein Crash-Loop-Risiko.

Was der PR tatsächlich vorschlägt

Der Pull Request beschreibt keine neue Konfigurationsform für openai-codex. Sein Zweck ist enger: Der Recovery-Hinweis soll den betroffenen Pfad als Legacy-Codex-Fall erkennen und auf Authentifizierung, Migration und Modellstatus verweisen.

Für das im PR #100161 dokumentierte Szenario nennt die Änderung openclaw doctor --fix, openclaw models status und bei fehlendem Profil openclaw models auth login --provider openai. Das ist kein pauschaler Reparaturpfad. Vor dem Einsatz auf der aktuellen stabilen Version sollten Betreiber Syntax und erwartete Ausgabe mit ihrer eigenen Umgebung abgleichen.

Im beschriebenen Upgrade-Fall fehlte ein Provider-Profil. Ohne OAuth-Registrierung standen die zugehörigen Modelle zur Laufzeit nicht bereit; ein zusätzliches Provider-Overlay griff deshalb an der falschen Stelle an.

Ein enger Prüfpfad für den Betrieb

Gerade in Docker-Setups sieht ein Startfehler schnell wie ein allgemeines Konfigurationsproblem aus, zumal der gemeldete Fall zusätzlich einen Custom Provider unter models.mode: "merge" enthielt. Diese Kombination verlangt eine feste Reihenfolge:

1. Modellstatus und vorhandenes Auth-Profil prüfen.
2. Migrationshinweise ausführen und die Ausgabe dokumentieren.
3. Danach die Provider-Konfiguration untersuchen.
4. Nach jeder Änderung Gateway-Start und Modellauflösung separat verifizieren.

Keine Änderung auf Verdacht.

Eine Recovery-Anweisung ist Teil des Produkts. Sie muss den Betreiber aus dem Fehler führen, ohne dabei eine zweite Fehlkonfiguration nahezulegen. Weitere Betriebsfälle rund um Gateway, Modelle und Recovery ordnet der Bereich OpenClaw ein; wie die Gateway-Konfiguration in openclaw.json selbst aufgebaut ist, zeigt der Beitrag zur JSON5-Gateway-Konfiguration.

Was der Testfall abdeckt

Der PR verweist auf einen isolierten CLI-Test: Ein openai-codex/gpt-5.4-Eintrag war in den Agent-Defaults vorhanden, ein Provider-Overlay fehlte. Nach der Änderung enthielt die Ausgabe laut PR keinen Hinweis mehr auf die Registrierung unter models.providers["openai-codex"].models[]; stattdessen erschien ein Migrations- und Auth-Hinweis, und ein Regressionstest sollte diesen Pfad absichern.

Das deckt genau diesen Fehlerweg ab. Bei Upgrade-, Container- und Merge-Setups bleiben Auth-Status, Konfiguration und Startverhalten getrennte Prüfungen.

Fazit: Config-Vorschläge erst gegen den Fehlerweg prüfen

Bei openai-codex/*-Fehlern sollte ein Hinweis in Richtung Custom-Provider-Overlay Misstrauen auslösen, solange Legacy- und OAuth-Status ungeklärt sind.

Die praktische Regel lautet: Auth prüfen, Migration prüfen, Modellstatus prüfen, dann erst an der Provider-Struktur arbeiten. Der kontrollierte Recovery-Nachweis zählt: Das Gateway startet wieder sauber und löst das erwartete Modell auf.