Codex-Harness-Laufzeit

Laufzeitvertrag für Codex-Harness-Turns. Informationen zu Einrichtung und Routing finden Sie unter Codex-Harness. Informationen zu Konfigurationsfeldern finden Sie in der Codex-Harness-Referenz.

Überblick

Codex übernimmt die native Modellschleife, das native Fortsetzen von Threads, die native Fortsetzung von Tools und die native Compaction. OpenClaw übernimmt das Channel-Routing, Sitzungsdateien, die sichtbare Nachrichtenzustellung, dynamische OpenClaw-Tools, Genehmigungen, die Medienzustellung und eine Transkriptspiegelung um diese Grenze herum.

Das Prompt-Routing richtet sich nach der ausgewählten Laufzeit, nicht nur nach der Provider-Zeichenfolge. Ein nativer Codex-Turn erhält die Entwickleranweisungen des Codex App Server; eine explizite OpenClaw-Kompatibilitätsroute behält den normalen OpenClaw-System-Prompt bei, selbst wenn sie Codex-spezifische OpenAI-Authentifizierung oder -Übertragung verwendet.

OpenClaw startet native Codex-Threads und setzt sie fort, wobei die integrierte Persönlichkeit von Codex deaktiviert ist (personality: "none"), damit Persönlichkeitsdateien des Arbeitsbereichs und die OpenClaw-Agentenidentität maßgeblich bleiben. Native Codex-Ausführungen behalten ansonsten die Codex-eigenen Basis-/Modellanweisungen und das Laden der Projektdokumentation bei. Leichtgewichtige OpenClaw-Ausführungen (beispielsweise Cron) unterdrücken weiterhin das Laden der Projektdokumentation.

Die OpenClaw-Entwickleranweisungen decken Belange der OpenClaw-Laufzeit ab: Zustellung über den Quell-Channel, dynamische OpenClaw-Tools, ACP-Delegierung, Adapterkontext und die aktiven Arbeitsbereichsprofildateien des Agenten. Skill-Kataloge und über Tools weitergeleitete MEMORY.md-Verweise werden als auf den Turn beschränkte Entwickleranweisungen zur Zusammenarbeit projiziert. Wenn Speicher-Tools nicht verfügbar sind, werden aktive BOOTSTRAP.md-Inhalte und vollständige MEMORY.md stattdessen als einfacher Turn-Eingabekontext bereitgestellt.

Die meisten dynamischen OpenClaw-Tools verwenden den durchsuchbaren openclaw-Namespace. Mit catalogMode: "direct-only" gekennzeichnete Tools verwenden openclaw_direct, das Codex direkt als DirectModelOnly für das Modell sichtbar hält, statt es einer verschachtelten Code-Mode-Ausführung zugänglich zu machen.

Thread-Bindungen und Modellwechsel

Wenn eine OpenClaw-Sitzung an einen bestehenden Codex-Thread angehängt ist, sendet der nächste Turn das aktuell ausgewählte Modell, die Genehmigungsrichtlinie, die Sandbox, den Genehmigungsprüfer und die Dienststufe erneut an den App Server. Ein Wechsel von openai/gpt-5.5 zu openai/gpt-5.2 behält die Thread-Bindung bei, fordert Codex jedoch auf, mit dem neu ausgewählten Modell fortzufahren.

Überwachte Bindungen bilden die Ausnahme. Die OpenClaw-Modellauswahl bleibt gesperrt, und beim Fortsetzen werden Modell- und Provider-Überschreibungen ausgelassen, damit Codex das persistierte Modell und den Provider des kanonischen Threads wiederherstellt. Eine separate native Codex-Steuerung kann dieses persistierte Paar ändern, und der anfängliche Snapshot kann die normale Codex-Warnung zu Modellunterschieden auslösen; das äußere OpenClaw-Modell und die Fallback-Kette ersetzen keines der beiden.

Überwachung und sichere Fortsetzung

