Zum Hauptinhalt springen

Documentation Index

Fetch the complete documentation index at: https://docs2.openclaw.ai/llms.txt

Use this file to discover all available pages before exploring further.

Das gebündelte codex-Plugin lässt OpenClaw eingebettete OpenAI-Agent-Durchläufe über den Codex-App-Server statt über den integrierten PI-Harness ausführen. Verwenden Sie den Codex-Harness, wenn Codex die Low-Level-Agent-Sitzung übernehmen soll: native Thread-Wiederaufnahme, native Tool-Fortsetzung, native Compaction und App-Server-Ausführung. OpenClaw übernimmt weiterhin Chat-Kanäle, Sitzungsdateien, Modellauswahl, dynamische OpenClaw-Tools, Genehmigungen, Medienauslieferung und die sichtbare Transkriptspiegelung. Die normale Einrichtung verwendet kanonische OpenAI-Modellreferenzen wie openai/gpt-5.5. Konfigurieren Sie keine openai-codex/gpt-*-Modellreferenzen. Legen Sie die OpenAI-Agent-Auth-Reihenfolge unter auth.order.openai ab; ältere openai-codex:*-Profile und auth.order.openai-codex-Einträge werden für bestehende Installationen weiterhin unterstützt. OpenClaw startet Codex-App-Server-Threads mit dem nativen Code-Modus von Codex und aktiviertem Nur-Code-Modus. Dadurch bleiben zurückgestellte/durchsuchbare dynamische OpenClaw-Tools innerhalb der eigenen Codeausführungs- und Tool-Suchoberfläche von Codex, statt oberhalb von Codex einen PI-artigen Tool-Such-Wrapper hinzuzufügen. Für die umfassendere Aufteilung von Modell, Provider und Laufzeitumgebung beginnen Sie mit Agent-Laufzeitumgebungen. Die Kurzfassung lautet: openai/gpt-5.5 ist die Modellreferenz, codex ist die Laufzeitumgebung, und Telegram, Discord, Slack oder ein anderer Kanal bleibt die Kommunikationsoberfläche.

Anforderungen

  • OpenClaw mit verfügbarem gebündeltem codex-Plugin.
  • Wenn Ihre Konfiguration plugins.allow verwendet, schließen Sie codex ein.
  • Codex-App-Server 0.125.0 oder neuer. Das gebündelte Plugin verwaltet standardmäßig eine kompatible Codex-App-Server-Binärdatei, daher wirken sich lokale codex-Befehle in PATH nicht auf den normalen Harness-Start aus.
  • Codex-Authentifizierung verfügbar über openclaw models auth login --provider openai-codex, ein App-Server-Konto im Codex-Home des Agenten oder ein explizites Codex-API-Schlüssel-Auth-Profil.
Informationen zu Auth-Priorität, Umgebungsisolation, benutzerdefinierten App-Server-Befehlen, Modellerkennung und allen Konfigurationsfeldern finden Sie in der Codex-Harness-Referenz.

Schnellstart

Die meisten Benutzer, die Codex in OpenClaw verwenden möchten, wählen diesen Pfad: Melden Sie sich mit einem ChatGPT/Codex-Abonnement an, aktivieren Sie das gebündelte codex-Plugin und verwenden Sie eine kanonische openai/gpt-*-Modellreferenz. Mit Codex OAuth anmelden:
openclaw models auth login --provider openai-codex
Aktivieren Sie das gebündelte codex-Plugin und wählen Sie ein OpenAI-Agent-Modell aus:
{
  plugins: {
    entries: {
      codex: {
        enabled: true,
      },
    },
  },
  agents: {
    defaults: {
      model: "openai/gpt-5.5",
    },
  },
}
Wenn Ihre Konfiguration plugins.allow verwendet, fügen Sie dort ebenfalls codex hinzu:
{
  plugins: {
    allow: ["codex"],
    entries: {
      codex: {
        enabled: true,
      },
    },
  },
}
Starten Sie den Gateway neu, nachdem Sie die Plugin-Konfiguration geändert haben. Wenn ein bestehender Chat bereits eine Sitzung hat, verwenden Sie /new oder /reset, bevor Sie Laufzeitänderungen testen, damit der nächste Durchlauf den Harness aus der aktuellen Konfiguration auflöst.

Konfiguration

