Codex-Harness-Referenz

Diese Referenz behandelt die detaillierte Konfiguration des offiziellen codex-Plugins. Informationen zur Einrichtung und zu Routing-Entscheidungen finden Sie zunächst unter Codex-Harness.

Plugin-Konfigurationsoberfläche

Alle Einstellungen des Codex-Harness befinden sich unter plugins.entries.codex.config.

{  plugins: {    entries: {      codex: {        enabled: true,        config: {          discovery: {            enabled: true,            timeoutMs: 2500,          },          appServer: {            mode: "guardian",          },        },      },    },  },}

Felder der obersten Ebene:

Supervision

Die Supervision listet nicht archivierte Codex-Sitzungen vom Gateway-Computer und von ausdrücklich einbezogenen gekoppelten Nodes auf. Aktivieren Sie sie unabhängig vom Agenten-Harness:

{  plugins: {    entries: {      codex: {        enabled: true,        config: {          supervision: {            enabled: true,          },        },      },    },  },}

Felder von supervision:

Endpunkteinträge akzeptieren folgende Felder:

Die Seite Codex-Sitzungen verwendet den Supervision-App-Server des Plugins und zeigt ausschließlich nicht archivierte Sitzungen an. Ohne explizite appServer-Verbindungseinstellungen handelt es sich bei dieser Verbindung um verwaltetes stdio im Benutzerverzeichnis. Gespeicherte oder inaktive lokale Zeilen können einen modellgebundenen Chat mit begrenztem Benutzer- und Assistentenverlauf bis zum letzten dauerhaft gespeicherten Quell-Turn im Endzustand erstellen. Seine private Bindung hält den Snapshot-Fork, den kanonischen aus appServer stammenden Zweig, die Verlaufsinjektion und spätere Turns auf dieser Verbindung. Beim ersten kanonischen Start wird das vom Fork zurückgegebene Paar verwendet. Bei späteren Fortsetzungen werden OpenClaw-Modell- und Provider-Überschreibungen ausgelassen, damit Codex das gespeicherte Paar des kanonischen Threads wiederherstellt. Eine separate native Änderung kann dieses Paar aktualisieren, aber das äußere Modell und die Fallback-Kette ersetzen es niemals. Gespeicherte und inaktive Zeilen können archiviert werden, nachdem bestätigt wurde, dass kein anderer Runner vorhanden ist, sofern nicht eine andere aktive OpenClaw-Bindung das exakte Ziel oder einen seiner nicht archivierten erzeugten Nachfolger besitzt. OpenClaw folgt der Nachfolger-Paginierung von Codex und beendet den Vorgang bei Aufzählungsfehlern, Zyklen oder Erschöpfung des Sicherheitslimits sicher. Die Bestätigung deckt weiterhin unbekannte native Clients und das Zeitfenster zwischen Statusprüfung und Archivierung ab. Ein über Supervision verwalteter modellgebundener Chat kann nicht gelöscht werden, solange er die native Bindung schützt. Aktive Quellen können weder einen Zweig erstellen noch archiviert werden, ein vorhandener über Supervision verwalteter Chat kann jedoch weiterhin geöffnet werden. Jede Zeile eines gekoppelten Nodes bleibt schreibgeschützt; der Node-Transport stellt den vom Harness benötigten Streaming-Lebenszyklus noch nicht bereit.

appServer.homeScope: "user" allein ändert lediglich, welches Codex-Home ein verwalteter Harness-Prozess verwendet; der Flottenkatalog wird dadurch nicht veröffentlicht. Die Aktivierung der Supervision ändert den Standardwert des Harness nicht. Stattdessen verwendet die separate Supervision-Verbindung standardmäßig verwaltetes stdio im Benutzerverzeichnis, wenn keine expliziten appServer-Verbindungseinstellungen vorhanden sind. Explizite Einstellungen werden für diese Verbindung berücksichtigt. Ausstehende und bestätigte Supervision-Bindungen behalten diese Verbindung für jeden Turn bei; bei deaktivierter Supervision oder einer Abweichung der Verbindung beziehungsweise des Lebenszyklus wird der Vorgang sicher beendet, statt auf den Harness im Agentenverzeichnis zurückzufallen. Die Standardverbindung teilt gespeicherte Sitzungen mit nativen Codex-Clients, nicht jedoch deren prozesslokalen Aktivitätsstatus.