Die Codex-Überwachung ist eine optionale Funktion desselben codex-Plugins. Sie erkennt native Threads über eine separate Verbindung und projiziert nur nicht archivierte Sitzungen in den Gateway-Katalog. Ohne explizite appServer-Verbindungseinstellungen verwendet diese Verbindung verwaltete stdio-Kommunikation im Benutzerverzeichnis, während das gewöhnliche Harness agentenspezifisch bleibt. Auflistungs- und Metadaten-Lesevorgänge sind passiv: Sie setzen keinen Thread fort, abonnieren OpenClaw nicht für dessen Live-Ereignisse und beantworten keine Genehmigungsanfragen.

Für eine gespeicherte oder inaktive Sitzung auf dem Gateway-Computer erstellt Als Branch fortsetzen einen normalen, modellgebundenen Chat und spiegelt einen begrenzten Verlauf von Benutzer- und Assistentennachrichten bis einschließlich des letzten terminalen persistierten Turns der Quelle. Der erste normale Chat-Turn installiert die tatsächlichen Genehmigungs-Handler und verwendet einen temporären nativen Fork, um den Snapshot ohne Modell- oder Provider-Überschreibung festzuhalten. Codex App Server verwendet seine aktuelle native Konfiguration und gibt das ausgewählte Paar zurück; er gibt seine normale Warnung aus, wenn dieses Modell vom zuletzt aufgezeichneten Modell der Quelle abweicht. Über dieselbe Überwachungsverbindung startet OpenClaw den kanonischen Codex-Harness-Thread der appServer-Quelle unter dessen Arbeitsverzeichnis und Laufzeitrichtlinie mit genau dem zurückgegebenen Modell und Provider für diesen ersten Start, fügt den begrenzten sichtbaren Verlauf ein und archiviert den temporären Fork. Die Quelle wird niemals fortgesetzt. Der kanonische Thread verfügt über die vollständige Tool-Oberfläche des OpenClaw-Harness; Reasoning, Tool-Aufrufe und Tool-Ergebnisse aus der Quelle werden nicht in ihn kopiert. Der private Verbindungsbereich bleibt über ausstehende und festgeschriebene Bindungszustände hinweg bestehen, sodass jeder spätere Turn mit nativer Authentifizierung und Provider-Konfiguration über diese Verbindung verbleibt. Deaktivierte Überwachung oder eine Abweichung der Bindung bzw. Verbindung führt zu einem sicheren Abbruch, statt zum gewöhnlichen Harness im Agentenverzeichnis zu wechseln.

Die ursprüngliche CLI-, VS-Code-, Atlas- oder ChatGPT-Quelle bleibt für beide Kataloge geeignet. Der kanonische Branch ist ein nativer Codex-Thread, seine Quellart lautet jedoch appServer; native Clients können diese Quellart herausfiltern, sodass sein Erscheinen in Codex Desktop nicht garantiert ist.

Aktive Quellen können weder einen neuen Branch starten noch archiviert werden; ein vorhandener überwachter Chat kann weiterhin geöffnet werden. notLoaded bedeutet, dass die Aktivität unbekannt und nicht inaktiv ist; OpenClaw erlaubt die Archivierung einer lokalen idle- oder notLoaded-Zeile erst nach einer expliziten Bestätigung, dass keine andere Ausführung läuft, und einer aktuellen prozesslokalen Statusabfrage. Codex serialisiert Thread-Mutationen innerhalb eines App-Server-Prozesses, stellt jedoch keine exklusive prozessübergreifende Lease für Ausführungen oder Genehmigungsverantwortliche bereit, sodass diese Abfrage nicht beweisen kann, dass kein anderer Prozess den Thread verwendet. OpenClaw blockiert einen bekannten aktiven Bindungsverantwortlichen für das exakte Ziel oder jeden nicht archivierten erzeugten Nachfolger, den die paginierte Codex-Nachfolgerabfrage zurückgibt. Aufzählungsfehler, Zyklen und das Ausschöpfen von Sicherheitsgrenzen führen zu einem sicheren Abbruch. Die native Archivierung kann weiterhin mit einem neuen Turn in einem anderen Prozess kollidieren, daher deckt die Bestätigung unbekannte Clients und die Lücke zwischen Statusabfrage und Archivierung ab. Ein überwachter modellgebundener Chat kann nicht gelöscht werden, solange er die native Bindung schützt.

