Codex-Harness-Laufzeit

Documentation Index

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

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

Diese Seite dokumentiert den Laufzeitvertrag für Codex-Harness-Turns. Für Einrichtung und Routing beginnen Sie mit Codex-Harness. Informationen zu Konfigurationsfeldern finden Sie in der Codex-Harness-Referenz.

​

Überblick

Der Codex-Modus ist nicht PI mit einem anderen Modellaufruf darunter. Codex übernimmt mehr von der nativen Modellschleife, und OpenClaw passt seine Plugin-, Tool-, Sitzungs- und Diagnoseoberflächen an diese Grenze an. OpenClaw besitzt weiterhin Kanal-Routing, Sitzungsdateien, sichtbare Nachrichtenzustellung, dynamische OpenClaw-Tools, Genehmigungen, Medienzustellung und eine Transkriptspiegelung. Codex besitzt den kanonischen nativen Thread, die native Modellschleife, die native Tool- Fortsetzung und native Compaction.

​

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 OpenAI-Modell, die Genehmigungsrichtlinie, die Sandbox und die Service- Stufe erneut an app-server. Der Wechsel von openai/gpt-5.5 zu openai/gpt-5.2 behält die Thread-Bindung bei, weist Codex aber an, mit dem neu ausgewählten Modell fortzufahren.

​

Sichtbare Antworten und Heartbeats

Wenn ein Quell-Chat-Turn über den Codex-Harness läuft, verwenden sichtbare Antworten standardmäßig das OpenClaw-Tool message, sofern die Bereitstellung messages.visibleReplies nicht explizit konfiguriert hat. Der Agent kann seinen Codex-Turn weiterhin privat beenden; er postet nur dann in den Kanal, wenn er message(action="send") aufruft. Setzen Sie messages.visibleReplies: "automatic", um finale Direct-Chat-Antworten auf dem älteren automatischen Zustellpfad zu belassen. Codex-Heartbeat-Turns erhalten standardmäßig auch heartbeat_respond im durchsuchbaren OpenClaw- Toolkatalog, sodass der Agent aufzeichnen kann, ob das Aufwachen still bleiben oder benachrichtigen soll, ohne diesen Kontrollfluss im finalen Text zu codieren. Heartbeat-spezifische Initiativanweisungen werden als Codex-Developer-Anweisung im Kollaborationsmodus auf dem Heartbeat-Turn selbst gesendet. Normale Chat-Turns stellen stattdessen den Codex-Standardmodus wieder her, anstatt Heartbeat-Philosophie in ihrem normalen Laufzeit-Prompt mitzuführen.

​

Hook-Grenzen

Der Codex-Harness hat drei Hook-Ebenen: OpenClaw verwendet keine projektbezogenen oder globalen Codex-hooks.json-Dateien, um OpenClaw-Plugin-Verhalten zu routen. Für die unterstützte Brücke für native Tools und Berechtigungen injiziert OpenClaw Codex-Konfiguration pro Thread für PreToolUse, PostToolUse, PermissionRequest und Stop. Wenn Codex-app-server-Genehmigungen aktiviert sind, also approvalPolicy nicht "never" ist, lässt die standardmäßig injizierte native Hook-Konfiguration PermissionRequest aus, damit der Codex-app-server-Prüfer und die OpenClaw-Genehmigungsbrücke echte Eskalationen nach der Prüfung verarbeiten. Betreiber können permission_request explizit zu nativeHookRelay.events hinzufügen, wenn sie den Kompatibilitäts-Relay benötigen. Andere Codex-Hooks wie SessionStart und UserPromptSubmit bleiben Codex-seitige Steuerungen. Sie werden im v1-Vertrag nicht als OpenClaw-Plugin-Hooks bereitgestellt. Für dynamische OpenClaw-Tools führt OpenClaw das Tool aus, nachdem Codex den Aufruf angefordert hat, sodass OpenClaw das Plugin- und Middleware-Verhalten, das es besitzt, im Harness-Adapter auslöst. Bei Codex-nativen Tools besitzt Codex den kanonischen Tool-Datensatz. OpenClaw kann ausgewählte Ereignisse spiegeln, aber es kann den nativen Codex-Thread nicht umschreiben, es sei denn, Codex stellt diese Operation über app-server oder native Hook-Callbacks bereit. Compaction- und LLM-Lebenszyklus-Projektionen stammen aus Codex-app-server-Benachrichtigungen und dem OpenClaw-Adapterzustand, nicht aus nativen Codex-Hook-Befehlen. Die OpenClaw-Ereignisse before_compaction, after_compaction, llm_input und llm_output sind Beobachtungen auf Adapterebene, 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-Agent-Ereignisse für Trajektorie und Debugging projiziert. Sie rufen keine OpenClaw-Plugin-Hooks auf.

​

V1-Supportvertrag

Unterstützt in Codex-Laufzeit v1: Nicht unterstützt in Codex-Laufzeit v1:

​

Native Berechtigungen und MCP-Elicitations