Veraltete Einstellungen unter plugins.entries.codex-supervisor werden nicht mehr verwendet. Führen Sie openclaw doctor --fix aus, um den alten Eintrag, Endpunktdefinitionen, Richtlinien-Flags sowie Plugin-Zulassungs- und -Ausschlussreferenzen in diesen Block zu migrieren. Explizite kanonische Werte unter codex.config.supervision haben bei Konflikten Vorrang.

App-Server-Transport

Für gewöhnliche Harness-Turns startet OpenClaw die verwaltete Codex-Binärdatei, die mit dem offiziellen Plugin ausgeliefert wird (derzeit @openai/codex 0.144.1):

codex app-server --listen stdio://

Dadurch bleibt die App-Server-Version an das offizielle codex-Plugin gebunden, statt von einer beliebigen separat lokal installierten Codex-CLI abzuhängen. Legen Sie appServer.command nur fest, wenn Sie bewusst eine andere ausführbare Datei verwenden möchten. Gewöhnliche verwaltete Turns mit dem standardmäßig isolierten Agentenverzeichnis bevorzugen dieses festgelegte Paket selbst dann, wenn ein macOS-Desktop-Bundle installiert ist. Wenn Computer Use aktiviert ist oder wenn homeScope den Wert "user" hat und nativen Computer-Use-Zustand laden kann, bevorzugt der verwaltete Start stattdessen die Binärdatei der Desktop-App, die über die erforderlichen macOS-Berechtigungen verfügt. Dieselbe Regel, nach der die Desktop-App Vorrang hat, gilt, wenn die effektive Codex-Konfiguration eines isolierten Agentenverzeichnisses natives Computer Use aktiviert. Wenn kein Desktop-App-Bundle installiert ist, greift OpenClaw auf die Binärdatei des festgelegten Pakets zurück.

Die Übergabe ausführbarer Dateien und die Abschirmung der nativen Konfiguration koordinieren Clients innerhalb eines laufenden Gateway-Prozesses. Starten Sie den Gateway neu, nachdem ein anderer Prozess die native Codex-Plugin-Konfiguration geändert hat.

Die Supervision löst eine separate Verbindung auf. Ohne explizite appServer-Verbindungseinstellungen verwendet sie verwaltetes stdio mit homeScope: "user"; der gewöhnliche Harness verwendet weiterhin verwaltetes stdio mit homeScope: "agent". Explizite Verbindungseinstellungen werden von beiden Pfaden berücksichtigt. Legen Sie homeScope: "user" explizit fest, wenn der gewöhnliche Harness $CODEX_HOME (oder ~/.codex) mit nativen Clients teilen soll. Eine private Supervision-Bindung verwendet unabhängig vom Standardwert des gewöhnlichen Harness die Supervision-Verbindung. Unabhängige App-Server-Prozesse behalten getrennte Live-Status- und Genehmigungszustände bei.

Verwenden Sie für einen bereits laufenden App-Server den WebSocket-Transport:

{  plugins: {    entries: {      codex: {        enabled: true,        config: {          appServer: {            transport: "websocket",            url: "ws://gateway-host:39175",            authToken: "${CODEX_APP_SERVER_TOKEN}",            requestTimeoutMs: 60000,          },        },      },    },  },}

Felder von appServer:

appServer.networkProxy ist explizit, da es den Sandbox-Vertrag von Codex ändert. Wenn die Option aktiviert ist, setzt OpenClaw außerdem features.network_proxy.enabled und default_permissions in der Codex-Thread-Konfiguration, damit das generierte Berechtigungsprofil die von Codex verwaltete Netzwerkfunktion starten kann. OpenClaw generiert standardmäßig aus dem Profilinhalt einen kollisionsresistenten Profilnamen openclaw-network-<fingerprint>; verwenden Sie profileName nur, wenn ein stabiler lokaler Name erforderlich ist.