Die Schnellstart-Konfiguration ist die minimal funktionsfähige Codex-Harness-Konfiguration. Legen Sie Codex-Harness-Optionen in der OpenClaw-Konfiguration fest und verwenden Sie die CLI nur für die Codex-Authentifizierung:
BedarfFestlegenWo
Harness aktivierenplugins.entries.codex.enabled: trueOpenClaw-Konfiguration
Plugin-Installation mit Allowlist beibehaltencodex in plugins.allow einschließenOpenClaw-Konfiguration
OpenAI-Agent-Durchläufe über Codex leitenagents.defaults.model oder agents.list[].model als openai/gpt-*OpenClaw-Agent-Konfiguration
Mit Codex OAuth anmeldenopenclaw models auth login --provider openai-codexCLI-Auth-Profil
API-Schlüssel-Backup für Codex-Läufe hinzufügenopenai:*-API-Schlüsselprofil, nach Abonnement-Auth in auth.order.openai aufgeführtCLI-Auth-Profil + OpenClaw-Konfiguration
Geschlossen fehlschlagen, wenn Codex nicht verfügbar istProvider oder Modell agentRuntime.id: "codex"OpenClaw-Modell/Provider-Konfiguration
Direkten OpenAI-API-Verkehr verwendenProvider oder Modell agentRuntime.id: "pi" mit normaler OpenAI-AuthOpenClaw-Modell/Provider-Konfiguration
App-Server-Verhalten abstimmenplugins.entries.codex.config.appServer.*Codex-Plugin-Konfiguration
Native Codex-Plugin-Apps aktivierenplugins.entries.codex.config.codexPlugins.*Codex-Plugin-Konfiguration
Codex Computer Use aktivierenplugins.entries.codex.config.computerUse.*Codex-Plugin-Konfiguration
Verwenden Sie openai/gpt-*-Modellreferenzen für Codex-gestützte OpenAI-Agent-Durchläufe. Bevorzugen Sie auth.order.openai für eine Reihenfolge mit Abonnement zuerst und API-Schlüssel als Backup. Bestehende openai-codex:*-Auth-Profile und auth.order.openai-codex bleiben gültig, aber schreiben Sie keine neuen openai-codex/gpt-*-Modellreferenzen.
{
  auth: {
    order: {
      openai: ["openai-codex:user@example.com", "openai:api-key-backup"],
    },
  },
}
In dieser Form laufen beide Profile für openai/gpt-*-Agent-Durchläufe weiterhin über Codex. Der API-Schlüssel ist nur ein Auth-Fallback, keine Aufforderung, zu PI oder einfachen OpenAI Responses zu wechseln. Der Rest dieser Seite behandelt gängige Varianten, zwischen denen Benutzer wählen müssen: Bereitstellungsform, Fail-closed-Routing, Guardian-Genehmigungsrichtlinie, native Codex-Plugins und Computer Use. Die vollständigen Optionslisten, Standardwerte, Enums, Erkennung, Umgebungsisolation, Timeouts und App-Server-Transportfelder finden Sie in der Codex-Harness-Referenz.

Codex-Laufzeitumgebung verifizieren

Verwenden Sie /status in dem Chat, in dem Sie Codex erwarten. Ein Codex-gestützter OpenAI-Agent-Durchlauf zeigt:
Runtime: OpenAI Codex
Prüfen Sie anschließend den Codex-App-Server-Status:
/codex status
/codex models
/codex status meldet App-Server-Konnektivität, Konto, Ratelimits, MCP-Server und Skills. /codex models listet den Live-Codex-App-Server-Katalog für den Harness und das Konto auf. Wenn /status unerwartet ist, siehe Fehlerbehebung.

Routing und Modellauswahl

Halten Sie Provider-Referenzen und Laufzeitrichtlinien getrennt:
  • Verwenden Sie openai/gpt-* für OpenAI-Agent-Durchläufe über Codex.
  • Verwenden Sie openai-codex/gpt-* nicht in der Konfiguration. Führen Sie openclaw doctor --fix aus, um Legacy-Referenzen und veraltete Sitzungsrouten-Pins zu reparieren.
  • agentRuntime.id: "codex" ist für den normalen OpenAI-Automodus optional, aber nützlich, wenn eine Bereitstellung geschlossen fehlschlagen soll, falls Codex nicht verfügbar ist.
  • agentRuntime.id: "pi" schaltet einen Provider oder ein Modell auf direktes PI-Verhalten um, wenn dies beabsichtigt ist.
  • /codex ... steuert native Codex-App-Server-Unterhaltungen aus dem Chat.
  • ACP/acpx ist ein separater externer Harness-Pfad. Verwenden Sie ihn nur, wenn der Benutzer ACP/acpx oder einen externen Harness-Adapter anfordert.
