codex führt eingebettete OpenAI-Agent-Durchläufe über den Codex
app-server statt über das integrierte OpenClaw-Harness aus. Codex verwaltet die
untergeordnete Agent-Sitzung: natives Fortsetzen von Threads, native Fortsetzung von Tools,
native Compaction und app-server-Ausführung. OpenClaw verwaltet weiterhin Chat-
Kanäle, Sitzungsdateien, Modellauswahl, dynamische OpenClaw-Tools, Genehmigungen,
Medienübermittlung und die sichtbare Transkriptspiegelung.
Verwenden Sie kanonische OpenAI-Modellreferenzen wie openai/gpt-5.6-sol. Konfigurieren Sie keine
veralteten Codex-GPT-Referenzen; legen Sie die Authentifizierungsreihenfolge für OpenAI-Agenten unter auth.order.openai ab.
Veraltete Codex-Authentifizierungsprofil-IDs und Einträge der veralteten Codex-Authentifizierungsreihenfolge werden
durch openclaw doctor --fix repariert.
Wenn die Provider-/Modell-Laufzeitrichtlinie nicht festgelegt oder auf auto gesetzt ist, wählt das Präfix openai/* allein
dieses Harness niemals aus. OpenAI darf Codex nur dann implizit auswählen, wenn eine
exakte offizielle HTTPS-Route für Platform Responses oder ChatGPT Responses ohne
benutzerdefinierte Anfrageüberschreibung verwendet wird. Siehe
Implizite Agent-Laufzeit von OpenAI.
Wenn Codex die Authentifizierung verwaltet, bevor das Routing zwischen Platform und ChatGPT bekannt ist, verlangt OpenClaw
weiterhin, dass jede mögliche Route Codex-Kompatibilität deklariert. Allein die native
Authentifizierungsverwaltung umgeht diese Routenprüfung niemals.
Wenn keine OpenClaw-Sandbox aktiv ist, startet OpenClaw Codex-app-server-Threads
mit aktiviertem nativen Codex-Codemodus (code-mode-only bleibt standardmäßig deaktiviert), sodass
native Arbeitsbereichs-/Codefunktionen neben dynamischen OpenClaw-Tools verfügbar bleiben,
die über die app-server-Brücke item/tool/call geleitet werden. Eine
aktive OpenClaw-Sandbox oder eingeschränkte Tool-Richtlinie deaktiviert den nativen Codemodus
vollständig, sofern Sie nicht ausdrücklich den experimentellen Sandbox-exec-server-Pfad aktivieren.
Mit der Standardeinstellung tools.exec.host: "auto" und ohne aktive OpenClaw-Sandbox
erhält Codex außerdem die Tools node_exec und node_process für Befehle auf gekoppelten
Nodes. Die native Shell verbleibt auf Host und Arbeitsbereich des Codex-app-server
(bei der standardmäßigen stdio-Bereitstellung lokal zum Gateway); node_exec wählt eine Node anhand
ihres Namens oder ihrer ID aus und setzt weiterhin die Node-Genehmigungsrichtlinie von OpenClaw durch. Wenn eine endliche
Laufzeit-Zulassungsliste den nativen Codemodus deaktiviert und der Durchlauf dadurch keine
Ausführungsumgebung mehr hat, hält OpenClaw stattdessen seine richtliniengefilterten Tools exec und process
für die direkte Ausführung ohne Sandbox verfügbar.
Diese native Codex-Funktion unterscheidet sich vom
OpenClaw-Codemodus, einer optionalen QuickJS-WASI-Laufzeit
für allgemeine OpenClaw-Durchläufe mit einer anderen Eingabeform exec. Einen Überblick über die
umfassendere Aufteilung zwischen Modell, Provider und Laufzeit finden Sie unter
Agent-Laufzeiten: openai/gpt-5.6-sol ist die Modell-
referenz, codex ist die Laufzeit und Telegram, Discord, Slack oder ein anderer
Kanal ist die Kommunikationsoberfläche.
Anforderungen
- Das offizielle Plugin
@openclaw/codexmuss installiert sein. Nehmen Siecodexinplugins.allowauf, wenn Ihre Konfiguration eine Zulassungsliste verwendet. - Ein stabiler Codex-app-server von
0.143.0bis0.145.0. Das Plugin verwaltet standardmäßig eine kompatible Binärdatei, sodass sich ein BefehlcodexunterPATHnicht auf den normalen Start auswirkt. - Codex-Authentifizierung über
openclaw models auth login --provider openai, ein bereits im Codex-Home des Agenten vorhandenes app-server-Konto oder ein explizites Codex-API-Schlüssel-Authentifizierungsprofil.
Schnellstart
Installieren Sie das offizielle Plugin und melden Sie sich anschließend mit Codex OAuth an:codex und wählen Sie ein OpenAI-Agent-Modell aus:
plugins.allow verwendet, fügen Sie dort auch codex hinzu:
/new oder /reset aus, damit der nächste Durchlauf das Harness
anhand der aktuellen Konfiguration bestimmt.
Threads mit Codex Desktop und der CLI teilen
Die StandardeinstellungappServer.homeScope: "agent" isoliert jeden OpenClaw-Agenten vom
nativen Codex-Zustand des Betreibers. Damit ein Eigentümer dieselben nativen Threads untersuchen und verwalten kann,
die in Codex Desktop und der Codex CLI angezeigt werden, aktivieren Sie das
Codex-Home des Benutzers:
$CODEX_HOME, wenn dies festgelegt ist, andernfalls ~/.codex, einschließlich
der nativen Codex-Authentifizierung, Konfiguration, Plugins und des Thread-Speichers dieses Homes. OpenClaw
injiziert kein OpenClaw-Authentifizierungsprofil in diesen app-server.
Durchläufe des Eigentümers erhalten das Tool codex_threads: native Threads auflisten, durchsuchen, lesen, forken, umbenennen,
archivieren und wiederherstellen. Forken Sie einen Thread, um ihn in
OpenClaw fortzusetzen; der Fork wird an die aktuelle OpenClaw-Sitzung angehängt und bleibt
für andere native Codex-Clients sichtbar. Für die Archivierung ist eine ausdrückliche
Bestätigung erforderlich, dass der Thread an anderer Stelle geschlossen ist. Wenn außerdem die Überwachung
aktiviert ist, benötigen Transkriptfelder und Änderungen die entsprechende Aktivierung von
supervision.allowRawTranscripts oder supervision.allowWriteControls.
Setzen Sie denselben Thread nicht gleichzeitig über unabhängig verwaltete
stdio-App-Server fort und schreiben Sie nicht gleichzeitig darauf. Codex koordiniert aktive Schreibzugriffe innerhalb eines App Servers, nicht
über separate Prozesse hinweg. Das Forken ist der sichere Koexistenzpfad für gewöhnliche
stdio-Sitzungen im Benutzer-Home.
appServer.homeScope: "user" allein steuert nicht den Flottenkatalog. Die native
Sitzungserkennung ist aktiviert, solange das Plugin aktiv ist; setzen Sie
sessionCatalog.enabled: false, um sie aus der OpenClaw-Seitenleiste zu entfernen, ohne
Codex zu deaktivieren. Der Katalog verwendet eine separate Überwachungsverbindung; ohne
explizite Verbindungseinstellungen für appServer verwendet diese Verbindung standardmäßig verwaltetes
stdio im Benutzer-Home, während das gewöhnliche Harness agentenspezifisch bleibt. Explizite
Einstellungen für appServer werden von beiden Pfaden berücksichtigt. Setzen Sie homeScope: "user"
wie oben ausdrücklich, wenn auch das gewöhnliche Harness den nativen Zustand gemeinsam nutzen soll.
Codex-Sitzungen überwachen
Dasselbe Plugincodex kann nicht archivierte Codex-Sitzungen auf dem Gateway-
Computer und auf ausdrücklich aktivierten gekoppelten Nodes auflisten. Eine gespeicherte oder inaktive Gateway-lokale Sitzung kann
einen modellgebundenen Chat erstellen, der ihren begrenzten, persistenten Verlauf von Benutzer und Assistent
spiegelt. Seine private Bindung verwendet die Überwachungsverbindung für den nativen
Snapshot, den kanonischen Branch und spätere Durchläufe, während gewöhnliche Codex-Sitzungen
agentenspezifisch bleiben. Beim ersten kanonischen Start werden exakt das Modell und der Provider verwendet, die
Codex für den Snapshot-Fork zurückgibt. Bei späteren Fortsetzungen bleibt die Auswahl der
nativen Codex-Konfiguration überlassen; das äußere OpenClaw-Modell und die Fallback-Kette ersetzen
sie niemals. Gespeicherte und inaktive Zeilen können nach ausdrücklicher Bestätigung,
dass kein anderer Runner vorhanden ist, archiviert werden. Aktive Quellen können weder einen Branch erstellen noch archiviert werden; ein bestehender
überwachter Chat kann weiterhin geöffnet werden. Sitzungen auf gekoppelten Nodes bleiben auf Metadaten beschränkt.
Einrichtung, Branching-Regeln, Beschränkungen gekoppelter Nodes, Metadatenoffenlegung und Fehlerbehebung finden Sie unter Codex-Sitzungen überwachen.
Konfiguration
Bevorzugen Sie
auth.order.openai für eine Reihenfolge mit Abonnement zuerst und API-Schlüssel als Backup.
Vorhandene veraltete Codex-Authentifizierungsprofil-IDs und die veraltete Codex-Authentifizierungsreihenfolge sind
veralteter Zustand ausschließlich für doctor; schreiben Sie keine neuen veralteten Codex-GPT-Referenzen.
Compaction
Setzen Siecompaction.model oder compaction.provider nicht für Codex-gestützte
Agenten. Codex führt Compaction über seinen nativen app-server-Thread-Zustand durch, daher
ignoriert OpenClaw diese lokalen Summarizer-Überschreibungen zur Laufzeit, und
openclaw doctor --fix entfernt sie, wenn der Agent Codex verwendet.
Lossless wird weiterhin als Kontext-Engine für Zusammenstellung, Aufnahme und
Wartung rund um Codex-Durchläufe unterstützt und über
plugins.slots.contextEngine: "lossless-claw" und
plugins.entries.lossless-claw.config.summaryModel konfiguriert, nicht über
agents.defaults.compaction.provider. openclaw doctor --fix migriert die
alte Form compaction.provider: "lossless-claw" in den Lossless-
Kontext-Engine-Slot, wenn Codex die aktive Laufzeit ist, doch die native Codex-Laufzeit verwaltet weiterhin
die Compaction. Das native app-server-Harness unterstützt Kontext-Engines,
die eine Zusammenstellung vor dem Prompt benötigen; generische CLI-Backends, einschließlich codex-cli,
stellen diese Host-Funktion nicht bereit.
Bei Codex-gestützten Agenten startet /compact die native Codex-app-server-
Compaction auf dem gebundenen Thread und wartet auf ihr endgültiges Ergebnis. Das gemeinsame
Budget agents.defaults.compaction.timeoutSeconds gilt; bei einer Zeitüberschreitung
fordert OpenClaw Codex auf, den nativen Durchlauf zu unterbrechen, und behält die threadbezogene Sperre bei,
bis die Beendigung bestätigt ist. Es greift niemals ersatzweise auf eine Kontext-Engine oder
den öffentlichen OpenAI-Summarizer zurück. Wenn die native Codex-Thread-Bindung fehlt oder
veraltet ist, schlägt der Befehl geschlossen fehl, statt unbemerkt zu einem anderen Compaction-
Backend zu wechseln.
Direkte API mit langem Kontext
Codex-Abonnement und direkter OpenAI-API-Datenverkehr sind separate Verträge. Der Live-Katalog von ChatGPT/Codex weist üblicherweise ein Modell-Kontextfenster von272000 Token auf,
während OpenAI für GPT-5.5 und GPT-5.6 ein Platform-API-Fenster von 1050000 Token und
eine maximale Ausgabe von 128000 dokumentiert. Wird die vollständige Ausgabekapazität
reserviert, ergibt sich daraus ein Eingabebudget von 922000 Token. Für Anfragen mit mehr als
272000 Eingabe-Token gilt die höhere OpenAI-Preisgestaltung für lange Kontexte.
Beginnen Sie mit einem vollständigen Codex-Modellkatalog, der mit der installierten
Codex-Version kompatibel ist. Behalten Sie für jeden direkten GPT-5.5- oder GPT-5.6-Eintrag,
der einen langen Kontext verwenden soll, den restlichen Deskriptor bei und legen Sie Folgendes fest:
922000 an und meldet daher ungefähr 875900 nutzbare Token. Eine Compaction bei
700000 lässt 175900 Token bis zu dieser effektiven Schutzgrenze und
222000 bis zur Provider-sicheren Eingabekapazität frei. Dieser größere Puffer ist beabsichtigt:
Codex prüft den bereits aufgezeichneten Kontext, bevor die nächste Benutzernachricht und
Kontextaktualisierungen hinzugefügt werden. Der Schwellenwert muss daher sowohl einen großen
eingehenden Turn als auch Tools, Anweisungen, Serialisierung und den Compaction-Turn selbst abdecken.
Für die eigenständige Verwendung der Codex CLI oder Desktop-Anwendung kann ein benutzerdefinierter
Provider mit Befehlsauthentifizierung den API-Schlüssel aus einem System-Schlüsselbund oder
Secret-Manager lesen, während die normale ChatGPT-Anmeldung für Konnektoren verfügbar bleibt:
openai einschleusen. Übergeben Sie den Katalog und die Kontextgrenzen als native
Argumente des Codex-App-Servers:
openai:api-key bei Bedarf durch die tatsächliche ID des API-Schlüsselprofils. Der
agentenspezifische App-Server erhält ausschließlich diesen vorbereiteten Schlüssel; die native
ChatGPT-Anmeldung unter ~/.codex, die Plugins, Konnektoren und der Thread-Speicher des
Betreibers bleiben unverändert. Codex App-Server 0.144.6 fügt bei App-Server-Turns
nicht den Bearer-Token eines benutzerdefinierten Providers mit Befehlsauthentifizierung hinzu.
Verwenden Sie für diese Route daher den oben beschriebenen eingeschleusten API-Schlüsselpfad
anstelle von homeScope: "user".
Starten Sie nach Änderungen am Katalog oder an den App-Server-Argumenten den Gateway neu und
beginnen Sie einen neuen Chat. Bestehende native Threads behalten ihre aufgezeichneten Provider-
und Modelleinstellungen bei. Überprüfen Sie die Laufzeit mit /status und
/codex status und senden Sie anschließend einen harmlosen direkten API-Turn, bevor Sie eine
lange Sitzung beginnen.
Der Rest dieser Seite behandelt die Bereitstellungsstruktur, Fail-Closed-Routing,
Guardian-Genehmigungsrichtlinien, native Codex-Plugins und Computer Use. Vollständige Listen
der Optionen, Standardwerte, Enumerationen sowie Informationen zu Erkennung,
Umgebungsisolierung, Zeitüberschreitungen und App-Server-Transportfeldern finden Sie in der
Referenz zum Codex-Harness.
Codex-Laufzeit überprüfen
Verwenden Sie/status in dem Chat, in dem Sie Codex erwarten. Ein von Codex gestützter
OpenAI-Agent-Turn zeigt Folgendes an:
/codex binding meldet den verknüpften nativen Thread und die aktuellen Modelleinstellungen.
/codex status meldet die App-Server-Verbindung, das Konto, die Ratenbegrenzungen, MCP-Server
und Skills. /codex models führt den Live-Katalog des Codex-App-Servers für das Harness und
das Konto auf. Falls /status unerwartet ist, lesen Sie
Fehlerbehebung.
Routing und Modellauswahl
Halten Sie Provider-Referenzen und Laufzeitrichtlinien getrennt:- Verwenden Sie
openai/gpt-*für die kanonische OpenAI-Modellauswahl. Das Präfix allein wählt niemals Codex aus. - Wenn die Laufzeit nicht festgelegt oder auf
autogesetzt ist, kann ausschließlich eine exakte offizielle HTTPS-Route für Platform Responses oder ChatGPT Responses ohne selbst definierte Anfrageüberschreibung Codex implizit auswählen. - Verwenden Sie keine veralteten Codex-GPT-Referenzen in der Konfiguration. Führen Sie
openclaw doctor --fixaus, um veraltete Referenzen und überholte Sitzungs-Routenbindungen zu reparieren. agentRuntime.id: "codex"macht Codex für eine kompatible Route zu einer Fail-Closed-Anforderung. Eine inkompatible effektive Route wird dadurch nicht kompatibel.agentRuntime.id: "openclaw"aktiviert für einen Provider oder ein Modell die eingebettete OpenClaw-Laufzeit, wenn dies beabsichtigt ist./codex ...steuert native Unterhaltungen des Codex-App-Servers 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.
agents.defaults.imageModel folgt derselben Präfixaufteilung. Verwenden Sie openai/gpt-*
für die normale OpenAI-Route und codex/gpt-* nur dann, wenn das Bildverständnis
über einen begrenzten Codex-App-Server-Turn ausgeführt werden soll. Doctor schreibt veraltete
Codex-GPT-Referenzen in openai/gpt-* um.
Bereitstellungsmuster
Einfache Codex-Bereitstellung
Verwenden Sie die Schnellstartkonfiguration für ein OpenAI-Modell, dessen effektive offizielle HTTPS-Route geeignet ist, Codex implizit auszuwählen:Bereitstellung mit gemischten Providern
Behalten Sie Claude als Standardagenten bei und fügen Sie einen benannten Codex-Agenten hinzu:main verwendet seinen normalen Provider-Pfad. Der Agent
codex verwendet den Codex-App-Server, solange seine effektive OpenAI-Route kompatibel
bleibt. Fügen Sie explizit modellbezogenes agentRuntime.id: "codex" hinzu, wenn dies eine
Fail-Closed-Anforderung sein soll.
Fail-Closed-Codex-Bereitstellung
Eine geeignete, exakte offizielle HTTPS-OpenAI-Route kann zu Codex aufgelöst werden, wenn das gebündelte Plugin verfügbar ist. Fügen Sie für eine ausdrücklich festgelegte Fail-Closed-Regel eine explizite Laufzeitrichtlinie hinzu:App-Server-Richtlinie
Standardmäßig startet das Plugin die von OpenClaw verwaltete Codex-Binärdatei lokal mit stdio-Transport. Setzen SieappServer.command nur, wenn absichtlich eine
andere ausführbare Datei verwendet werden soll. Codex stuft den WebSocket-Transport als experimentell
und nicht unterstützt ein; verwenden Sie ihn nur für Tests außerhalb der Produktion mit einem App-Server,
der bereits an anderer Stelle ausgeführt wird:
approvalPolicy: "never", approvalsReviewer: "user" und
sandbox: "danger-full-access". Wenn lokale Codex-Anforderungen diese
implizite YOLO-Vertrauensstellung nicht zulassen, wählt OpenClaw stattdessen
zulässige Guardian-Berechtigungen aus. Wenn für die Sitzung eine OpenClaw-Sandbox
aktiv ist, deaktiviert OpenClaw für diesen Turn den nativen Code Mode von Codex,
benutzerdefinierte MCP-Server und die Ausführung App-gestützter Plugins, anstatt sich
auf das hostseitige Sandboxing von Codex zu verlassen. Der Shell-Zugriff erfolgt
stattdessen über dynamische, von der OpenClaw-Sandbox unterstützte Tools wie
sandbox_exec und sandbox_process, wenn die normalen Exec-/Prozesstools
verfügbar sind.
Verwenden Sie den normalisierten OpenClaw-Exec-Modus für die native automatische Überprüfung
von Codex, bevor Sandbox-Ausbrüche oder zusätzliche Berechtigungen eingesetzt werden:
tools.exec.mode: "auto" auf von Codex
Guardian geprüfte Genehmigungen abgebildet: üblicherweise approvalPolicy: "on-request",
approvalsReviewer: "auto_review" und sandbox: "workspace-write", wenn
die lokalen Anforderungen diese Werte zulassen. In tools.exec.mode: "auto"
behält OpenClaw veraltete unsichere Codex-Überschreibungen für approvalPolicy: "never"
oder sandbox: "danger-full-access" nicht bei; verwenden Sie tools.exec.mode: "full"
für eine absichtlich genehmigungsfreie Codex-Vertrauensstellung. Die veraltete
Voreinstellung plugins.entries.codex.config.appServer.mode: "guardian" funktioniert weiterhin,
aber tools.exec.mode: "auto" ist die normalisierte OpenClaw-Oberfläche.
Den Vergleich auf Modusebene mit Host-Exec-Genehmigungen und ACPX-Berechtigungen
finden Sie unter Berechtigungsmodi. Einzelheiten zu allen
App-Server-Feldern, zur Authentifizierungsreihenfolge, zur Umgebungsisolation und zum Timeout-Verhalten
finden Sie in der Codex-Harness-Referenz.
Befehle und Diagnose
Das Plugincodex registriert /codex als Slash-Befehl in jedem Kanal, der
OpenClaw-Textbefehle unterstützt.
Native Ausführung und Steuerung erfordern einen Eigentümer oder einen operator.admin-
Gateway-Client: Threads binden oder fortsetzen, Turns senden oder stoppen,
Modell, Schnellmodus oder Berechtigungsstatus ändern, Compaction oder Überprüfungen
durchführen und eine Bindung lösen. Andere autorisierte Absender behalten
schreibgeschützte Befehle zur Status-, Hilfe-, Konto-, Modell-, Thread-, nativen Ziel-,
MCP-Server-, Skill- und Bindungsprüfung.
Gängige Formen:
/codex statusprüft App-Server-Konnektivität, Modelle, Konto, Nutzungslimits, MCP-Server und Skills./codex modelslistet aktive Codex-App-Server-Modelle auf./codex threads [filter]listet kürzlich verwendete Codex-App-Server-Threads auf./codex goalliest oder aktualisiert das native Codex-Ziel des angehängten Threads. Die automatische Zielfortsetzung von Codex bleibt deaktiviert; OpenClaw verwaltet noch keine autonomen nachfolgenden Turns./codex resume <thread-id>hängt die aktuelle OpenClaw-Sitzung an einen vorhandenen Codex-Thread an./codex bind [thread-id] [--cwd <path>] [--model <model>] [--provider <provider>]hängt den aktuellen Chat an./codex detach(oder/codex unbind) löst die aktuelle Bindung./codex bindingbeschreibt die aktuelle Bindung./codex stopstoppt den aktiven Turn;/codex steer <text>steuert ihn./codex model <model>,/codex fast [on|off|status]und/codex permissions [default|yolo|status]ändern den konversationsbezogenen Status./codex compactfordert den Codex-App-Server auf, für den angehängten Thread eine Compaction durchzuführen./codex reviewstartet die native Codex-Überprüfung für den angehängten Thread./codex diagnostics [note]fragt vor dem Senden von Codex-Feedback für den angehängten Thread nach./codex accountzeigt den Konto- und Nutzungslimitstatus an./codex mcplistet den Status der MCP-Server des Codex-App-Servers auf./codex skillslistet die Skills des Codex-App-Servers auf./codex plugins list,/codex plugins enable <name>und/codex plugins disable <name>verwalten konfigurierte native Codex-Plugins./codex computer-use [status|install]verwaltet Codex Computer Use./codex helplistet den vollständigen Befehlsbaum auf.
/diagnostics [note] in der
Konversation, in der der Fehler aufgetreten ist. Dadurch wird ein Gateway-Diagnosebericht
erstellt und bei Codex-Harness-Sitzungen um Genehmigung zum Senden des
relevanten Codex-Feedbackpakets gebeten. Informationen zum Datenschutzmodell und zum Verhalten
in Gruppenchats finden Sie unter
Diagnoseexport. Verwenden Sie /codex diagnostics [note] nur, wenn Sie ausdrücklich
das Codex-Feedback für den derzeit angehängten Thread hochladen möchten, ohne
das vollständige Gateway-Diagnosepaket einzuschließen.
Codex-Threads lokal prüfen
Die schnellste Möglichkeit, einen fehlerhaften Codex-Lauf zu untersuchen, besteht häufig darin, den nativen Codex-Thread direkt zu öffnen:/diagnostics, in /codex binding
oder in /codex threads [filter].
Informationen zum Upload-Mechanismus und zu den Diagnosegrenzen auf Runtime-Ebene finden Sie unter
Codex-Harness-Runtime.
Authentifizierungsreihenfolge
Im standardmäßigen agentenbezogenen Home-Verzeichnis wird die Authentifizierung in dieser Reihenfolge ausgewählt:- Geordnete OpenAI-Authentifizierungsprofile für den Agenten, vorzugsweise unter
auth.order.openai. Führen Sieopenclaw doctor --fixaus, um ältere veraltete Codex-Authentifizierungsprofil-IDs und die veraltete Codex-Authentifizierungsreihenfolge zu migrieren. - Das vorhandene Konto des App-Servers im Codex-Home-Verzeichnis dieses Agenten.
- Nur bei lokalen stdio-App-Server-Starts:
CODEX_API_KEY, danachOPENAI_API_KEY, wenn kein App-Server-Konto vorhanden ist und weiterhin eine OpenAI-Authentifizierung erforderlich ist.
CODEX_API_KEY und OPENAI_API_KEY aus dem gestarteten
Codex-Kindprozess. Dadurch bleiben API-Schlüssel auf Gateway-Ebene für Einbettungen oder
direkte OpenAI-Modelle verfügbar, ohne dass native Turns des Codex-App-Servers
versehentlich über die API abgerechnet werden. Explizite Codex-API-Schlüsselprofile und der lokale
stdio-Fallback auf Umgebungsschlüssel verwenden die App-Server-Anmeldung anstelle der geerbten
Umgebung des Kindprozesses. WebSocket-App-Server-Verbindungen erhalten keinen Fallback auf
Gateway-Umgebungs-API-Schlüssel; verwenden Sie ein explizites Authentifizierungsprofil oder das eigene
Konto des entfernten App-Servers.
Wenn ein Abonnementprofil ein Codex-Nutzungslimit erreicht, zeichnet OpenClaw die
Rücksetzzeit auf, sofern Codex eine meldet, und versucht für denselben Codex-Lauf
das nächste geordnete Authentifizierungsprofil. Nach Ablauf der Rücksetzzeit kann das
Abonnementprofil wieder verwendet werden, ohne dass das ausgewählte openai/gpt-*-
Modell oder die Codex-Runtime geändert wird.
Wenn native Codex-Plugins konfiguriert sind, installiert oder aktualisiert OpenClaw
diese Plugins über den verbundenen App-Server, bevor dem Codex-Thread
Plugin-eigene Apps bereitgestellt werden. app/list bleibt die maßgebliche Quelle für App-
IDs, Zugänglichkeit und Metadaten, aber OpenClaw verwaltet die threadbezogene
Aktivierungsentscheidung: Wenn die Richtlinie eine aufgeführte zugängliche App zulässt, sendet OpenClaw
thread/start.config.apps[appId].enabled = true, selbst wenn app/list
diese App derzeit als deaktiviert meldet. Dieser Pfad erfindet keine App-
Installation für unbekannte IDs; OpenClaw aktiviert nur Marketplace-Plugins
mit plugin/install und aktualisiert anschließend den Bestand.
Umgebungsisolation
Bei lokalen stdio-App-Server-Starts setzt OpenClawCODEX_HOME auf ein
agentenbezogenes Verzeichnis, sodass Codex-Konfiguration, Authentifizierungs-/Kontodateien, Plugin-Cache/-Daten
und der native Thread-Status standardmäßig nicht aus dem persönlichen
~/.codex des Betreibers gelesen oder dorthin geschrieben werden. OpenClaw behält das normale
prozessbezogene HOME bei; von Codex ausgeführte Unterprozesse können weiterhin
Konfigurationen und Token im Benutzer-Home-Verzeichnis finden, und Codex kann gemeinsame Einträge unter
$HOME/.agents/skills und $HOME/.agents/plugins/marketplace.json erkennen. Mit
appServer.homeScope: "user" verwendet OpenClaw stattdessen das native Codex-
Home-Verzeichnis des Benutzers und dessen vorhandenes Konto, ohne ein OpenClaw-Authentifizierungsprofil einzufügen.
Wenn eine Bereitstellung zusätzliche Umgebungsisolation erfordert, fügen Sie diese
Variablen zu appServer.clearEnv hinzu:
appServer.clearEnv wirkt sich nur auf den gestarteten Kindprozess des Codex-App-Servers
aus. OpenClaw entfernt CODEX_HOME und HOME während
der lokalen Startnormalisierung aus dieser Liste: CODEX_HOME verweist weiterhin auf den ausgewählten
Agenten- oder Benutzerbereich, und HOME wird weiterhin geerbt, damit Unterprozesse den
normalen Status des Benutzer-Home-Verzeichnisses verwenden können.
Dynamische Tools und Websuche
Dynamische Codex-Tools verwenden standardmäßig das Laden übersearchable. OpenClaw stellt normalerweise
keine dynamischen Tools bereit, die native Codex-Arbeitsbereichsoperationen duplizieren:
read, write, edit, apply_patch, exec, process, update_plan,
get_goal, create_goal, update_goal, tool_call, tool_describe,
tool_search und tool_search_code. Zieloperationen bleiben nativ in Codex,
daher projiziert OpenClaw keinen zweiten Zielspeicher in Codex-Turns. Die meisten
übrigen OpenClaw-Integrationstools, etwa für Messaging, Medien, Cron,
Browser, Nodes, Gateway und heartbeat_respond, sind über die
Codex-Tool-Suche im Namespace openclaw verfügbar, wodurch der anfängliche Modellkontext
kleiner bleibt. Der Shell-Fallback für eingeschränkte Turns bildet die Ausnahme für
exec und process, wenn eine endliche Positivliste den nativen Code Mode deaktiviert;
Runtime-Positivlisten und codexDynamicToolsExclude gelten weiterhin.
Mit catalogMode: "direct-only" gekennzeichnete Tools, einschließlich des OpenClaw-Tools computer,
verwenden stattdessen den Namespace openclaw_direct. Codex behandelt diesen Namespace
als DirectModelOnly, sodass diese Tools in normalen und ausschließlich für den
Code Mode vorgesehenen Threads direkt für das Modell sichtbar bleiben, anstatt verschachtelte
Code-Mode-Aufrufe von tools.* zu durchlaufen.
Die Websuche verwendet standardmäßig das gehostete Codex-Tool web_search, wenn die Suche
aktiviert und kein verwalteter Provider ausgewählt ist. Die native gehostete Suche und
das verwaltete dynamische OpenClaw-Tool web_search schließen sich gegenseitig aus, damit
die verwaltete Suche native Domänenbeschränkungen nicht umgehen kann. OpenClaw verwendet das
verwaltete Tool, wenn die gehostete Suche nicht verfügbar oder ausdrücklich deaktiviert ist oder
durch einen ausgewählten verwalteten Provider ersetzt wurde. OpenClaw lässt die eigenständige
Codex-Erweiterung web.run deaktiviert, da produktiver App-Server-Datenverkehr
deren benutzerdefinierten Namespace web ablehnt. tools.web.search.enabled: false
deaktiviert beide Pfade, ebenso wie reine LLM-Läufe mit deaktivierten Tools. Codex behandelt
"cached" als Präferenz und löst sie für uneingeschränkte App-Server-Turns
in einen aktiven externen Zugriff auf. Der automatische verwaltete Fallback schlägt geschlossen fehl, wenn
native allowedDomains festgelegt sind, sodass die Positivliste nicht umgangen werden kann.
Dauerhafte Änderungen der effektiven Suchrichtlinie rotieren den gebundenen Codex-Thread
vor dem nächsten Turn; vorübergehende Einschränkungen pro Turn verwenden einen temporären
eingeschränkten Thread und behalten die bestehende Bindung für eine spätere Fortsetzung bei.
sessions_yield, sessions_spawn und ausschließlich vom Nachrichten-Tool stammende Antworten bleiben
direkt, da sie Verträge zur Ablaufsteuerung oder Delegation darstellen. Die Anleitung
bevorzugt weiterhin das native spawn_agent von Codex als primäre Oberfläche für Codex-Unteragenten,
während eine explizite OpenClaw- oder ACP-Delegation weiterhin direkt über
sessions_spawn aufgerufen werden kann. Im Codex Code Mode sind generische Ergebnisse dynamischer OpenClaw-
Tools JSON-Text und keine JavaScript-Objekte. Analysieren Sie daher
wie JSON aussehende Ergebnisse, bevor Sie Felder auslesen. Codex serialisiert außerdem verschachtelte
dynamische Aufrufe. Übermitteln Sie mehrere sessions_spawn-Aufrufe in einer begrenzten Schleife,
statt zu erwarten, dass Promise.all sie gleichzeitig startet. Bereits akzeptierte
untergeordnete Prozesse können sich weiterhin zeitlich überschneiden, während spätere Aufrufe übermittelt werden. Unter
Schwarm finden Sie ein vollständiges Muster.
Anweisungen zur Heartbeat-Zusammenarbeit
weisen Codex an, vor dem Beenden eines Heartbeat-Durchlaufs nach heartbeat_respond zu suchen,
wenn das Tool noch nicht geladen ist.
Legen Sie codexDynamicToolsLoading: "direct" nur fest, wenn Sie eine Verbindung zu einem benutzerdefinierten
Codex-App-Server herstellen, der nicht nach zurückgestellten dynamischen Tools suchen kann, oder wenn Sie
die vollständige Tool-Nutzlast debuggen.
Konfigurationsfelder
Unterstützte Codex-Plugin-Felder der obersten Ebene:
Unterstützte
appServer-Felder:
appServer.networkProxy ist explizit, da es den Codex-Sandbox-Vertrag
ändert. Wenn diese Option aktiviert ist, legt OpenClaw außerdem features.network_proxy.enabled
und default_permissions in der Codex-Thread-Konfiguration fest, damit das generierte
Berechtigungsprofil das von Codex verwaltete Networking starten kann. Standardmäßig
generiert OpenClaw aus dem Profilinhalt einen kollisionsresistenten
openclaw-network-<fingerprint>-Profilnamen; verwenden Sie profileName nur, wenn ein
stabiler lokaler Name erforderlich ist.
danger-full-access wäre, verwendet die
Aktivierung von networkProxy für das generierte Berechtigungsprofil einen
Dateisystemzugriff im Workspace-Stil: Die von Codex verwaltete Netzwerkdurchsetzung
ist ein Sandbox-Networking, sodass ein Profil mit vollständigem Zugriff ausgehenden
Datenverkehr nicht schützen würde. Domaineinträge verwenden allow oder
deny; Unix-Socket-Einträge verwenden die Codex-Werte
allow oder none.
Dynamische Zeitlimits für Tool-Aufrufe
OpenClaw-eigene dynamische Tool-Aufrufe werden unabhängig vonappServer.requestTimeoutMs begrenzt: Codex-Anfragen vom Typ item/tool/call
verwenden standardmäßig einen OpenClaw-Watchdog von 90 Sekunden. Ein positives
aufrufspezifisches Argument timeoutMs verlängert oder verkürzt das Budget
dieses konkreten Tools, begrenzt auf 600000 ms. Das Tool image_generate
verwendet agents.defaults.mediaModels.image.timeoutMs, wenn der Tool-Aufruf kein eigenes Zeitlimit angibt,
andernfalls gilt für die Bilderzeugung ein Standardwert von 120 Sekunden. Das
Medienanalyse-Tool image verwendet timeoutSeconds des ausgewählten
bildfähigen Eintrags tools.media.models[] oder seinen Medienstandardwert von
60 Sekunden; bei der Bildanalyse gilt dieses Zeitlimit für die Anfrage selbst und
wird nicht durch vorherige Vorbereitungsarbeiten verkürzt. Bei einer
Zeitüberschreitung bricht OpenClaw das Tool-Signal ab, sofern dies unterstützt wird,
und gibt eine fehlgeschlagene Antwort des dynamischen Tools an Codex zurück, damit
der Turn fortgesetzt werden kann, anstatt die Sitzung in processing zu
belassen. Dieser Watchdog bildet das äußere dynamische Budget
item/tool/call; providerspezifische Anfragezeitlimits laufen innerhalb dieses
Aufrufs und behalten ihre eigene Zeitlimitsemantik bei.
Nachdem Codex einen Turn akzeptiert hat und nachdem OpenClaw auf eine
turnbezogene App-Server-Anfrage geantwortet hat, erwartet das Harness, dass Codex
im aktuellen Turn Fortschritte erzielt und den nativen Turn schließlich mit
turn/completed abschließt. Wenn der App-Server für appServer.turnCompletionIdleTimeoutMs
inaktiv bleibt, unterbricht OpenClaw nach bestem Bemühen den Codex-Turn, zeichnet
eine diagnostische Zeitüberschreitung auf und gibt die OpenClaw-Sitzungsspur frei,
damit nachfolgende Chatnachrichten nicht hinter einem veralteten nativen Turn
eingereiht werden. Die meisten nicht terminalen Benachrichtigungen desselben Turns
deaktivieren diesen kurzen Watchdog, da Codex damit nachgewiesen hat, dass der Turn
noch aktiv ist.
Tool-Übergaben verwenden ein längeres Leerlaufbudget nach dem Tool: nachdem
OpenClaw eine Antwort vom Typ item/tool/call zurückgegeben hat, nachdem native
Tool-Elemente wie commandExecution abgeschlossen wurden, nach unverarbeiteten
custom_tool_call_output-Abschlüssen sowie nach unverarbeitetem Assistentenfortschritt,
Reasoning-Abschlüssen oder Reasoning-Fortschritt nach dem Tool. Die Schutzlogik
verwendet appServer.postToolRawAssistantCompletionIdleTimeoutMs, wenn dies konfiguriert ist, und andernfalls
standardmäßig fünf Minuten; dasselbe Budget verlängert außerdem den
Fortschritts-Watchdog für das stille Synthesefenster, bevor Codex das nächste
Ereignis des aktuellen Turns ausgibt. Globale App-Server-Benachrichtigungen wie
Aktualisierungen von Ratenbegrenzungen setzen den Leerlauffortschritt des Turns
nicht zurück. Auf Reasoning-Abschlüsse, Kommentarabschlüsse vom Typ
agentMessage sowie unverarbeiteten Reasoning- oder Assistentenfortschritt vor
einem Tool kann eine automatische endgültige Antwort folgen. Daher verwenden sie
die Antwortschutzlogik nach Fortschritt, anstatt die Sitzungsspur sofort
freizugeben.
Nur abgeschlossene endgültige bzw. nicht kommentierende Elemente vom Typ
agentMessage und unverarbeitete Assistentenabschlüsse vor einem Tool
aktivieren die Freigabe nach Assistentenausgabe: Wenn Codex anschließend ohne
turn/completed inaktiv bleibt, unterbricht OpenClaw nach bestem Bemühen den
nativen Turn und gibt die Sitzungsspur frei. Wenn eine andere Turn-Überwachung
dieses Freigaberennen gewinnt, akzeptiert OpenClaw das abgeschlossene endgültige
Assistentenelement dennoch, sobald keine native Anfrage, kein Element und kein
Abschluss eines dynamischen Tools mehr aktiv ist, die Freigabe nach
Assistentenausgabe weiterhin zum zuletzt abgeschlossenen Element gehört und kein
späterer Elementabschluss vorliegt. Dadurch kann die endgültige Antwort nach
abgeschlossener Tool-Arbeit erhalten bleiben, ohne den Turn erneut auszuführen.
Partielle Assistenten-Deltas, veraltete frühere Antworten und leere spätere
Abschlüsse erfüllen die Voraussetzungen nicht.
Wiederholungssichere Fehler des stdio-App-Servers, einschließlich
Zeitüberschreitungen im Leerlauf beim Turn-Abschluss ohne Hinweise auf Assistent,
Tool, aktives Element oder Nebeneffekte, werden einmal mit einem neuen
App-Server-Versuch wiederholt. Bei unsicheren Zeitüberschreitungen wird der
hängende App-Server-Client dennoch außer Betrieb genommen und die
OpenClaw-Sitzungsspur freigegeben; außerdem wird die veraltete Bindung des nativen
Threads entfernt, anstatt sie automatisch erneut auszuführen. Zeitüberschreitungen
der Abschlussüberwachung zeigen Codex-spezifischen Zeitlimittext an: In
wiederholungssicheren Fällen wird darauf hingewiesen, dass die Antwort möglicherweise
unvollständig ist, während unsichere Fälle den Benutzer auffordern, vor einem
erneuten Versuch den aktuellen Zustand zu überprüfen. Öffentliche
Zeitüberschreitungsdiagnosen enthalten strukturelle Felder wie die Methode der
letzten App-Server-Benachrichtigung, ID/Typ/Rolle des unverarbeiteten
Assistentenantwortelements, die Anzahl aktiver Anfragen und Elemente sowie den
aktivierten Überwachungszustand. Wenn die letzte Benachrichtigung ein
unverarbeitetes Assistentenantwortelement ist, enthalten sie außerdem eine
begrenzte Vorschau des Assistententextes. Sie enthalten weder den unverarbeiteten
Prompt noch Tool-Inhalte.
Lokale Überschreibungen der Testumgebung
OPENCLAW_CODEX_APP_SERVER_BINumgeht die verwaltete Binärdatei, wennappServer.commandnicht festgelegt ist.OPENCLAW_CODEX_APP_SERVER_ARGSOPENCLAW_CODEX_APP_SERVER_MODE=yolo|guardianOPENCLAW_CODEX_APP_SERVER_APPROVAL_POLICYOPENCLAW_CODEX_APP_SERVER_SANDBOX
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.
Für wiederholbare Bereitstellungen wird die Konfiguration bevorzugt, da sie das
Plugin-Verhalten in derselben geprüften Datei wie die übrige Einrichtung des
Codex-Harness hält.
Native Codex-Plugins
Die native Unterstützung für Codex-Plugins verwendet die eigenen App- und Plugin-Funktionen des Codex-App-Servers im selben Codex-Thread wie der OpenClaw-Harness-Turn. OpenClaw übersetzt Codex-Plugins nicht in synthetische dynamische OpenClaw-Tools vom Typcodex_plugin_*.
codexPlugins wirkt sich nur auf Sitzungen aus, die das native Codex-Harness
auswählen. Es hat keine Auswirkung auf Ausführungen mit dem integrierten Harness,
normale Ausführungen des OpenAI-Providers, ACP-Konversationsbindungen oder andere
Harnesses.
Minimale migrierte Konfiguration:
codexPlugins /new oder /reset, oder starten Sie
das Gateway neu, damit zukünftige Codex-Harness-Sitzungen mit dem aktualisierten
App-Satz beginnen.
Informationen zu Migrationseignung, App-Inventar, Richtlinien für destruktive
Aktionen, Rückfragen und Diagnosen nativer Plugins finden Sie unter
Native Codex-Plugins.
Der App- und Plugin-Zugriff auf OpenAI-Seite wird durch das angemeldete
Codex-Konto und bei Business- und Enterprise/Edu-Workspaces durch die
App-Steuerung des Workspace kontrolliert. Eine Übersicht von OpenAI zur Konto- und
Workspace-Steuerung finden Sie unter
Codex mit Ihrem ChatGPT-Tarif verwenden.
Computer Use
Für Computer Use gibt es eine eigene Einrichtungsanleitung: Codex Computer Use. Kurzfassung: OpenClaw liefert die Desktop-Steuerungs-App nicht mit und führt Desktop-Aktionen nicht selbst aus. Es bereitet den Codex-App-Server vor, überprüft, ob der MCP-Servercomputer-use verfügbar ist, und überlässt Codex anschließend
während Turns im Codex-Modus die nativen MCP-Tool-Aufrufe.
Laufzeitgrenzen
Das Codex-Harness ändert nur den eingebetteten Agent-Executor auf niedriger Ebene.- Dynamische OpenClaw-Tools werden unterstützt. Codex fordert OpenClaw zur Ausführung dieser Tools auf, sodass OpenClaw Teil des Ausführungspfads bleibt.
- Codex-native Shell-, Patch-, MCP- und native App-Tools gehören Codex. OpenClaw kann ausgewählte native Ereignisse über das unterstützte Relay beobachten oder blockieren, schreibt die Argumente nativer Tools jedoch nicht um.
- Codex ist für die native Compaction zuständig. OpenClaw hält einen
Transkriptspiegel für den Kanalverlauf, die Suche,
/new,/resetsowie zukünftige Modell- oder Harness-Wechsel vor, ersetzt die Codex-Compaction jedoch nicht durch eine OpenClaw- oder Kontext-Engine-Zusammenfassung. - Medienerzeugung, Medienanalyse, TTS, Genehmigungen und Ausgaben von Messaging-Tools laufen weiterhin über die entsprechenden OpenClaw-Provider-/Modelleinstellungen.
tool_result_persistgilt für OpenClaw-eigene Transkript-Tool-Ergebnisse, nicht für Codex-native Tool-Ergebnisdatensätze.
Fehlerbehebung
Codex wird nicht als normaler/model-Provider angezeigt: Dies ist
bei neuen Konfigurationen zu erwarten. Wählen Sie ein openai/gpt-*-Modell,
aktivieren Sie plugins.entries.codex.enabled und prüfen Sie, ob plugins.allow
codex ausschließt.
OpenClaw verwendet das integrierte Harness anstelle von Codex: Vergewissern
Sie sich, dass die effektive Route exakt eine offizielle HTTPS-Route für Platform
Responses oder ChatGPT Responses ist, keine selbst definierte
Anfrageüberschreibung enthält und dass das Codex-Plugin installiert und aktiviert
ist. Das Präfix openai/gpt-* allein reicht nicht aus. Legen Sie für einen
strikten Nachweis während des Tests beim Provider oder Modell
agentRuntime.id: "codex" fest; erzwungenes Codex schlägt fehl, anstatt auf eine
Ausweichlösung zurückzugreifen, wenn die Route oder das Harness inkompatibel ist.
Die OpenAI-Codex-Laufzeit weicht auf den API-Schlüsselpfad aus: Erfassen Sie
einen redigierten Gateway-Auszug, der Modell, Laufzeit, ausgewählten Provider und
Fehler zeigt. Bitten Sie betroffene Mitwirkende, diesen schreibgeschützten Befehl
auf ihrem OpenClaw-Host auszuführen:
openai/gpt-5.6-sol oder
openai/gpt-5.6-luna, Runtime: OpenAI Codex, agentRuntime.id oder
harnessRuntime, candidateProvider: "openai" sowie ein Ergebnis vom Typ
401, Incorrect API key oder No API key. Eine korrigierte
Ausführung sollte anstelle eines einfachen Fehlers des OpenAI-API-Schlüssels den
OpenAI-OAuth-Pfad anzeigen.
Die Konfiguration enthält weiterhin veraltete Codex-Modellreferenzen: Führen Sie openclaw doctor --fix aus.
Doctor schreibt veraltete Modellreferenzen in openai/* um, entfernt überholte Laufzeit-Pins für Sitzungen und
den gesamten Agenten und behält bestehende Überschreibungen der Authentifizierungsprofile bei.
Der App-Server wird abgelehnt: Verwenden Sie über das gebündelte 0.145.0 einen stabilen Codex-App-Server aus 0.143.0.
Vorabversionen, Versionen mit Build-Suffix und neuere
nicht validierte Releases werden abgelehnt, da OpenClaw generierte Schemas
gegen die gebündelte App-Server-Version validiert.
/codex status kann keine Verbindung herstellen: Prüfen Sie, ob das Plugin codex
aktiviert ist, ob plugins.allow es enthält, wenn eine Positivliste
konfiguriert ist, und ob benutzerdefinierte appServer.command, url, authToken oder
Header gültig sind.
Der Codex-App-Server verwendet zu viel Arbeitsspeicher: Unterscheiden Sie zunächst die beiden Prozesse.
OpenClaw führt den lokalen Codex-App-Server als separaten untergeordneten Rust-Prozess aus.
NODE_OPTIONS=--max-old-space-size=... ändert nur den Node.js-V8-Heap
des Gateways; Codex wird dadurch weder begrenzt noch vergrößert. Verwaltete Gateway-Installationen wählen bereits
einen adaptiven V8-Heap, und seine Vergrößerung kann weniger Host-Arbeitsspeicher für Codex übrig lassen. Verwenden Sie
Fehlerbehebung beim Gateway-Arbeitsspeicher
bei Speicherdruck auf das Gateway und prüfen Sie den Host- oder Container-Arbeitsspeicher für den untergeordneten Codex-Prozess.
Das gebündelte Codex hat weder ein Heap- noch ein RSS-Limit und keine konfigurierbare
Verzögerung zum Entladen bei Inaktivität. Nachdem sich der letzte Client abgemeldet hat, kann ein inaktiver Thread
bis zu 30 Minuten geladen bleiben. Reduzieren Sie auf Hosts mit begrenzten Ressourcen die Auffächerung nativer Codex-Subagenten,
bevor Sie den Gateway-Heap vergrößern:
features.multi_agent_v2.max_concurrent_threads_per_session=3; das v2-
Limit schließt den Root-Thread ein und kann nicht mit agents.max_threads kombiniert werden.
Um Codex mehr Spielraum zu geben, erhöhen Sie die Arbeitsspeicherzuweisung
des Hosts, Containers oder der cgroup. Ein hartes Betriebssystemlimit kann Codex beenden, statt Gegendruck auszuüben.
Die Modellerkennung ist langsam: Verringern Sie
plugins.entries.codex.config.discovery.timeoutMs oder deaktivieren Sie die Erkennung.
Siehe Referenz zum Codex-Harness.
Der WebSocket-Transport schlägt sofort fehl: Prüfen Sie appServer.url,
authToken, die Header und ob der entfernte App-Server dieselbe Codex-
App-Server-Protokollversion verwendet. Der Codex-WebSocket-Transport bleibt experimentell
und wird nicht unterstützt; bevorzugen Sie verwaltetes stdio oder den lokalen Unix-Steuerungssocket.
Native Shell- oder Patch-Werkzeuge werden mit Native hook relay unavailable blockiert: Der Codex-Thread versucht weiterhin, eine native Hook-Relay-
ID zu verwenden, die nicht mehr bei OpenClaw registriert ist. Dies ist ein Transportproblem des nativen Codex-Hooks
und kein Fehler des ACP-Backends, Providers, von GitHub oder eines Shell-Befehls.
Starten Sie mit /new oder /reset eine neue Sitzung im betroffenen Chat
und versuchen Sie anschließend erneut einen harmlosen Befehl. Wenn dies einmal funktioniert, aber der nächste native Werkzeugaufruf
erneut fehlschlägt, behandeln Sie /new nur als vorübergehende Problemumgehung: Kopieren Sie den
Prompt nach einem Neustart des Codex-App-Servers oder
OpenClaw Gateways in eine neue Sitzung, damit alte Threads verworfen und native Hook-Registrierungen
neu erstellt werden.
Codex-Werkzeugaufrufe erzeugen zu viele kurzlebige Hook-Prozesse: Legen Sie
plugins.entries.codex.config.appServer.loopDetectionPreToolUseRelay: false fest
und starten Sie das Gateway neu. Dadurch wird nur der Codex-Unterprozess PreToolUse
deaktiviert, der für die OpenClaw-Schleifenerkennung und dessen Marker für fehlende Richtlinien verwendet wird. Erforderliche
before_tool_call und Richtlinien-Relays für vertrauenswürdige Werkzeuge bleiben aktiviert.
Ein Nicht-Codex-Modell verwendet das integrierte Harness: Dies ist zu erwarten, sofern die Laufzeitrichtlinie des Providers
oder Modells es nicht an ein anderes Harness weiterleitet. Einfache Referenzen von Nicht-OpenAI-
Providern verbleiben im Modus auto auf ihrem normalen Provider-Pfad.
Computer Use ist installiert, aber die Werkzeuge werden nicht ausgeführt: Prüfen Sie
/codex computer-use status in einer neuen Sitzung. Wenn ein Werkzeug
Native hook relay unavailable meldet, verwenden Sie die oben beschriebene Wiederherstellung des nativen Hook-Relays.
Siehe Codex Computer Use.