export default {  plugins: {    entries: {      codex: {        config: {          appServer: {            sandbox: "workspace-write",            networkProxy: {              enabled: true,              domains: {                "api.openai.com": "allow",                "blocked.example.com": "deny",              },              allowUpstreamProxy: true,              proxyUrl: "http://127.0.0.1:3128",            },          },        },      },    },  },};

Wenn die normale App-Server-Laufzeitumgebung danger-full-access wäre, verwendet die Aktivierung von networkProxy stattdessen einen Dateisystemzugriff im Workspace-Stil für das generierte Berechtigungsprofil. Die von Codex verwaltete Netzwerkdurchsetzung erfolgt über isolierte Netzwerke, sodass ein Vollzugriffsprofil ausgehenden Datenverkehr nicht schützen würde.

Das Plugin blockiert ältere oder nicht versionierte App-Server-Handshakes: Der Codex-App-Server muss die stabile Version 0.143.0 oder neuer melden.

OpenClaw behandelt WebSocket-App-Server-URLs außerhalb von local loopback als remote und erfordert eine identitätsgebundene WebSocket-Authentifizierung über appServer.authToken oder einen Authorization-Header. appServer.authToken und jeder Wert unter appServer.headers.* können ein SecretInput sein; die Secrets-Laufzeitumgebung löst SecretRefs und Env-Kurzformen auf, bevor OpenClaw die App-Server-Startoptionen erstellt, und nicht aufgelöste strukturierte SecretRefs führen zu einem Fehler, bevor ein Token oder Header gesendet wird. Wenn native Codex-Plugins konfiguriert sind, verwendet OpenClaw die Plugin-Steuerungsebene des verbundenen App-Servers, um diese Plugins zu installieren oder zu aktualisieren, und aktualisiert anschließend den App-Bestand, damit Plugin-eigene Apps für den Codex-Thread sichtbar sind. app/list bleibt die maßgebliche Quelle für Bestand und Metadaten, doch die OpenClaw-Richtlinie entscheidet, ob thread/start für eine aufgelistete, zugängliche App config.apps[appId].enabled = true sendet, selbst wenn Codex sie derzeit als deaktiviert kennzeichnet. Unbekannte oder fehlende App-IDs bleiben nach dem Fail-Closed-Prinzip gesperrt; dieser Pfad aktiviert ausschließlich Marketplace-Plugins über plugin/install und aktualisiert den Bestand. Verbinden Sie OpenClaw nur mit Remote-App-Servern, denen Sie zutrauen, von OpenClaw verwaltete Plugin-Installationen und Aktualisierungen des App-Bestands anzunehmen.

Genehmigungs- und Sandbox-Modi

Lokale stdio-App-Server-Sitzungen verwenden standardmäßig den YOLO-Modus: approvalPolicy: "never", approvalsReviewer: "user" und sandbox: "danger-full-access". Diese Haltung für vertrauenswürdige lokale Betreiber ermöglicht unbeaufsichtigten OpenClaw-Turns und Heartbeats Fortschritte ohne native Genehmigungsaufforderungen, auf die niemand antworten kann.

Wenn die lokale Systemanforderungsdatei von Codex implizite YOLO-Werte für Genehmigung, Prüfer oder Sandbox untersagt, behandelt OpenClaw stattdessen die implizite Voreinstellung als Guardian und wählt zulässige Guardian-Berechtigungen. tools.exec.mode: "auto" erzwingt ebenfalls von Guardian geprüfte Codex-Genehmigungen und behält unsichere Legacy-Überschreibungen wie approvalPolicy: "never" oder sandbox: "danger-full-access" nicht bei; legen Sie tools.exec.mode: "full" fest, wenn Sie bewusst ohne Genehmigungen arbeiten möchten. Hostnamen entsprechende [[remote_sandbox_config]]-Einträge in derselben Anforderungsdatei werden bei der Entscheidung über die Sandbox-Voreinstellung berücksichtigt.

Legen Sie appServer.mode: "guardian" für von Codex Guardian geprüfte Genehmigungen fest:

{  plugins: {    entries: {      codex: {        enabled: true,        config: {          appServer: {            mode: "guardian",            serviceTier: "priority",          },        },      },    },  },}

Die Voreinstellung guardian wird zu approvalPolicy: "on-request", approvalsReviewer: "auto_review" und sandbox: "workspace-write" erweitert, sofern diese Werte zulässig sind. Einzelne Richtlinienfelder überschreiben mode. Der ältere Prüferwert guardian_subagent wird weiterhin als Kompatibilitätsalias akzeptiert, neue Konfigurationen sollten jedoch auto_review verwenden.

Wenn eine OpenClaw-Sandbox aktiv ist, wird der lokale Codex-App-Server-Prozess weiterhin auf dem Gateway-Host ausgeführt. OpenClaw deaktiviert daher für diesen Turn den nativen Code Mode von Codex, benutzerdefinierte MCP-Server und die App-gestützte Plugin-Ausführung, anstatt die hostseitige Sandbox-Isolierung von Codex als gleichwertig mit dem OpenClaw-Sandbox-Backend zu behandeln. Shell-Zugriff wird über dynamische, vom OpenClaw-Sandbox-Backend gestützte Tools wie sandbox_exec und sandbox_process bereitgestellt, wenn die normalen Ausführungs- und Prozesstools verfügbar sind.

Native Ausführung in der Sandbox

Die stabile Voreinstellung arbeitet nach dem Fail-Closed-Prinzip: Aktive OpenClaw-Sandbox-Isolierung deaktiviert native Codex-Ausführungsoberflächen, die andernfalls auf dem Host des Codex-App-Servers ausgeführt würden. Verwenden Sie appServer.experimental.sandboxExecServer: true nur, wenn Sie die Unterstützung von Codex für Remote-Umgebungen mit dem OpenClaw-Sandbox-Backend ausprobieren möchten. Dieser Vorschaupfad funktioniert mit jeder unterstützten Codex-App-Server-Version.

{  plugins: {    entries: {      codex: {        enabled: true,        config: {          appServer: {            experimental: {              sandboxExecServer: true,            },          },        },      },    },  },}

Wenn das Flag aktiviert und die aktuelle OpenClaw-Sitzung in einer Sandbox isoliert ist, startet OpenClaw einen von der aktiven Sandbox gestützten Exec-Server über local loopback, registriert ihn beim Codex-App-Server und startet den Codex-Thread und -Turn mit dieser von OpenClaw verwalteten Umgebung. Wenn der App-Server die Umgebung nicht registrieren kann, schlägt die Ausführung nach dem Fail-Closed-Prinzip fehl, statt unbemerkt auf die Host-Ausführung zurückzufallen.

Dieser Vorschaupfad ist ausschließlich lokal verfügbar. Ein Remote-WebSocket-App-Server kann den Loopback-Exec-Server nur erreichen, wenn er auf demselben Host ausgeführt wird; daher lehnt OpenClaw diese Kombination ab.

Authentifizierungs- und Umgebungsisolation

Im standardmäßigen agentenspezifischen Home-Verzeichnis wird die Authentifizierung in dieser Reihenfolge ausgewählt:

1. Ein explizites OpenClaw-Codex-Authentifizierungsprofil für den Agenten.
2. Das vorhandene Konto des App-Servers im Codex-Home-Verzeichnis dieses Agenten.
3. Nur für lokale stdio-App-Server-Starts: CODEX_API_KEY, danach OPENAI_API_KEY, wenn kein App-Server-Konto vorhanden ist und weiterhin eine OpenAI-Authentifizierung erforderlich ist.

Wenn OpenClaw ein Codex-Authentifizierungsprofil im Stil eines ChatGPT-Abonnements erkennt – mit OAuth- oder Token-Anmeldedatentyp –, entfernt es 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 Codex-App-Server-Turns versehentlich über die API abgerechnet werden.