Gängiges Befehls-Routing:
BenutzerabsichtVerwenden
Aktuellen Chat anhängen/codex bind [--cwd <path>]
Bestehenden Codex-Thread fortsetzen/codex resume <thread-id>
Codex-Threads auflisten oder filtern/codex threads [filter]
Nur Codex-Feedback senden/codex diagnostics [note]
Eine ACP/acpx-Aufgabe startenACP/acpx-Sitzungsbefehle, nicht /codex
AnwendungsfallKonfigurierenVerifizierenHinweise
ChatGPT/Codex-Abonnement mit nativer Codex-Laufzeitumgebungopenai/gpt-* plus aktiviertes codex-Plugin/status zeigt Runtime: OpenAI CodexEmpfohlener Pfad
Geschlossen fehlschlagen, wenn Codex nicht verfügbar istProvider oder Modell agentRuntime.id: "codex"Durchlauf schlägt statt PI-Fallback fehlFür reine Codex-Bereitstellungen verwenden
Direkter OpenAI-API-Schlüssel-Verkehr über PIProvider oder Modell agentRuntime.id: "pi" und normale OpenAI-Auth/status zeigt PI-LaufzeitumgebungNur verwenden, wenn PI beabsichtigt ist
Legacy-Konfigurationopenai-codex/gpt-*openclaw doctor --fix schreibt sie umNeue Konfiguration nicht so schreiben
ACP/acpx-Codex-AdapterACP sessions_spawn({ runtime: "acp" })ACP-Aufgaben/SitzungsstatusGetrennt vom nativen Codex-Harness
agents.defaults.imageModel folgt derselben Präfixaufteilung. Verwenden Sie openai/gpt-* für die normale OpenAI-Route und codex/gpt-* nur, wenn Bildverständnis über einen begrenzten Codex-App-Server-Durchlauf laufen soll. Verwenden Sie nicht openai-codex/gpt-*; doctor schreibt dieses Legacy-Präfix zu openai/gpt-* um.

Bereitstellungsmuster

Einfache Codex-Bereitstellung

Verwenden Sie die Schnellstart-Konfiguration, wenn alle OpenAI-Agent-Durchläufe standardmäßig Codex verwenden sollen.
{
  plugins: {
    entries: {
      codex: {
        enabled: true,
      },
    },
  },
  agents: {
    defaults: {
      model: "openai/gpt-5.5",
    },
  },
}

Gemischte Provider-Bereitstellung

Diese Form behält Claude als Standard-Agent bei und fügt einen benannten Codex-Agenten hinzu:
{
  plugins: {
    entries: {
      codex: {
        enabled: true,
      },
    },
  },
  agents: {
    defaults: {
      model: "anthropic/claude-opus-4-6",
    },
    list: [
      {
        id: "main",
        default: true,
        model: "anthropic/claude-opus-4-6",
      },
      {
        id: "codex",
        name: "Codex",
        model: "openai/gpt-5.5",
      },
    ],
  },
}
Mit dieser Konfiguration verwendet der main-Agent seinen normalen Provider-Pfad und der codex-Agent den Codex-App-Server.

Fail-closed-Codex-Bereitstellung

Für OpenAI-Agent-Durchläufe wird openai/gpt-* bereits zu Codex aufgelöst, wenn das gebündelte Plugin verfügbar ist. Fügen Sie eine explizite Laufzeitrichtlinie hinzu, wenn Sie eine schriftliche Fail-closed-Regel wünschen:
{
  models: {
    providers: {
      openai: {
        agentRuntime: {
          id: "codex",
        },
      },
    },
  },
  agents: {
    defaults: {
      model: "openai/gpt-5.5",
    },
  },
  plugins: {
    entries: {
      codex: {
        enabled: true,
      },
    },
  },
}
Wenn Codex erzwungen wird, schlägt OpenClaw früh fehl, falls das Codex-Plugin deaktiviert ist, der App-Server zu alt ist oder der App-Server nicht starten kann.

App-Server-Richtlinie