Kataloge gekoppelter Nodes bleiben in der ersten Version reine Metadatenkataloge. Die aktuelle Node-Aufrufgrenze arbeitet nach dem Anfrage-/Antwortprinzip und kann die langlebigen Turn-Ereignisse, Genehmigungsanfragen oder Streaming-Ausgaben nicht übertragen, die eine echte Codex-Harness-Bindung erfordert. Die entfernten Aktionen Fortsetzen und Archivieren bleiben daher auch dann nicht verfügbar, wenn die Zeile inaktiv ist.

Informationen zur Einrichtung durch Betreiber und zum sichtbaren Verhalten der Control UI finden Sie unter Codex-Überwachung.

Sichtbare Antworten und Heartbeats

Direkte bzw. Quell-Chat-Turns über das Codex-Harness verwenden standardmäßig die automatische abschließende Assistentenzustellung für interne WebChat-Oberflächen und entsprechen damit dem Vertrag des Pi-Harness: Der Agent antwortet normal, und OpenClaw veröffentlicht den abschließenden Text in der Quellkonversation. Setzen Sie messages.visibleReplies: "message_tool", um den abschließenden Assistententext privat zu halten, sofern der Agent nicht message(action="send") aufruft.

Codex-Heartbeat-Turns erhalten standardmäßig heartbeat_respond im durchsuchbaren OpenClaw-Tool-Katalog, damit der Agent festhalten kann, ob der Weckvorgang still bleiben oder eine Benachrichtigung auslösen soll. Hinweise zur Heartbeat-Initiative werden als Entwickleranweisung für den Codex-Zusammenarbeitsmodus gesendet, die auf den Heartbeat-Turn beschränkt ist; gewöhnliche Chat-Turns verbleiben im Codex-Standardmodus. Wenn HEARTBEAT.md nicht leer ist, verweisen die Heartbeat-Anweisungen Codex auf die Datei, statt deren Inhalt direkt einzubetten.

Hook-Grenzen

OpenClaw verwendet keine projektbezogenen oder globalen Codex-hooks.json-Dateien, um Plugin-Verhalten zu routen. Für die Brücke für native Tools und Berechtigungen injiziert OpenClaw eine Codex-Konfiguration pro Thread für PreToolUse, PostToolUse, PermissionRequest und Stop.

Wenn Codex-App-Server-Genehmigungen aktiviert sind (approvalPolicy ist nicht "never"), lässt die standardmäßig injizierte native Hook-Konfiguration PermissionRequest aus, damit der App-Server-Prüfer von Codex und die OpenClaw-Genehmigungsbrücke echte Eskalationen nach der Prüfung bearbeiten. Fügen Sie permission_request zu nativeHookRelay.events hinzu, um die Kompatibilitätsweiterleitung dennoch zu erzwingen. Andere Codex- Hooks wie SessionStart und UserPromptSubmit bleiben Steuerungen auf Codex-Ebene; sie werden im v1-Vertrag nicht als OpenClaw-Plugin-Hooks bereitgestellt.

Bei dynamischen OpenClaw-Tools führt OpenClaw das Tool aus, nachdem Codex den Aufruf angefordert hat, sodass Plugin- und Middleware-Verhalten im Harness-Adapter ausgeführt wird. Codex Code Mode empfängt generische dynamische Ergebnisse als Text und serialisiert verschachtelte dynamische Aufrufe; Aufrufer müssen JSON-ähnliche Ergebnisse analysieren und können sich bei der gleichzeitigen Übermittlung nicht auf Promise.all verlassen. Bei Codex-nativen Tools verwaltet Codex den kanonischen Tool-Datensatz; OpenClaw kann ausgewählte Ereignisse spiegeln, den nativen Thread jedoch nicht umschreiben, sofern Codex dies nicht über App-Server- oder native Hook- Callbacks verfügbar macht.