Explizite Codex-API-Schlüsselprofile und der Env-Schlüssel-Fallback für lokales stdio verwenden die App-Server-Anmeldung statt einer geerbten Kindprozessumgebung. WebSocket-App-Server-Verbindungen erhalten keinen Fallback auf API-Schlüssel aus der Gateway-Umgebung; verwenden Sie ein explizites Authentifizierungsprofil oder das eigene Konto des Remote-App-Servers.

Starts von stdio-App-Servern erben standardmäßig die Prozessumgebung von OpenClaw. OpenClaw verwaltet die Kontobrücke des Codex-App-Servers und setzt CODEX_HOME auf ein agentenspezifisches Verzeichnis im OpenClaw-Zustand dieses Agenten. Dadurch bleiben Codex-Konfiguration, Konten, Plugin-Cache und -Daten sowie Thread-Zustand auf den OpenClaw-Agenten beschränkt, statt aus dem persönlichen ~/.codex-Home-Verzeichnis des Betreibers übernommen zu werden.

Legen Sie appServer.homeScope: "user" fest, um nativen Codex-Zustand mit Codex Desktop und der CLI zu teilen. Dieser lokale Benutzer-Home-Modus unterstützt verwaltetes stdio und expliziten Unix-Transport. Er verwendet $CODEX_HOME, wenn es gesetzt ist, andernfalls ~/.codex, einschließlich nativer Authentifizierung, Konfiguration, Plugins und Threads. OpenClaw überspringt für den App-Server seine Authentifizierungsprofilbrücke. Verifizierte Turns des Eigentümers können mit codex_threads diese Threads auflisten – optional mit einem search-Filter –, lesen, forken, umbenennen, archivieren und aus dem Archiv wiederherstellen. Forken Sie einen Thread, bevor Sie ihn in OpenClaw fortsetzen; unabhängige Codex-Prozesse koordinieren keine gleichzeitigen Schreibzugriffe auf denselben Thread.

Diese homeScope-Aktivierung gilt für gewöhnliche Harness-Sitzungen. Ein über Codex Sessions erstellter Chat verwendet stattdessen seine private Überwachungsverbindung, wodurch die Authentifizierungs- und Provider-Konfiguration der nativen Verbindung für den kanonischen Branch und zukünftige Fortsetzungen erhalten bleibt.

In einem modellgebundenen, überwachten Chat kann codex_threads weder einen anderen Fork anhängen noch den gebundenen nativen Thread des Chats archivieren. Auflisten und ausschließlich metadatenbezogenes Lesen bleiben verfügbar. Das Lesen von Rohtranskripten erfordert allowRawTranscripts; wenn diese Option deaktiviert ist, wird auch die Listensuche abgelehnt, da die native Suche Treffer in Transkriptvorschauen finden kann. Das Umbenennen, Wiederherstellen aus dem Archiv, abgetrennte Forken und Archivieren eines nicht zugehörigen Threads, der keinem anderen OpenClaw-Chat gehört, erfordern allowWriteControls. Keine der beiden Optionen umgeht eine gesperrte Bindung.

OpenClaw schreibt HOME bei normalen lokalen App-Server-Starts nicht um. Von Codex ausgeführte Unterprozesse wie openclaw, gh, git, Cloud-CLIs und Shell-Befehle sehen das normale Prozess-Home-Verzeichnis und können Konfigurationen und Token im Benutzer-Home-Verzeichnis finden. Codex kann außerdem $HOME/.agents/skills und $HOME/.agents/plugins/marketplace.json erkennen; diese .agents-Erkennung wird bewusst mit dem Home-Verzeichnis des Betreibers geteilt und ist vom isolierten ~/.codex-Zustand getrennt.

Im standardmäßigen Agentenbereich werden OpenClaw-Plugins und OpenClaw-Skill-Snapshots weiterhin über die eigene Plugin-Registry und den Skill-Loader von OpenClaw bereitgestellt; persönliche Codex-Ressourcen aus ~/.codex dagegen nicht. Wenn Sie nützliche Skills oder Plugins der Codex CLI aus einem Codex-Home-Verzeichnis besitzen, die Teil eines isolierten OpenClaw-Agenten werden sollen, inventarisieren Sie diese explizit:

openclaw migrate codex --dry-runopenclaw migrate apply codex --yes