Standardmäßig startet das Plugin die von OpenClaw verwaltete Codex-Binärdatei lokal mit stdio-Transport. Legen Sie appServer.command nur fest, wenn Sie absichtlich eine andere ausführbare Datei ausführen möchten. Verwenden Sie WebSocket-Transport nur, wenn bereits anderswo ein App-Server läuft:
{
  plugins: {
    entries: {
      codex: {
        enabled: true,
        config: {
          appServer: {
            transport: "websocket",
            url: "ws://gateway-host:39175",
            authToken: "${CODEX_APP_SERVER_TOKEN}",
          },
        },
      },
    },
  },
}
Lokale stdio-App-Server-Sitzungen verwenden standardmäßig die vertrauenswürdige Haltung des lokalen Operators: approvalPolicy: "never", approvalsReviewer: "user" und sandbox: "danger-full-access". Wenn lokale Codex-Anforderungen diese implizite YOLO-Haltung nicht zulassen, wählt OpenClaw stattdessen zulässige Guardian-Berechtigungen aus. Wenn für die Sitzung eine OpenClaw-Sandbox aktiv ist, schränkt OpenClaw Codex danger-full-access auf Codex workspace-write ein, damit native Codex-Code-Mode-Turns innerhalb des Sandbox-Workspace bleiben. Verwenden Sie den Guardian-Modus, wenn Sie native automatische Codex-Reviews vor Sandbox-Ausbrüchen oder zusätzlichen Berechtigungen wünschen:
{
  plugins: {
    entries: {
      codex: {
        enabled: true,
        config: {
          appServer: {
            mode: "guardian",
            serviceTier: "priority",
          },
        },
      },
    },
  },
}
Der Guardian-Modus wird zu Codex-App-Server-Genehmigungen erweitert, in der Regel approvalPolicy: "on-request", approvalsReviewer: "auto_review" und sandbox: "workspace-write", wenn die lokalen Anforderungen diese Werte zulassen. Informationen zu jedem App-Server-Feld, zur Authentifizierungsreihenfolge, Umgebungsisolation, Discovery und zum Timeout-Verhalten finden Sie in der Codex-Harness-Referenz.

Befehle und Diagnose

Das gebündelte Plugin registriert /codex als Slash-Befehl in jedem Kanal, der OpenClaw-Textbefehle unterstützt. Häufige Formen:
  • /codex status prüft App-Server-Konnektivität, Modelle, Konto, Ratenlimits, MCP-Server und Skills.
  • /codex models listet Live-Modelle des Codex-App-Servers auf.
  • /codex threads [filter] listet aktuelle Threads des Codex-App-Servers auf.
  • /codex resume <thread-id> hängt die aktuelle OpenClaw-Sitzung an einen vorhandenen Codex-Thread an.
  • /codex compact fordert den Codex-App-Server auf, den angehängten Thread zu verdichten.
  • /codex review startet eine native Codex-Review für den angehängten Thread.
  • /codex diagnostics [note] fragt nach, bevor Codex-Feedback für den angehängten Thread gesendet wird.
  • /codex account zeigt Konto- und Ratenlimitstatus an.
  • /codex mcp listet den Status der MCP-Server des Codex-App-Servers auf.
  • /codex skills listet Skills des Codex-App-Servers auf.
Beginnen Sie bei den meisten Support-Berichten mit /diagnostics [note] in der Unterhaltung, in der der Fehler aufgetreten ist. Dadurch wird ein Gateway-Diagnosebericht erstellt und bei Codex-Harness-Sitzungen eine Genehmigung zum Senden des relevanten Codex-Feedback-Bundles angefordert. Informationen zum Datenschutzmodell und zum Verhalten in Gruppenchats finden Sie unter Diagnoseexport. Verwenden Sie /codex diagnostics [note] nur, wenn Sie gezielt den Codex-Feedback-Upload für den aktuell angehängten Thread ohne das vollständige Gateway-Diagnosebundle wünschen.

Codex-Threads lokal untersuchen