Für PermissionRequest gibt OpenClaw nur dann explizite Zulassen- oder Ablehnen-Entscheidungen zurück, wenn die Richtlinie entscheidet. Ein Ergebnis ohne Entscheidung ist keine Zulassung. Codex behandelt es als keine Hook-Entscheidung und fällt auf seinen eigenen Guardian- oder Benutzergenehmigungspfad zurück. Codex-app-server-Genehmigungsmodi lassen diesen nativen Hook standardmäßig aus. Dieses Verhalten gilt, wenn permission_request explizit in nativeHookRelay.events aufgenommen wird oder eine Kompatibilitätslaufzeit ihn installiert. Wenn ein Operator für eine native Codex-Berechtigungsanfrage allow-always auswählt, merkt sich OpenClaw diesen exakten Provider-/Sitzungs-/Tool-Eingabe-/cwd-Fingerabdruck für ein begrenztes Sitzungsfenster. Die gemerkte Entscheidung ist absichtlich nur ein exakter Treffer: Ein geänderter Befehl, geänderte Argumente, eine geänderte Tool-Nutzlast oder ein geändertes cwd erzeugt eine neue Genehmigung. Genehmigungsaufforderungen für Codex MCP-Tools werden über den Plugin-Genehmigungsablauf von OpenClaw geleitet, wenn Codex _meta.codex_approval_kind als "mcp_tool_call" markiert. Codex-request_user_input-Prompts werden an den ursprünglichen Chat zurückgesendet, und die nächste eingereihte Folgenachricht beantwortet diese native Serveranforderung, statt als zusätzlicher Kontext gesteuert zu werden. Andere MCP-Elicitation- Anfragen schlagen standardmäßig geschlossen fehl.

​

Warteschlangensteuerung

Die Warteschlangensteuerung während eines aktiven Laufs wird auf turn/steer des Codex-App-Servers abgebildet. Mit dem Standardwert messages.queue.mode: "steer" bündelt OpenClaw eingereihte Chatnachrichten für das konfigurierte Ruhefenster und sendet sie in Eingangsreihenfolge als eine turn/steer-Anfrage. Der Legacy-Modus queue sendet separate turn/steer-Anfragen. Codex-Review- und manuelle Compaction-Turns können Steuerung im selben Turn ablehnen. In diesem Fall verwendet OpenClaw die Folgewarteschlange, wenn der ausgewählte Modus einen Fallback erlaubt. Siehe Steuerungswarteschlange.

​

Codex-Feedback-Upload

Wenn /diagnostics [note] für eine Sitzung genehmigt wird, die den nativen Codex- Harness verwendet, ruft OpenClaw außerdem feedback/upload des Codex-App-Servers für relevante Codex-Threads auf. Der Upload fordert den App-Server auf, Protokolle für jeden aufgeführten Thread und für erzeugte Codex-Unterthreads einzuschließen, sofern verfügbar. Der Upload läuft über den normalen Codex-Feedbackpfad zu OpenAI-Servern. Wenn Codex- Feedback in diesem App-Server deaktiviert ist, gibt der Befehl den App-Server- Fehler zurück. Die abgeschlossene Diagnosereply listet 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 ablehnen oder ignorieren, gibt OpenClaw diese Codex-IDs nicht aus und sendet kein Codex-Feedback. Der Upload ersetzt nicht den lokalen Gateway- Diagnoseexport. Siehe Diagnoseexport für Genehmigung, Datenschutz, lokales Bundle und Gruppenchat-Verhalten. Verwenden Sie /codex diagnostics [note] nur, wenn Sie ausdrücklich den Codex- Feedback-Upload für den aktuell angehängten Thread ohne das vollständige Gateway- Diagnosebundle wünschen.

​

Compaction und Transkriptspiegel

Wenn das ausgewählte Modell den Codex-Harness verwendet, wird native Thread-Compaction an den Codex-App-Server delegiert. OpenClaw hält einen Transkriptspiegel für Kanalverlauf, Suche, /new, /reset und zukünftige Modell- oder Harness-Wechsel vor. Der Spiegel enthält den Benutzer-Prompt, den endgültigen Assistententext sowie schlanke Codex- Reasoning- oder Planungsdatensätze, wenn der App-Server sie ausgibt. Derzeit zeichnet OpenClaw nur Start- und Abschlusssignale der nativen Compaction auf. Es stellt noch keine menschenlesbare Compaction-Zusammenfassung oder prüfbare Liste bereit, welche Einträge Codex nach der Compaction behalten hat. Da Codex den kanonischen nativen Thread besitzt, schreibt tool_result_persist derzeit keine Codex-nativen Tool-Ergebnisdatensätze um. Es gilt nur, wenn OpenClaw ein Tool-Ergebnis in ein OpenClaw-eigenes Sitzungstranskript schreibt.

​

Medien und Zustellung

OpenClaw besitzt weiterhin die Medienzustellung und die Auswahl des Medienproviders. Bild, Video, Musik, PDF, TTS und Medienverständnis verwenden passende Provider-/Modelleinstellungen wie agents.defaults.imageGenerationModel, videoGenerationModel, pdfModel und messages.tts. Text, Bilder, Video, Musik, TTS, Genehmigungen und Messaging-Tool-Ausgaben laufen weiterhin über den normalen OpenClaw-Zustellpfad. Mediengenerierung erfordert kein PI. Wenn Codex ein natives Element zur Bildgenerierung mit einem savedPath ausgibt, leitet OpenClaw genau diese Datei über den normalen Antwort-Medienpfad weiter, auch wenn der Codex- Turn keinen Assistententext enthält.

​

Verwandte Themen

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