Wenn eine Bereitstellung 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 betrifft nur den gestarteten Kindprozess des Codex-App-Servers. OpenClaw entfernt CODEX_HOME und HOME während der Normalisierung lokaler Starts aus dieser Liste: CODEX_HOME verweist weiterhin auf den ausgewählten Agenten- oder Benutzerbereich, und HOME bleibt geerbt, damit Unterprozesse den normalen Zustand im Benutzer-Home-Verzeichnis verwenden können.

Dynamische Tools

Dynamische Codex-Tools verwenden standardmäßig das Laden über searchable, werden im Namespace openclaw mit deferLoading: true bereitgestellt. OpenClaw stellt keine dynamischen Tools bereit, die native Workspace-Operationen von Codex oder dessen eigene Tool-Suchoberfläche duplizieren:

• read
• write
• edit
• apply_patch
• exec
• process
• update_plan
• tool_call
• tool_describe
• tool_search
• tool_search_code

Die meisten verbleibenden OpenClaw-Integrationstools, etwa für Messaging, Medien, Cron, Browser, Nodes, Gateway, heartbeat_respond und web_search, sind über die Codex-Tool-Suche in diesem Namespace verfügbar. Dadurch bleibt der anfängliche Modellkontext kleiner. Eine kleine Gruppe von Tools bleibt unabhängig von codexDynamicToolsLoading direkt aufrufbar, da die Codex-Tool-Suche nicht verfügbar sein oder nur einen Connector-spezifischen Bestand auflösen kann: agents_list, sessions_spawn und sessions_yield. Entwickleranweisungen lenken normale Codex-Subagenten für Codex-native Subagentenaufgaben weiterhin zu nativem spawn_agent, während sessions_spawn für eine explizite Delegierung über OpenClaw oder ACP verfügbar bleibt. Antworten aus Quellen, die ausschließlich das Nachrichten-Tool verwenden, bleiben ebenfalls direkt, da dies ein Vertrag zur Turn-Steuerung ist.

Mit catalogMode: "direct-only" gekennzeichnete Tools, einschließlich des OpenClaw-Tools computer, werden unter openclaw_direct gruppiert. OpenClaw fügt diesen Namespace der Liste code_mode.direct_only_tool_namespaces von Codex hinzu, ohne vom Betreiber bereitgestellte Einträge zu ersetzen. Codex stellt diese Tools daher in normalen sowie ausschließlich für Code Mode vorgesehenen Threads als DirectModelOnly bereit, statt sie durch verschachtelte Code-Mode-Aufrufe von tools.* zu leiten. Diese Grenze ist für Ergebnisse mit Bildern erforderlich: Die verschachtelte Code-Mode-Serialisierung reduziert Bildausgaben auf Text, wodurch der für die nächste Computeraktion erforderliche Screenshot verloren ginge.

Legen Sie codexDynamicToolsLoading: "direct" nur fest, wenn Sie eine Verbindung zu einem benutzerdefinierten Codex-App-Server herstellen, der verzögert geladene dynamische Tools nicht durchsuchen kann, oder wenn Sie die vollständige Tool-Nutzlast debuggen.

Zeitüberschreitungen

OpenClaw-eigene dynamische Tool-Aufrufe werden unabhängig von appServer.requestTimeoutMs begrenzt. Jede Codex-Anfrage vom Typ item/tool/call verwendet das erste verfügbare Zeitlimit in dieser Reihenfolge:

• Ein positives aufrufspezifisches Argument timeoutMs.
• Für image_generate: agents.defaults.imageGenerationModel.timeoutMs.
• Für image_generate ohne konfiguriertes Zeitlimit: der Standardwert von 120 Sekunden für die Bilderzeugung.
• Für das Medienverständnis-Tool image: tools.media.image.timeoutSeconds, umgerechnet in Millisekunden, oder der Medienstandardwert von 60 Sekunden. Beim Bildverständnis gilt dies für die Anfrage selbst und wird nicht durch vorherige Vorbereitungsarbeiten verkürzt.
• Für das Tool message: ein fester Standardwert von 120 Sekunden.
• Der Standardwert von 90 Sekunden für dynamische Tools.