Der schnellste Weg, einen fehlerhaften Codex-Lauf zu untersuchen, besteht oft darin, den nativen Codex-Thread direkt zu öffnen:
codex resume <thread-id>
Rufen Sie die Thread-ID aus der abgeschlossenen /diagnostics-Antwort, /codex binding oder /codex threads [filter] ab. Informationen zu Upload-Mechanik und Diagnosegrenzen auf Runtime-Ebene finden Sie unter Codex-Harness-Runtime. Die Authentifizierung wird in dieser Reihenfolge ausgewählt:
  1. Geordnete OpenAI-Auth-Profile für den Agenten, vorzugsweise unter auth.order.openai. Vorhandene openai-codex:*-Profil-IDs bleiben gültig.
  2. Das vorhandene Konto des App-Servers im Codex-Home dieses Agenten.
  3. Nur für lokale stdio-App-Server-Starts: CODEX_API_KEY, dann OPENAI_API_KEY, wenn kein App-Server-Konto vorhanden ist und OpenAI-Auth weiterhin erforderlich ist.
Wenn OpenClaw ein Codex-Auth-Profil im Stil eines ChatGPT-Abonnements erkennt, entfernt es CODEX_API_KEY und OPENAI_API_KEY aus dem gestarteten Codex-Kindprozess. Dadurch bleiben API-Schlüssel auf Gateway-Ebene für Embeddings oder direkte OpenAI-Modelle verfügbar, ohne dass native Codex-App-Server-Turns versehentlich über die API abgerechnet werden. Explizite Codex-API-Schlüsselprofile und der lokale stdio-Fallback über Umgebungsvariablenschlüssel verwenden die App-Server-Anmeldung statt der geerbten Kindprozess-Umgebung. WebSocket-App-Server-Verbindungen erhalten keinen Gateway-Fallback für API-Schlüssel aus der Umgebung; verwenden Sie ein explizites Auth-Profil oder das eigene Konto des Remote-App-Servers. Wenn ein Abonnementprofil ein Codex-Nutzungslimit erreicht, zeichnet OpenClaw die Zurücksetzungszeit auf, sofern Codex eine meldet, und versucht für denselben Codex-Lauf das nächste geordnete Auth-Profil. Nach Ablauf der Zurücksetzungszeit wird das Abonnementprofil wieder nutzbar, ohne das ausgewählte openai/gpt-*- Modell oder die Codex-Runtime zu ändern. Wenn ein Deployment zusätzliche Umgebungsisolation benötigt, fügen Sie diese Variablen zu appServer.clearEnv hinzu:
{
  plugins: {
    entries: {
      codex: {
        enabled: true,
        config: {
          appServer: {
            clearEnv: ["CODEX_API_KEY", "OPENAI_API_KEY"],
          },
        },
      },
    },
  },
}
appServer.clearEnv wirkt sich nur auf den gestarteten Kindprozess des Codex-App-Servers aus. Dynamische Codex-Tools verwenden standardmäßig searchable-Laden. OpenClaw macht keine dynamischen Tools verfügbar, die native Codex-Workspace-Operationen duplizieren: read, write, edit, apply_patch, exec, process und update_plan. Verbleibende OpenClaw-Integrationstools wie Messaging, Sitzungen, Medien, Cron, Browser, Nodes, Gateway, heartbeat_respond und web_search sind über die Codex-Toolsuche unter dem Namespace openclaw verfügbar, wodurch der anfängliche Modellkontext kleiner bleibt. sessions_yield und Quellantworten nur mit Message-Tool bleiben direkt, weil sie Turn-Control-Verträge sind. Heartbeat-Kollaborationsanweisungen weisen Codex an, vor dem Beenden eines Heartbeat-Turns nach heartbeat_respond zu suchen, wenn das Tool noch nicht geladen ist. Setzen Sie codexDynamicToolsLoading: "direct" nur, wenn Sie eine Verbindung zu einem benutzerdefinierten Codex-App-Server herstellen, der zurückgestellte dynamische Tools nicht suchen kann, oder wenn Sie die vollständige Tool-Payload debuggen. Unterstützte Codex-Plugin-Felder auf oberster Ebene:
FeldStandardwertBedeutung
codexDynamicToolsLoading"searchable"Verwenden Sie "direct", um dynamische OpenClaw-Tools direkt in den anfänglichen Codex-Toolkontext zu legen.
codexDynamicToolsExclude[]Zusätzliche Namen dynamischer OpenClaw-Tools, die in Codex-App-Server-Turns ausgelassen werden sollen.
codexPluginsdeaktiviertNative Codex-Plugin-/App-Unterstützung für migrierte, quellinstallierte kuratierte Plugins.
Unterstützte appServer-Felder:
FeldStandardwertBedeutung
transport"stdio""stdio" startet Codex; "websocket" verbindet mit url.
commandverwaltete Codex-BinärdateiAusführbare Datei für den stdio-Transport. Lassen Sie den Wert nicht gesetzt, um die verwaltete Binärdatei zu verwenden; setzen Sie ihn nur für eine explizite Überschreibung.
args["app-server", "--listen", "stdio://"]Argumente für den stdio-Transport.
urlnicht festgelegtWebSocket-App-Server-URL.
authTokennicht festgelegtBearer-Token für den WebSocket-Transport.
headers{}Zusätzliche WebSocket-Header.
clearEnv[]Zusätzliche Namen von Umgebungsvariablen, die aus dem gestarteten stdio-App-Server-Prozess entfernt werden, nachdem OpenClaw seine geerbte Umgebung aufgebaut hat. CODEX_HOME und HOME sind für OpenClaws Codex-Isolation pro Agent bei lokalen Starts reserviert.
requestTimeoutMs60000Timeout für App-Server-Control-Plane-Aufrufe.
turnCompletionIdleTimeoutMs60000Ruhefenster nach einer turnbezogenen Codex-App-Server-Anfrage, während OpenClaw auf turn/completed wartet. Erhöhen Sie diesen Wert für langsame Synthesephasen nach Tools oder nur mit Status.
mode"yolo", sofern lokale Codex-Anforderungen YOLO nicht untersagenVoreinstellung für YOLO- oder Guardian-geprüfte Ausführung. Lokale stdio-Anforderungen, die danger-full-access, never-Genehmigung oder den user-Reviewer auslassen, machen den impliziten Standardwert zu Guardian.
approvalPolicy"never" oder eine zulässige Guardian-GenehmigungsrichtlinieNative Codex-Genehmigungsrichtlinie, die an Thread-Start, Resume oder Turn gesendet wird. Guardian-Standardwerte bevorzugen "on-request", wenn zulässig.
sandbox"danger-full-access" oder eine zulässige Guardian-SandboxNativer Codex-Sandbox-Modus, der an Thread-Start oder Resume gesendet wird. Guardian-Standardwerte bevorzugen "workspace-write", wenn zulässig, andernfalls "read-only". Wenn eine OpenClaw-Sandbox aktiv ist, wird danger-full-access auf "workspace-write" eingeschränkt.
approvalsReviewer"user" oder ein zulässiger Guardian-ReviewerVerwenden Sie "auto_review", damit Codex native Genehmigungsaufforderungen prüft, wenn zulässig, andernfalls guardian_subagent oder user. guardian_subagent bleibt ein Legacy-Alias.
serviceTiernicht festgelegtOptionale Service-Stufe des Codex-App-Servers. "priority" aktiviert Fast-Mode-Routing, "flex" fordert Flex-Verarbeitung an, null entfernt die Überschreibung, und das Legacy-"fast" wird als "priority" akzeptiert.
OpenClaw-eigene dynamische Tool-Aufrufe sind unabhängig von appServer.requestTimeoutMs begrenzt: Codex-item/tool/call-Anfragen verwenden standardmäßig einen 30-sekündigen OpenClaw-Watchdog. Ein positives timeoutMs-Argument pro Aufruf verlängert oder verkürzt dieses spezifische Tool-Budget. Das image_generate-Tool verwendet außerdem agents.defaults.imageGenerationModel.timeoutMs, wenn der Tool-Aufruf kein eigenes Timeout bereitstellt, und das Medienverständnis-image-Tool verwendet tools.media.image.timeoutSeconds oder seinen Medienstandard von 60 Sekunden. Dynamische Tool- Budgets sind auf 600000 ms begrenzt. Bei einem Timeout bricht OpenClaw das Tool-Signal ab, sofern unterstützt, und gibt eine fehlgeschlagene Dynamic-Tool-Antwort an Codex zurück, damit der Turn fortgesetzt werden kann, statt die Sitzung in processing zu belassen. Nachdem OpenClaw auf eine turn-bezogene App-Server-Anfrage von Codex geantwortet hat, erwartet das Harness außerdem, dass Codex den nativen Turn mit turn/completed abschließt. Wenn der App-Server nach dieser Antwort für appServer.turnCompletionIdleTimeoutMs still bleibt, unterbricht OpenClaw den Codex-Turn nach bestem Bemühen, zeichnet ein diagnostisches Timeout auf und gibt die OpenClaw-Sitzungsspur frei, sodass nachfolgende Chat-Nachrichten nicht hinter einem veralteten nativen Turn eingereiht werden. Jede nicht-terminale Benachrichtigung für denselben Turn, einschließlich rawResponseItem/completed, deaktiviert diesen kurzen Watchdog, weil Codex nachgewiesen hat, dass der Turn noch aktiv ist; der längere terminale Watchdog schützt weiterhin tatsächlich festhängende Turns. Globale App-Server-Benachrichtigungen, wie Ratenlimit-Aktualisierungen, setzen den Turn-Idle-Fortschritt nicht zurück. Wenn Codex ein abgeschlossenes agentMessage-Element ausgibt und dann ohne turn/completed still bleibt, behandelt OpenClaw die Assistentenausgabe als effektiv abgeschlossen, unterbricht den nativen Codex-Turn nach bestem Bemühen und gibt die Sitzungsspur frei. Timeout- Diagnosen enthalten die letzte App-Server-Benachrichtigungsmethode und, für rohe Assistentenantwortelemente, den Elementtyp, die Rolle, die ID und eine begrenzte Vorschau des Assistententexts. Umgebungsüberschreibungen bleiben für lokale Tests verfügbar:
  • OPENCLAW_CODEX_APP_SERVER_BIN
  • OPENCLAW_CODEX_APP_SERVER_ARGS
  • OPENCLAW_CODEX_APP_SERVER_MODE=yolo|guardian
  • OPENCLAW_CODEX_APP_SERVER_APPROVAL_POLICY
  • OPENCLAW_CODEX_APP_SERVER_SANDBOX
