OpenClaw kann Provider-Schlüssel an den falschen Endpunkt senden

Eine Gemini-Anfrage landet bei api.openai.com/v1/responses — samt Schlüssel. Laut GitHub-Issue #126529 vom 20. August 2026 passiert genau das in Stable v2026.7.1-2: Ein manuell ergänzter Modelleintrag ohne api- und baseUrl-Angabe bricht nicht mit einem Konfigurationsfehler ab, sondern läuft still über eine fremde Provider-Route. Der Eintrag war unvollständig. Der Request ging trotzdem raus.

Das Issue hält fest, dass jede Anfrage für dieses Modell mit api=openai-responses an OpenAIs Endpunkt ging. Der Provider-Schlüssel reiste mit. Er gehörte dort nicht hin.

Was beim Routing schiefgeht

Der Mechanismus dahinter ist ein Fallback, der zu viel tut. Fehlen bei einem Modell die Felder für API-Typ und Basis-URL, wählt OpenClaw laut Issue #126529 weder eine passende Default-Route noch verweigert es den Dienst, sondern setzt eine generische Request-Form ein. Aus einem fehlenden Konfigurationswert wird so kein Abbruch, sondern eine Zuweisung — und die zeigte im dokumentierten Fall auf einen Host, mit dem das konfigurierte Modell nichts zu tun hat.

Das ältere Schwester-Issue #85042, dessen Kommentare zuletzt am 5. August 2026 aktualisiert wurden, bestätigt denselben Pfad auf aktuellem Main: Wer ein nicht katalogisiertes Provider-Modell nur mit id und name konfiguriert und dann auflösen lässt, bekommt vom Fallback openai-responses materialisiert — ohne routeneigene Basis-URL. Das ist kein Sonderfall einer einzelnen Anbieterroute. Es ist die dokumentierte Auflösungslogik für unvollständige Einträge.

Die Fehlermeldung führt in die Irre

Was ankommt, ist ein HTTP 401 mit dem Hinweis, das Provider-Token sei womöglich abgelaufen. So steht es in Issue #126529 dokumentiert. Abgelaufen ist der Schlüssel aber nicht — er wurde nur an einem Endpunkt vorgelegt, der ihn nicht kennt.

Diese Verwechslung lenkt die Diagnose in die falsche Richtung: Man rotiert Tokens, prüft Ablaufdaten oder legt neue Credentials an, während die Ursache in einer Konfiguration liegt, die gar keinen Fehler geworfen hat. Und jeder weitere Testlauf über dieselbe Route schickt den Schlüssel erneut an den falschen Host.

Diagnose und Workaround

Das Issue nennt einen bestätigten Fix: die Provider-Felder für API-Typ und Basis-URL zusätzlich auf Provider-Ebene explizit setzen, statt sich auf Vererbung oder Defaults zu verlassen. Eigene Modelleinträge gehören vor dem produktiven Einsatz auf ihren tatsächlichen Zielhost geprüft, denn ein erfolgreich abgesetzter Request belegt bei diesem Fehlerbild keine korrekte Route.

Ein 401 nach einer Modelländerung verdient deshalb erst einen Blick auf die Route und dann auf das Token.

Wo das im Betrieb wehtut

Issue #126529 dokumentiert die Reproduktion in zwei Kontexten: bei einem direkten Agentenlauf und bei einem geplanten Cronjob, in dem dasselbe Modell als Standard eines Agenten hinterlegt war. Der zweite Fall ist der unangenehmere. Ein interaktiver Lauf zeigt den 401 sofort auf dem Bildschirm; ein Cronjob wiederholt ihn nach Zeitplan, ohne dass jemand hinsieht.

Fail-open-Routing ist hier das eigentliche Problem. Ein System, das bei unvollständiger Provider-Konfiguration abbricht, verliert einen Lauf. Eines, das stattdessen rät, verschickt ein Geheimnis an eine Adresse, die niemand ausgewählt hat.

Ob und in welcher Version das Verhalten inzwischen korrigiert wurde, geht aus den beiden Issues nicht hervor. Die Mindestregel bis dahin: Jeder handgeschriebene Modelleintrag bekommt API-Typ und Basis-URL explizit — und einen Testlauf, bei dem jemand den Zielhost tatsächlich anschaut. Besonders bei den Modellen, die sonst nur der Cron aufruft.