PreToolUse-Ereignisse im Berichtsmodus des Codex App Server verschieben die Plugin-Genehmigung auf die entsprechende App-Server-Genehmigung. Wenn ein OpenClaw-before_tool_call-Hook requireApproval zurückgibt, während die native Nutzlast openclaw_approval_mode: "report" setzt, zeichnet die native Hook-Weiterleitung die Plugin-Genehmigungsanforderung auf und gibt keine native Entscheidung zurück. Wenn Codex später die App-Server-Genehmigungsanfrage für dieselbe Tool-Verwendung sendet, öffnet OpenClaw die Plugin-Genehmigungsaufforderung und ordnet die Entscheidung Codex zu. Codex-PermissionRequest-Ereignisse bilden einen separaten Genehmigungspfad und können weiterhin über OpenClaw-Genehmigungen geroutet werden, wenn diese Brücke entsprechend konfiguriert ist.

Elementbenachrichtigungen des Codex App Server stellen außerdem asynchrone after_tool_call- Beobachtungen für Abschlüsse nativer Tools bereit, die noch nicht von der nativen PostToolUse-Weiterleitung abgedeckt werden. Diese dienen ausschließlich der Telemetrie und Kompatibilität; sie können den nativen Tool-Aufruf weder blockieren, verzögern noch verändern.

Compaction- und LLM-Lebenszyklusprojektionen stammen aus Benachrichtigungen des Codex App Server und dem Zustand des OpenClaw-Adapters, nicht aus nativen Codex-Hook-Befehlen. before_compaction, after_compaction, llm_input und llm_output sind Beobachtungen auf Adapterebene und keine bytegenauen Erfassungen der internen Anfrage- oder Compaction-Nutzlasten von Codex.

Native Codex-App-Server-Benachrichtigungen hook/started und hook/completed werden als codex_app_server.hook-Agentenereignisse für Verlauf und Debugging projiziert. Sie rufen keine OpenClaw-Plugin-Hooks auf.

v1-Unterstützungsvertrag

In Codex-Laufzeit v1 unterstützt:

In Codex-Laufzeit v1 nicht unterstützt:

Native Berechtigungen und MCP-Abfragen

Für PermissionRequest gibt OpenClaw nur dann ausdrückliche Zulassen- oder Ablehnen- Entscheidungen zurück, wenn die Richtlinie eine Entscheidung trifft. Ein Ergebnis ohne Entscheidung ist keine Zulassung: Codex behandelt es als fehlende Hook-Entscheidung und greift auf den eigenen Guardian- oder Benutzer- Genehmigungspfad zurück.

In den Genehmigungsmodi des Codex-App-Servers wird dieser native Hook standardmäßig ausgelassen. Dies gilt, sofern permission_request nicht ausdrücklich in nativeHookRelay.events enthalten ist oder eine Kompatibilitätslaufzeit ihn installiert.

Wenn ein Betreiber allow-always für eine native Codex-Berechtigungs- anfrage auswählt, merkt sich OpenClaw diesen exakten Fingerabdruck aus Provider/Sitzung/Tool-Eingabe/cwd für ein begrenztes Sitzungszeitfenster. Die gespeicherte Entscheidung gilt absichtlich nur bei exakter Übereinstimmung: Ein geänderter Befehl, geänderte Argumente, Tool-Nutzdaten oder ein geändertes cwd führen zu einer neuen Genehmigung.