OPENCLAW_CODEX_APP_SERVER_BIN umgeht die verwaltete Binärdatei, wenn appServer.command nicht gesetzt ist. OPENCLAW_CODEX_APP_SERVER_GUARDIAN=1 wurde entfernt. Verwenden Sie stattdessen plugins.entries.codex.config.appServer.mode: "guardian" oder OPENCLAW_CODEX_APP_SERVER_MODE=guardian für einmalige lokale Tests. Config wird für wiederholbare Bereitstellungen bevorzugt, weil sie das Plugin-Verhalten in derselben geprüften Datei hält wie den übrigen Codex-Harness-Aufbau.

Native Codex-Plugins

Native Codex-Plugin-Unterstützung verwendet die eigenen App- und Plugin- Fähigkeiten des Codex-App-Servers im selben Codex-Thread wie der OpenClaw-Harness-Turn. OpenClaw übersetzt Codex-Plugins nicht in synthetische codex_plugin_* OpenClaw- Dynamic Tools. codexPlugins wirkt sich nur auf Sitzungen aus, die das native Codex-Harness auswählen. Es hat keine Auswirkungen auf PI-Läufe, normale OpenAI-Provider-Läufe, ACP-Gesprächs- Bindings oder andere Harnesses. Minimale migrierte Config:
{
  plugins: {
    entries: {
      codex: {
        enabled: true,
        config: {
          codexPlugins: {
            enabled: true,
            allow_destructive_actions: true,
            plugins: {
              "google-calendar": {
                enabled: true,
                marketplaceName: "openai-curated",
                pluginName: "google-calendar",
              },
            },
          },
        },
      },
    },
  },
}
Die Thread-App-Config wird berechnet, wenn OpenClaw eine Codex-Harness-Sitzung herstellt oder ein veraltetes Codex-Thread-Binding ersetzt. Sie wird nicht bei jedem Turn neu berechnet. Nach einer Änderung an codexPlugins verwenden Sie /new, /reset oder starten Sie den Gateway neu, damit zukünftige Codex-Harness-Sitzungen mit dem aktualisierten App-Satz starten. Informationen zu Migrationsfähigkeit, App-Inventar, Richtlinien für destruktive Aktionen, Elicitations und nativen Plugin-Diagnosen finden Sie unter Native Codex-Plugins.

