OpenAI oauth (ChatGPT Plus) in pi runtime

[snow ledge]

Hi Krill, ich brauche einmal Hilfe bei der saubersten OpenClaw-Konfiguration für folgenden Sonderfall:
Ziel: Ich möchte ChatGPT Plus / OpenAI Codex OAuth nutzen, aber nicht die native Codex-Harness-Runtime. Die Agenten sollen weiter über OpenClaw Pi Default laufen.
Aktueller funktionierender Zustand:
Kopieren
agents.defaults.model.primary = openai-codex/gpt-5.5
agents.defaults.model.fallbacks = [openai-codex/gpt-5.4]

agents.defaults.models.openai-codex/gpt-5.5.agentRuntime.id = "pi"
agents.defaults.models.openai-codex/gpt-5.4.agentRuntime.id = "pi"
agents.defaults.models.openai-codex/gpt-5.4-mini.agentRuntime.id = "pi"

auth.order.openai = ["openai-codex:<my-oauth-profile>"]
plugins.entries.codex.enabled = false
"codex" is not in plugins.allow
openclaw status --usage zeigt damit korrekt:
Kopieren
Runtime: OpenClaw Pi Default
Usage: Codex
Problem: openclaw doctor warnt weiterhin, dass openai-codex/* Legacy-Refs seien und empfiehlt doctor --fix.
Wenn ich aber auf openai/* migriere, versucht OpenClaw bei Agent-Runs wieder den Codex-Harness zu verwenden:
Kopieren
Requested agent harness "codex" is not registered.
Das passiert, weil das Codex-Plugin bewusst deaktiviert ist — ich will ja gerade nicht in die native Codex-Runtime.
Frage: Was ist für diesen Use Case die empfohlene, stabile Konfiguration?
Konkret:
Soll ich openai-codex/* trotz Doctor-Warnung behalten, wenn ich Codex OAuth + Pi Runtime nutzen will?
Gibt es eine korrekte openai/-Konfiguration, die garantiert Pi Runtime nutzt, aber trotzdem über das openai-codex:<oauth-profile>-Auth-Profil/ChatGPT-Plus-Route läuft?
Sollte doctor --fix für diesen Fall vermieden werden, oder gibt es einen Preserve-/Compatibility-Pfad, den ich explizit aktivieren kann?
Ist es erwartetes Verhalten, dass Doctor openai-codex/ → openai/* rewritet und dabei Codex-Harness-Intent rekonstruiert?
Kurz: Ich suche die offiziell empfohlene Lösung für Codex OAuth billing/auth + OpenClaw Pi runtime, ohne aktiviertes Codex-Harness-Plugin.

[swift oak]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[ivory adder]

Ich prüfe das kurz gegen aktuelle Docs/Code, weil das genau die Sorte Config-Kante ist, bei der Raten weh tut. Ich melde mich gebündelt mit der belastbaren Variante.

[ivory adder]

Kurzfassung nach Code-/Docs-Check: Für Codex OAuth/ChatGPT-Plus-Billing + OpenClaw Pi Runtime ist openai-codex/* weiterhin die richtige Provider-Familie. Das ist in der aktuellen Source nicht grundsätzlich “legacy”; openai-codex ist der Provider, der auf den Codex-OAuth/ChatGPT-Backend-Pfad normalisiert. openai/* ist die normale OpenAI-API-Familie und sollte nicht als “Codex OAuth aber Pi” Ersatz benutzt werden.

Die robustere Config-Form wäre eher global/per-agent die Embedded-Harness-Policy zu setzen, nicht pro Modell über agentRuntime.id:

agents: {
  defaults: {
    model: {
      primary: "openai-codex/<dein-modell>",
      fallbacks: ["openai-codex/<fallback>"]
    },
    embeddedHarness: {
      runtime: "pi",
      fallback: "pi"
    }
  }

[ivory adder]

}

auth: {
  order: {
    "openai-codex": ["openai-codex:<dein-oauth-profile>"]
  }
}

plugins: {
  entries: {
    codex: { enabled: false }
  }
  // codex nicht in plugins.allow
}

[ivory adder]

Wichtig: auth.order.openai würde ich für diesen Use Case nicht verwenden. Das Auth-Profil gehört semantisch zu openai-codex, weil nur dieser Provider den Codex-OAuth-Transport/Usage-Pfad repräsentiert.

Zur Doctor-Warnung: Doctor warnt laut aktueller Doku/Tests vor alten models.providers.openai-codex-Transport-Overrides, die den eingebauten Codex-OAuth-Pfad shadowen können, und vor alten /models add-Metadata-Zeilen. Das ist etwas anderes als “openai-codex/* Modellrefs sind verboten”. Wenn deine Config unter models.providers.openai-codex noch api: "openai-responses", baseUrl: "https://api.openai.com/v1" oder alte inline model metadata stehen hat, würde ich eher diese Provider-Override-Reste entfernen/aufräumen, nicht die Modellrefs auf openai/* migrieren.

Wenn nach einer Migration Requested agent harness "codex" is not registered kommt, ist irgendwo noch Harness-Policy auf codex gepinnt: agents.defaults.embeddedHarness.runtime, ein agents.list[].embeddedHarness.runtime, OPENCLAW_AGENT_RUNTIME, oder eine bestehende Session-Pin/ACP-Bindung. Für Pi muss das pi sein oder die Session neu/resetet werden.

Für deinen konkreten Zustand: Ja, ich würde doctor --fix in diesem Sonderfall nicht blind laufen lassen, bevor klar ist, welche Diff Doctor anwenden will. Bitte einmal openclaw --version und am besten die relevante Doctor-Warnung/Diff posten; dann kann man unterscheiden, ob es nur stale Provider-Metadata ist oder ein echter Rewrite-Bug, der als GitHub-Issue taugt: https://github.com/openclaw/openclaw/issues

Docs dazu:
https://docs.openclaw.ai/help/faq
https://docs.openclaw.ai/gateway/doctor
https://docs.openclaw.ai/concepts/models

[snow ledge]

In OpenClaw 2026.5.12 zeigt config.schema.lookup agents.defaults.embeddedHarness, dass embeddedHarness legacy ist und von Runtime Selection ignoriert wird. Soll in dieser Version stattdessen weiterhin agents.defaults.models["openai-codex/<model>"].agentRuntime.id = "pi" genutzt werden?

[ivory adder]

Guter Catch. Ich prüfe das gegen den 2026.5.12-Codepfad, weil meine vorige Antwort offenbar auf aktuellerem Schema-Verhalten gelandet ist.

[ivory adder]

Ja, du hast recht: In 2026.5.12 ist agents.defaults.embeddedHarness legacy und wird von der Runtime Selection ignoriert. Meine vorige Empfehlung mit embeddedHarness.runtime: "pi" passt nicht zu 2026.5.12. Danke fürs Gegenprüfen.

Für diese Version ist die saubere Form:

agents: {
  defaults: {
    model: {
      primary: "openai/gpt-5.5",
      fallbacks: ["openai/gpt-5.4"]
    },
    models: {
      "openai/gpt-5.5": { agentRuntime: { id: "pi" } },
      "openai/gpt-5.4": { agentRuntime: { id: "pi" } },
      "openai/gpt-5.4-mini": { agentRuntime: { id: "pi" } }
    }

[ivory adder]

  }
}

Also: nicht agents.defaults.models["openai-codex/<model>"].agentRuntime.id = "pi" als Zielzustand, sondern canonical openai/<model> plus model/provider-scoped agentRuntime.id = "pi".

Der wichtige 2026.5.12-Mechanismus ist: openai/* wählt auf offizieller OpenAI-Route standardmäßig Codex-Harness, außer du setzt provider/model-scoped agentRuntime.id: "pi". Für PI + Codex OAuth kann ein ausgewähltes openai-codex:... Auth-Profil dann intern durch den PI-Codex-Auth-Transport geroutet werden. Der Codepfad dafür heißt sinngemäß shouldRouteOpenAIPiThroughCodexAuthProvider.

Wenn du es providerweit willst, sollte auch diese Form gehen:

models: {
  providers: {
    openai: {
      agentRuntime: { id: "pi" }

[ivory adder]

    }
  }
}

Ich würde für deinen Sonderfall aber die model-scoped Variante bevorzugen, weil sie enger ist und weniger Nebenwirkungen auf andere OpenAI-Nutzung hat.

doctor --fix in 2026.5.12 rewritet openai-codex/gpt-* zu openai/gpt-*. Wenn bei dir schon agentRuntime.id: "pi" auf dem alten Modell-Key steht, sollte Doctor diese per-model settings auf den canonical openai/* Key mitnehmen/preservieren. Wenn Doctor daraus trotzdem codex macht oder danach Requested agent harness "codex" is not registered entsteht, dann ist das sehr wahrscheinlich ein Doctor-Rewrite-Bug und gehört als Issue rein: https://github.com/openclaw/openclaw/issues

Docs:
https://docs.openclaw.ai/concepts/agent-runtimes
https://docs.openclaw.ai/providers/openai
https://docs.openclaw.ai/gateway/doctor

[snow ledge]

leider funktioniert das nicht: Backup ist sauber erstellt:
/Users/daniel/.openclaw/openclaw.json.bak-openai-pi-codexoauth-retry-20260517-160306
Config ist jetzt auf Krills zweiten Vorschlag gesetzt:
primary: openai/gpt-5.5
Fallback: openai/gpt-5.4
model-scoped PI-Pins:
openai/gpt-5.5 → agentRuntime.id = "pi"
openai/gpt-5.4 → agentRuntime.id = "pi"
openai/gpt-5.4-mini → agentRuntime.id = "pi"
auth.order jetzt:
"openai-codex": ["openai-codex:[e-mail]"]
agents.defaults.agentRuntime entfernt
Codex-Plugin bleibt disabled
openclaw config validate ist OK
Lokaler Runtime-Policy-Check resolved für alle drei Modelle korrekt zu pi
Wichtig: Der Gateway hat den nötigen Restart gerade noch deferred, weil noch aktive Runs/Replies laufen:
Kopieren
config change requires gateway restart ... restart still deferred
Ich lasse diesen Turn jetzt enden, damit der Restart durchlaufen kann. Danach prüfe ich Status/Logs nochmal.

⚠️ Agent failed before reply: Requested agent harness "codex" is not registered.
Logs: openclaw logs --follow

[ivory adder]

Das Fehlerbild passt nicht mehr zu “Policy resolved lokal zu pi”, sondern zu einem von zwei Dingen:

1. Der laufende Gateway hat die neue Config noch nicht geladen. Deine Zeile restart still deferred ist hier entscheidend. Solange der Restart wegen aktiver Runs blockiert ist, läuft der Agent weiter mit der alten Runtime-Auswahl und kann weiterhin codex anfordern.
2. Der konkrete Run nutzt nicht den Config-Pfad, den du lokal geprüft hast, z.B. anderer Agent, anderer Session-Key, anderer tatsächlich selektierter Model-Ref/Fallback.

Nächster sinnvoller Schritt, bevor wir weiter an der Config drehen: wirklich alle aktiven Runs enden lassen und dann den Gateway einmal hart neu starten:

openclaw gateway restart
openclaw status --all
openclaw logs --follow

Wenn danach weiterhin Requested agent harness "codex" is not registered kommt, setz zusätzlich providerweit den PI-Pin. Das ist weniger elegant, aber in 2026.5.12 der stärkere Hammer, weil resolveModelRuntimePolicy nach model-scoped Pins auch models.providers.openai.agentRuntime prüft:

[ivory adder]

models: {
  providers: {
    openai: {
      agentRuntime: { id: "pi" }
    }
  }
}

Die model-scoped Pins können bleiben. Damit ist jeder openai/* Agent-Run im PI-Pfad, auch wenn irgendein Fallback/Session-Pfad nicht exakt den erwarteten model key trifft.

Wichtig: Nicht wieder auf openai-codex/* zurückspringen, wenn du auf 2026.5.12 bleiben willst. Für 2026.5.12 ist der canonical Model-Ref openai/*; openai-codex ist hier vor allem Auth-/Transport-Route. Wenn Provider-wide openai.agentRuntime.id = "pi" nach echtem Gateway-Restart immer noch codex anfordert, dann ist das kein normaler Config-Fall mehr, sondern sehr wahrscheinlich ein Runtime-Policy/Gateway-reload Bug. Dann wären die relevanten Auszüge aus openclaw status --all und die paar Logzeilen direkt vor Requested agent harness "codex" Gold wert.

[snow ledge]

wie baue ich den abschnitt in die json ein ?

"models": {
"openrouter-argon/deepseek/deepseek-v3.2": {
"alias": "ds-v3-ar"
},
"openrouter-argon/xiaomi/mimo-v2-flash": {
"alias": "mimo-ar"

[ivory adder]

In deiner openclaw.json gibt es wahrscheinlich schon einen Block agents.defaults.models. Dort musst du die Einträge zusammenführen, nicht einen zweiten models-Block daneben anlegen.

Beispiel mit deinen Alias-Einträgen plus den PI-Pins:

{
  "agents": {
    "defaults": {
      "model": {
        "primary": "openai/gpt-5.5",
        "fallbacks": ["openai/gpt-5.4"]
      },
      "models": {
        "openai/gpt-5.5": {
          "agentRuntime": { "id": "pi" }
        },

[ivory adder]

        "openai/gpt-5.4": {
          "agentRuntime": { "id": "pi" }
        },
        "openai/gpt-5.4-mini": {
          "agentRuntime": { "id": "pi" }
        },
        "openrouter-argon/deepseek/deepseek-v3.2": {
          "alias": "ds-v3-ar"
        },
        "openrouter-argon/xiaomi/mimo-v2-flash": {
          "alias": "mimo-ar"
        }
      }
    }
  }

[ivory adder]

}

Wenn du zusätzlich den providerweiten OpenAI-PI-Hammer setzen willst, der kommt nicht in agents.defaults.models, sondern auf Top-Level unter models.providers:

{
  "models": {
    "providers": {
      "openai": {
        "agentRuntime": { "id": "pi" }
      }
    }
  }
}

[ivory adder]

Falls models.providers bei dir schon existiert, nur den openai-Eintrag dort ergänzen. Danach:

openclaw config validate
openclaw gateway restart

[snow ledge]

wird das in einer aktuellen version besser gelöst ? (bin nur auf stable versionen)

[ivory adder]

Kurz: ja, der aktuelle Stand sieht wieder sauberer aus, aber wenn du nur Stable nutzt, bist du aktuell vermutlich noch auf dem ungünstigen Zwischenstand 2026.5.12.

Ich habe gerade gegen den aktuellen Docs-/Code-Stand geschaut: Dort ist die Route wieder klarer getrennt:

• openai/* = direkte OpenAI/API-Route
• openai-codex/* = Codex/ChatGPT-OAuth durch PI
• openai/* + embeddedHarness.runtime: "codex" = native Codex app-server Harness

Das ist genau die Form, die für deinen Use Case eigentlich viel weniger verrenkt ist: Codex OAuth + PI Runtime = openai-codex/gpt-..., ohne diese provider/model agentRuntime.id = "pi"-Pins.

Aber: In den Tags, die ich sehe, ist die neuere Linie gerade nur als Beta vorhanden; die letzte Stable ist v2026.5.12. Wenn du strikt Stable bleibst, würde ich entweder:

1. bei deiner ursprünglich funktionierenden openai-codex/*-Config bleiben und die Doctor-Warnung als 2026.5.12-Migrationskante behandeln, oder
2. den 2026.5.12-Workaround mit openai/* + provider/model agentRuntime.id: "pi" nutzen, wenn er nach sauberem Gateway-Restart wirklich greift.

Ich würde in deinem Fall ehrlich eher nicht weiter Zeit in 2026.5.12 Doctor-Fix-Migration investieren, wenn dein funktionierender Zielzustand openai-codex/* + PI ist. Das scheint im aktuellen Stand wieder der dokumentierte saubere Pfad zu sein. Sobald die nächste Stable raus ist, sollte das deutlich weniger hakelig sein.