Genehmigungsabfragen für Codex-MCP-Tools werden über den Plugin-Genehmigungs- ablauf von OpenClaw geleitet, wenn Codex _meta.codex_approval_kind als "mcp_tool_call" kennzeichnet. Codex request_user_input registriert eine providerneutrale Gateway-Frage für die ursprüngliche Sitzung. Die Control UI zeigt die Gateway-Fragekarte an, und eine einzelne nicht geheime Auswahl verwendet typisierte Kanalschaltflächen, wenn der Kanal sie unterstützt. Das Antippen einer Schaltfläche, Antworten in der Control UI und die nächste in der Warteschlange befindliche Klartextantwort lösen alle denselben Gateway-Datensatz auf, bevor OpenClaw die App-Server-Antwort zurückgibt. Die automatische Auflösung durch Codex und abgebrochene Versuche begrenzen die Wartezeit und brechen den Datensatz ab. Geheime Fragen verbleiben vollständig im mit einer Warnung versehenen Pfad für Textantworten. Andere MCP- Abfrageanfragen werden sicher abgelehnt.

Den allgemeinen Plugin-Genehmigungsablauf, der diese Aufforderungen überträgt, finden Sie unter Plugin-Berechtigungsanfragen.

Warteschlangensteuerung

Die Steuerung der Warteschlange aktiver Ausführungen wird Codex app-server turn/steer zugeordnet. Mit dem standardmäßigen messages.queue.mode: "steer" bündelt OpenClaw Chatnachrichten im Steuerungsmodus für das konfigurierte Ruhefenster und sendet sie in der Reihenfolge ihres Eingangs als eine turn/steer- Anfrage.

Codex-Reviews und manuelle Compaction-Durchläufe können die Steuerung im selben Durchlauf ablehnen. In diesem Fall wartet OpenClaw, bis die aktive Ausführung abgeschlossen ist, bevor der Prompt gestartet wird. Verwenden Sie /queue followup oder /queue collect, wenn Nachrichten standardmäßig in die Warteschlange eingereiht statt zur Steuerung verwendet werden sollen. Siehe Steuerungswarteschlange.

Hochladen von Codex-Feedback

Wenn /diagnostics [note] für eine Sitzung im nativen Codex- Harness genehmigt wird, ruft OpenClaw für relevante Codex-Threads zusätzlich Codex app-server feedback/upload auf, einschließlich Protokollen für jeden aufgeführten Thread und erzeugte Codex- Unterthreads, sofern verfügbar.

Das Hochladen erfolgt über den regulären Feedbackpfad von Codex zu den OpenAI-Servern. Wenn Codex-Feedback in diesem app-server deaktiviert ist, gibt der Befehl den app-server-Fehler zurück. Die Antwort der abgeschlossenen Diagnose führt die Kanäle, OpenClaw-Sitzungs-IDs, Codex-Thread-IDs und lokalen codex resume <thread-id>- Befehle für die gesendeten Threads auf.

Wenn Sie die Genehmigung verweigern oder ignorieren, gibt OpenClaw diese Codex-IDs nicht aus und sendet kein Codex-Feedback. Das Hochladen ersetzt nicht den lokalen Export der Gateway-Diagnose. Informationen zu Genehmigung, Datenschutz, lokalem Paket und Verhalten in Gruppenchats finden Sie unter Diagnoseexport.

Verwenden Sie /codex diagnostics [note] nur, wenn Sie Codex-Feedback für den aktuell angehängten Thread ohne das vollständige Gateway-Diagnosepaket hochladen möchten.

Compaction und Transkriptspiegel

Wenn das ausgewählte Modell das Codex-Harness verwendet, gehört die native Thread-Compaction zum Codex app-server. OpenClaw führt für Codex-Durchläufe keine Compaction vorab aus, ersetzt die Codex-Compaction nicht durch die Compaction der Kontext-Engine und greift nicht auf eine Zusammenfassung durch OpenClaw oder die öffentliche OpenAI-Schnittstelle zurück, wenn die native Compaction nicht gestartet werden kann. OpenClaw verwaltet einen Transkriptspiegel für den Kanalverlauf, die Suche, /new, /reset und zukünftige Wechsel des Modells oder Harness.