Computer Use

Computer Use wird in einer eigenen Einrichtungsanleitung behandelt: Codex Computer Use. Kurzfassung: OpenClaw vendort die Desktop-Control-App nicht und führt Desktop-Aktionen nicht selbst aus. Es bereitet den Codex-App-Server vor, verifiziert, dass der computer-use-MCP-Server verfügbar ist, und lässt dann Codex während Codex-Modus-Turns die nativen MCP-Tool-Aufrufe besitzen.

Laufzeitgrenzen

Das Codex-Harness ändert nur den Low-Level-Executor des eingebetteten Agents.
  • OpenClaw Dynamic Tools werden unterstützt. Codex bittet OpenClaw, diese Tools auszuführen, sodass OpenClaw im Ausführungspfad bleibt.
  • Codex-native Shell-, Patch-, MCP- und native App-Tools gehören Codex. OpenClaw kann ausgewählte native Ereignisse über den unterstützten Relay beobachten oder blockieren, schreibt native Tool-Argumente aber nicht um.
  • Codex besitzt native Compaction. OpenClaw behält eine Transkriptspiegelung für Kanal- Verlauf, Suche, /new, /reset und zukünftige Modell- oder Harness-Wechsel.
  • Mediengenerierung, Medienverständnis, TTS, Genehmigungen und Messaging-Tool- Ausgabe laufen weiterhin über die passenden OpenClaw-Provider-/Modelleinstellungen.
  • tool_result_persist gilt für OpenClaw-eigene Transkript-Tool-Ergebnisse, nicht für Codex-native Tool-Ergebnisdatensätze.