Dieser Watchdog bildet das äußere Budget für dynamische item/tool/call-Aufrufe. Provider-spezifische Anfragezeitlimits laufen innerhalb dieses Aufrufs und behalten ihre eigene Zeitlimitsemantik bei. Budgets für dynamische Tools sind auf 600000 ms begrenzt. 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, sodass der Turn fortgesetzt werden kann, anstatt die Sitzung im Zustand processing zu belassen.

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 beendet. 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 abschließenden Benachrichtigungen desselben Turns deaktivieren diesen kurzen Watchdog, da Codex damit nachgewiesen hat, dass der Turn noch aktiv ist. Tool-Übergaben verwenden ein längeres Inaktivitätsbudget nach einem Tool-Aufruf: nachdem OpenClaw eine item/tool/call-Antwort zurückgegeben hat, nachdem native Tool-Elemente wie commandExecution abgeschlossen wurden, nach dem Abschluss unverarbeiteter custom_tool_call_output-Elemente sowie nach unverarbeitetem Assistentenfortschritt nach einem Tool, abgeschlossenen unverarbeiteten Reasoning-Vorgängen oder Reasoning-Fortschritt. Die Überwachung verwendet appServer.postToolRawAssistantCompletionIdleTimeoutMs, wenn dies konfiguriert ist, andernfalls standardmäßig fünf Minuten. Dasselbe Budget nach einem Tool-Aufruf verlängert außerdem den Fortschritts-Watchdog für das stille Synthesefenster, bevor Codex das nächste Ereignis des aktuellen Turns ausgibt. Abgeschlossene Reasoning-Vorgänge, abgeschlossene agentMessage-Kommentarvorgänge sowie unverarbeiteter Reasoning- oder Assistentenfortschritt vor einem Tool können von einer automatischen finalen Antwort gefolgt werden. Daher verwenden sie die Antwortüberwachung nach Fortschritt, anstatt die Sitzungsspur sofort freizugeben. Nur abgeschlossene finale agentMessage-Elemente ohne Kommentar und abgeschlossene unverarbeitete Assistentenausgaben 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. Wiederholungssichere Fehler des stdio-App-Servers, einschließlich Zeitüberschreitungen beim Turn-Abschluss ohne Hinweise auf Assistentenaktivität, Tools, aktive Elemente oder Nebenwirkungen, werden einmal mit einem neuen App-Server-Versuch wiederholt. Unsichere Zeitüberschreitungen setzen den blockierten App-Server-Client dennoch außer Betrieb und geben die OpenClaw-Sitzungsspur frei. Außerdem löschen sie die veraltete Bindung des nativen Threads, anstatt automatisch wiederholt zu werden. Zeitüberschreitungen der Abschlussüberwachung zeigen Codex-spezifischen Zeitüberschreitungstext an: Bei wiederholungssicheren Fällen wird darauf hingewiesen, dass die Antwort möglicherweise unvollständig ist, während Benutzer bei unsicheren Fällen aufgefordert werden, den aktuellen Zustand vor einem erneuten Versuch zu überprüfen. Öffentliche Zeitüberschreitungsdiagnosen enthalten strukturelle Felder wie die Methode der letzten App-Server-Benachrichtigung, ID, Typ und Rolle des unverarbeiteten Assistentenantwortelements, die Anzahl aktiver Anfragen und Elemente sowie den Status der aktivierten Überwachung. Wenn die letzte Benachrichtigung ein unverarbeitetes Assistentenantwortelement ist, enthalten sie außerdem eine begrenzte Vorschau des Assistententexts. Sie enthalten keine unverarbeiteten Prompt- oder Tool-Inhalte.

Modellerkennung

Standardmäßig fragt das Codex-Plugin den App-Server nach verfügbaren Modellen. Die Modellverfügbarkeit wird vom Codex-App-Server verwaltet. Daher kann sich die Liste ändern, wenn OpenClaw die gebündelte Version von @openai/codex aktualisiert oder wenn eine Bereitstellung appServer.command auf eine andere Codex-Binärdatei verweist. Die Verfügbarkeit kann außerdem kontospezifisch sein. Verwenden Sie /codex models auf einem laufenden Gateway, um den aktuellen Katalog für dieses Harness und Konto anzuzeigen.