Explizite Compaction-Anfragen wie /compact oder ein von einem Plugin angeforderter manueller Compaction-Vorgang starten die native Codex-Compaction mit thread/compact/start. OpenClaw hält die Anfrage und die Lease des gemeinsam verwendeten Clients offen, bis Codex das zugehörige Abschlusselement contextCompaction ausgibt, und meldet den Compaction- Durchlauf anschließend als abgeschlossen. Wenn dieser abschließende Durchlauf das konfigurierte Compaction- Zeitlimit überschreitet, fordert OpenClaw eine native Unterbrechung des Durchlaufs an. Die Lease und die Thread-spezifische Compaction-Sperre bleiben bestehen, bis Codex den Endzustand meldet oder den Unterbrechungs-RPC bestätigt. Wenn Codex dies nicht innerhalb der Kulanzfrist für die Unterbrechung bestätigt, nimmt OpenClaw die Verbindung außer Betrieb, bevor die Sperre aufgehoben wird. Bei Remote- Verbindungen wird außerdem die zugehörige Thread-Bindung getrennt, damit spätere Arbeiten nicht mit einem unbestätigten Remote-Durchlauf überlappen können. Andere Durchläufe auf einer außer Betrieb genommenen Verbindung schlagen fehl und können mit einem neuen Client wiederholt werden. Das Schließen des Clients, der Abbruch der Anfrage oder ein fehlgeschlagener Compaction-Durchlauf führt zu einem fehlgeschlagenen Vorgang. Die automatische Compaction bei Kontextdruck ist Aufgabe von Codex; OpenClaw startet die native Compaction nur bei manuell angeforderten Auslösern.

Wenn eine Kontext-Engine die Thread-Bootstrap-Projektion für Codex anfordert, projiziert OpenClaw Namen und IDs von Tool-Aufrufen, Eingabeformen und redigierte Inhalte von Tool-Ergebnissen in den neuen Codex-Thread. Die Rohwerte der Argumente von Tool-Aufrufen werden nicht in diese Projektion kopiert.

Der Spiegel umfasst den Benutzer-Prompt, den endgültigen Assistententext und kompakte Codex-Datensätze zu Gedankengängen oder Plänen, wenn der app-server sie ausgibt. OpenClaw zeichnet den Beginn und den Endstatus der nativen Compaction auf, stellt jedoch weder eine für Menschen lesbare Compaction-Zusammenfassung noch eine überprüfbare Liste der Einträge bereit, die Codex nach der Compaction beibehalten hat.

Da Codex Eigentümer des kanonischen nativen Threads ist, schreibt tool_result_persist Codex-native Tool-Ergebnisdatensätze nicht um. Dies gilt nur, wenn OpenClaw ein Tool-Ergebnis in ein OpenClaw-eigenes Sitzungstranskript schreibt.

Medien und Zustellung

OpenClaw ist weiterhin für die Medienzustellung und die Auswahl des Medien-Providers zuständig. Bild-, Video-, Musik-, PDF- und TTS-Funktionen sowie das Medienverständnis verwenden entsprechende Provider-/Modell- Einstellungen wie agents.defaults.mediaModels.image, agents.defaults.mediaModels.video, pdfModel und tts.

Text, Bilder, Video, Musik, TTS, Genehmigungen und Ausgaben von Messaging-Tools werden weiterhin über den regulären Zustellungspfad von OpenClaw verarbeitet; die Mediengenerierung erfordert die Legacy-Laufzeit nicht. Wenn Codex ein natives Bildgenerierungselement mit einem savedPath ausgibt, leitet OpenClaw genau diese Datei über den regulären Antwortmedien- Pfad weiter, selbst wenn der Codex-Durchlauf keinen Assistententext enthält.

Verwandte Themen

• Codex-Harness
• Codex-Harness-Referenz
• Codex-Überwachung
• Native Codex-Plugins
• Plugin-Hooks
• Agent-Harness-Plugins
• Diagnoseexport
• Trajektorienexport