Informationen zu Hook-Ebenen, unterstützten V1-Oberflächen, nativer Berechtigungsbehandlung, Queue- Steuerung, Mechanik für Codex-Feedback-Uploads und Compaction-Details finden Sie unter Codex-Harness-Laufzeit.

Problembehebung

Codex erscheint nicht als normaler /model-Provider: Das ist bei neuen Configs erwartet. Wählen Sie ein openai/gpt-*-Modell aus, aktivieren Sie plugins.entries.codex.enabled und prüfen Sie, ob plugins.allow codex ausschließt. OpenClaw verwendet PI statt Codex: Stellen Sie sicher, dass die Modellreferenz openai/gpt-* auf dem offiziellen OpenAI-Provider ist und dass das Codex-Plugin installiert und aktiviert ist. Wenn Sie beim Testen einen strikten Nachweis benötigen, setzen Sie beim Provider oder Modell agentRuntime.id: "codex". Eine erzwungene Codex-Laufzeit schlägt fehl, statt auf PI zurückzufallen. Legacy-openai-codex/*-Config bleibt bestehen: Führen Sie openclaw doctor --fix aus. Doctor schreibt Legacy-Modellreferenzen zu openai/* um, entfernt veraltete Sitzungs- und Whole-Agent-Laufzeit-Pins und bewahrt vorhandene Auth-Profil-Überschreibungen. Der App-Server wird abgelehnt: Verwenden Sie Codex-App-Server 0.125.0 oder neuer. Prereleases derselben Version oder Build-Suffix-Versionen wie 0.125.0-alpha.2 oder 0.125.0+custom werden abgelehnt, weil OpenClaw den stabilen Protokoll-Mindeststand 0.125.0 testet. /codex status kann keine Verbindung herstellen: Prüfen Sie, dass das gebündelte codex-Plugin aktiviert ist, dass plugins.allow es einschließt, wenn eine Allowlist konfiguriert ist, und dass alle benutzerdefinierten appServer.command-, url-, authToken- oder Header-Werte gültig sind. Modellerkennung ist langsam: Verringern Sie plugins.entries.codex.config.discovery.timeoutMs oder deaktivieren Sie die Erkennung. Siehe Codex-Harness-Referenz. WebSocket-Transport schlägt sofort fehl: Prüfen Sie appServer.url, authToken, Header und dass der entfernte App-Server dieselbe Codex-App-Server- Protokollversion spricht. Ein Nicht-Codex-Modell verwendet PI: Das ist erwartet, sofern die Provider- oder Modelllaufzeit- Richtlinie es nicht zu einem anderen Harness leitet. Einfache Nicht-OpenAI-Provider-Referenzen bleiben im auto-Modus auf ihrem normalen Provider-Pfad. Computer Use ist installiert, aber Tools laufen nicht: Prüfen Sie /codex computer-use status aus einer frischen Sitzung. Wenn ein Tool Native hook relay unavailable meldet, verwenden Sie /new oder /reset; wenn es bestehen bleibt, starten Sie den Gateway neu, um veraltete native Hook-Registrierungen zu löschen. Siehe Codex Computer Use.

Verwandte Themen