Wenn die Erkennung fehlschlägt oder das Zeitlimit überschreitet, verwendet OpenClaw einen gebündelten Ausweichkatalog:

Passen Sie die Erkennung unter plugins.entries.codex.config.discovery an:

{  plugins: {    entries: {      codex: {        enabled: true,        config: {          discovery: {            enabled: true,            timeoutMs: 2500,          },        },      },    },  },}

Deaktivieren Sie die Erkennung, wenn beim Start keine Codex-Abfrage erfolgen und ausschließlich der Ausweichkatalog verwendet werden soll:

{  plugins: {    entries: {      codex: {        enabled: true,        config: {          discovery: {            enabled: false,          },        },      },    },  },}

Bootstrap-Dateien des Arbeitsbereichs

Codex verarbeitet AGENTS.md selbst über die native Erkennung von Projektdokumentation. OpenClaw schreibt keine synthetischen Codex-Projektdokumentationsdateien und ist für Persona-Dateien nicht von Codex-Ausweichdateinamen abhängig, da Codex-Ausweichmechanismen nur gelten, wenn AGENTS.md fehlt.

Für die Gleichwertigkeit des OpenClaw-Arbeitsbereichs leitet das Codex-Harness die anderen Bootstrap-Dateien als Entwickleranweisungen weiter, jedoch nicht auf identische Weise:

• TOOLS.md wird als vererbte Codex-Entwickleranweisung weitergeleitet, sodass native Codex-Unteragenten, die während des Turns gestartet werden, sie ebenfalls sehen.
• SOUL.md, IDENTITY.md und USER.md werden als turnbezogene Anweisungen zur Zusammenarbeit weitergeleitet. Native Codex-Unteragenten erben sie nicht. Dadurch übernehmen Unteragenten-Turns weder die Persona noch das Benutzerprofil des übergeordneten Agenten.
• Die kompakte Liste geladener OpenClaw-Skills wird ebenfalls als turnbezogene Entwickleranweisung zur Zusammenarbeit weitergeleitet, sodass native Codex-Unteragenten sie ebenfalls nicht erben.
• Der Inhalt von HEARTBEAT.md wird nicht eingefügt. Heartbeat-Turns erhalten einen Hinweis im Zusammenarbeitsmodus, die Datei zu lesen, wenn sie vorhanden und nicht leer ist.
• Der Inhalt von MEMORY.md aus dem konfigurierten Agentenarbeitsbereich wird nicht in die native Codex-Turn-Eingabe eingefügt, wenn für diesen Arbeitsbereich Speicher-Tools verfügbar sind. Wenn die Datei vorhanden ist, fügt das Harness den turnbezogenen Entwickleranweisungen zur Zusammenarbeit einen kurzen Hinweis zum Arbeitsbereichsspeicher hinzu, und Codex sollte memory_search oder memory_get verwenden, wenn dauerhafter Speicher relevant ist. Wenn Tools deaktiviert sind, die Speichersuche nicht verfügbar ist oder sich der aktive Arbeitsbereich vom Agentenspeicher-Arbeitsbereich unterscheidet, verwendet MEMORY.md stattdessen den normalen begrenzten Turn-Kontextpfad.
• BOOTSTRAP.md wird, sofern vorhanden, als Referenzkontext der OpenClaw-Turn-Eingabe weitergeleitet.

Umgebungsüberschreibungen

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 festgelegt 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. Für wiederholbare Bereitstellungen wird die Konfiguration bevorzugt, da sie das Plugin-Verhalten in derselben überprüften Datei wie die übrige Einrichtung des Codex-Harness festhält.

Verwandte Themen

• Codex-Harness
• Codex-Harness-Laufzeit
• Codex-Überwachung
• Native Codex-Plugins
• Codex-Computersteuerung
• OpenAI-Provider
• Konfigurationsreferenz