Vue d’ensemble
Codex gère la boucle de modèle native, la reprise native des fils, la continuation native des outils et la Compaction native. OpenClaw gère le routage des canaux, les fichiers de session, la remise des messages visibles, les outils dynamiques OpenClaw, les approbations, la remise des médias et un miroir de la transcription autour de cette frontière. Le routage des prompts suit l’environnement d’exécution sélectionné, et pas seulement la chaîne du fournisseur. Un tour Codex natif reçoit les instructions destinées aux développeurs du serveur d’application Codex ; une route de compatibilité OpenClaw explicite conserve le prompt système OpenClaw normal, même lorsqu’elle utilise une authentification ou un transport OpenAI de type Codex. OpenClaw démarre et reprend les fils Codex natifs avec la personnalité intégrée de Codex désactivée (personality: "none"), afin que les fichiers de
personnalité de l’espace de travail et l’identité de l’agent OpenClaw restent
les références faisant autorité. Autrement, le mode Codex natif conserve les
instructions de base et de modèle gérées par Codex ainsi que le chargement de
la documentation du projet. Les exécutions OpenClaw légères, par exemple Cron,
continuent de désactiver le chargement de la documentation du projet.
Les instructions OpenClaw destinées aux développeurs couvrent les
préoccupations liées à l’environnement d’exécution OpenClaw : remise au canal
source, outils dynamiques OpenClaw, délégation ACP, contexte de l’adaptateur et
fichiers de profil actifs de l’espace de travail de l’agent. Les catalogues de
Skills et les pointeurs vers MEMORY.md acheminés par les outils sont projetés
sous forme d’instructions de collaboration destinées aux développeurs et
limitées au tour. Lorsque les outils de mémoire sont indisponibles, le contenu
actif de BOOTSTRAP.md et l’intégralité de MEMORY.md sont à la place ajoutés
au contexte d’entrée en texte brut du tour.
La plupart des outils dynamiques OpenClaw utilisent l’espace de noms
interrogeable openclaw. Les outils marqués catalogMode: "direct-only"
utilisent openclaw_direct, que Codex conserve directement visible par le
modèle sous la forme DirectModelOnly, au lieu de l’exposer à une exécution
imbriquée en mode Code.
Liaisons de fils et changements de modèle
Lorsqu’une session OpenClaw est attachée à un fil Codex existant, le tour suivant renvoie au serveur d’application le modèle actuellement sélectionné, la politique d’approbation, le bac à sable, le réviseur des approbations et le niveau de service. Le passage deopenai/gpt-5.5 à openai/gpt-5.2 conserve
la liaison au fil, mais demande à Codex de poursuivre avec le modèle
nouvellement sélectionné.
Les liaisons supervisées constituent l’exception. Le sélecteur de modèle
OpenClaw reste verrouillé et les reprises omettent les substitutions de modèle
et de fournisseur afin que Codex restaure le modèle et le fournisseur
persistants du fil canonique. Une commande Codex native distincte peut modifier
cette paire persistante, et l’instantané initial peut produire l’avertissement
normal de Codex signalant une différence de modèle ; le modèle OpenClaw externe
et la chaîne de repli ne se substituent jamais à l’un ou à l’autre.
Supervision et continuation sûre
La supervision Codex est une fonctionnalité facultative du même Plugincodex. Elle détecte les fils natifs au moyen d’une connexion distincte et ne
projette dans le catalogue du Gateway que les sessions non archivées. En
l’absence de paramètres de connexion appServer explicites, cette connexion
utilise l’entrée-sortie standard gérée du répertoire personnel de l’utilisateur,
tandis que le harnais ordinaire reste limité à l’agent. L’énumération et la
lecture des métadonnées sont passives : elles ne reprennent pas un fil,
n’abonnent pas OpenClaw à ses événements en direct et ne répondent pas à ses
demandes d’approbation.
Pour une session enregistrée ou inactive sur l’ordinateur du Gateway,
Continuer en tant que branche crée une conversation normale verrouillée sur
le modèle et reproduit un historique limité des messages de l’utilisateur et
de l’assistant jusqu’au dernier tour terminal persistant de la source. Le
premier tour de conversation normale installe les véritables gestionnaires
d’approbation et utilise un embranchement natif temporaire pour figer
l’instantané sans substitution de modèle ni de fournisseur. Codex App Server
utilise sa configuration native actuelle et renvoie la paire sélectionnée ; il
émet son avertissement normal si ce modèle diffère du dernier modèle enregistré
pour la source. Sur la même connexion de supervision, OpenClaw démarre le fil
du harnais Codex canonique dont la source est appServer, dans son répertoire
de travail et sous sa politique d’exécution, avec exactement le modèle et le
fournisseur renvoyés pour ce démarrage initial, injecte l’historique visible
limité et archive l’embranchement temporaire. La source n’est jamais reprise.
Le fil canonique dispose de toute la surface d’outils du harnais OpenClaw ; le
raisonnement, les appels d’outils et les résultats d’outils de la source n’y
sont pas clonés. La portée privée de la connexion persiste dans les états de
liaison en attente et validés, de sorte que chaque tour ultérieur reste sur
cette connexion avec la configuration native d’authentification et de
fournisseur. Une supervision désactivée ou une dérive de liaison ou de
connexion provoque un échec fermé au lieu de basculer vers le harnais ordinaire
du répertoire personnel de l’agent.
La source CLI ou VS Code d’origine reste admissible dans les deux catalogues.
La branche canonique est un fil Codex natif, mais son type de source est
appServer ; les clients natifs peuvent filtrer ce type de source, de sorte
que son affichage dans Codex Desktop n’est pas garanti.
Les sources actives ne peuvent pas démarrer une nouvelle branche ni être
archivées ; une conversation supervisée existante peut néanmoins être ouverte.
notLoaded signifie que l’activité est inconnue, et non que la session est
inactive ; OpenClaw n’autorise l’archivage d’une ligne locale idle ou
notLoaded qu’après confirmation explicite de l’absence d’un autre processus
d’exécution et une nouvelle lecture locale au processus de l’état. Codex
sérialise les mutations des fils au sein d’un même processus App Server, mais
ne fournit aucun bail exclusif entre processus pour le processus d’exécution ou
le propriétaire des approbations ; cette lecture ne peut donc pas prouver
qu’un autre processus n’utilise pas le fil. OpenClaw bloque un propriétaire de
liaison actif connu pour la cible exacte ou pour tout descendant créé et non
archivé renvoyé par la requête paginée de Codex sur les descendants. Les
erreurs d’énumération, les cycles et l’épuisement de la limite de sécurité
provoquent un échec fermé. L’archivage natif peut encore entrer en concurrence
avec un nouveau tour dans un autre processus ; la confirmation couvre donc les
clients inconnus et l’intervalle entre la lecture de l’état et l’archivage. Une
conversation supervisée verrouillée sur le modèle ne peut pas être supprimée
tant qu’elle protège la liaison native.
Les catalogues de nœuds appairés restent limités aux métadonnées dans la
version initiale. La frontière actuelle d’invocation des nœuds fonctionne en
requête-réponse et ne peut pas transporter les événements de tour de longue
durée, les demandes d’approbation ni la sortie diffusée en continu nécessaires
à une véritable liaison de harnais Codex. Les actions distantes Continuer
et Archiver restent donc indisponibles, même lorsque la ligne est inactive.
Consultez Supervision Codex pour la configuration
par l’opérateur et le comportement visible de l’interface de contrôle.
Réponses visibles et Heartbeats
Les tours de conversation directs ou provenant de la source via le harnais Codex utilisent par défaut la remise automatique de la réponse finale de l’assistant pour les surfaces WebChat internes, conformément au contrat du harnais Pi : l’agent répond normalement et OpenClaw publie le texte final dans la conversation source. Définissezmessages.visibleReplies: "message_tool"
pour garder privé le texte final de l’assistant, sauf si l’agent appelle
message(action="send").
Les tours Heartbeat de Codex reçoivent par défaut heartbeat_respond dans le
catalogue interrogeable d’outils OpenClaw, afin que l’agent puisse indiquer si
le réveil doit rester silencieux ou envoyer une notification. Les consignes
d’initiative du Heartbeat sont envoyées sous forme d’instruction Codex de mode
collaboration destinée aux développeurs et limitée au tour Heartbeat ; les
tours de conversation ordinaires restent en mode Codex Default. Lorsque
HEARTBEAT.md n’est pas vide, les instructions du Heartbeat indiquent le
fichier à Codex au lieu d’intégrer directement son contenu.
Frontières des hooks
OpenClaw n’utilise pas les fichiers
hooks.json Codex du projet ou globaux pour
acheminer le comportement des Plugins. Pour le pont des outils natifs et des
autorisations, OpenClaw injecte une configuration Codex propre à chaque fil
pour PreToolUse, PostToolUse, PermissionRequest et Stop.
Lorsque les approbations du serveur d’application Codex sont activées
(approvalPolicy n’est pas "never"), la configuration de hooks natifs
injectée par défaut omet PermissionRequest, afin que le réviseur du serveur
d’application Codex et le pont d’approbation OpenClaw gèrent les véritables
élévations après examen. Ajoutez permission_request à
nativeHookRelay.events pour imposer malgré tout le relais de compatibilité.
Les autres hooks Codex, tels que SessionStart et UserPromptSubmit, restent
des mécanismes de contrôle au niveau de Codex ; ils ne sont pas exposés comme
hooks de Plugin OpenClaw dans le contrat v1.
Pour les outils dynamiques OpenClaw, OpenClaw exécute l’outil après que Codex a
demandé l’appel ; le comportement des Plugins et du middleware s’exécute donc
dans l’adaptateur du harnais. Pour les outils natifs de Codex, Codex possède
l’enregistrement canonique de l’outil ; OpenClaw peut reproduire certains
événements, mais ne peut pas réécrire le fil natif sauf si Codex l’expose par
l’intermédiaire du serveur d’application ou de rappels de hooks natifs.
Les événements PreToolUse en mode rapport du serveur d’application Codex
reportent l’approbation du Plugin jusqu’à l’approbation correspondante du
serveur d’application. Si un hook OpenClaw before_tool_call renvoie
requireApproval alors que la charge utile native définit
openclaw_approval_mode: "report", le relais de hook natif enregistre
l’exigence d’approbation du Plugin et ne renvoie aucune décision native.
Lorsque Codex envoie ensuite la demande d’approbation du serveur d’application
pour la même utilisation de l’outil, OpenClaw ouvre la demande d’approbation du
Plugin et retransmet la décision à Codex. Les événements Codex
PermissionRequest constituent un chemin d’approbation distinct et peuvent
toujours être acheminés par les approbations OpenClaw lorsque ce pont est
configuré.
Les notifications d’éléments du serveur d’application Codex fournissent
également des observations asynchrones after_tool_call pour les exécutions
d’outils natifs qui ne sont pas déjà couvertes par le relais natif
PostToolUse. Elles servent uniquement à la télémétrie et à la compatibilité ;
elles ne peuvent ni bloquer, ni retarder, ni modifier l’appel de l’outil natif.
Les projections de Compaction et du cycle de vie du LLM proviennent des
notifications du serveur d’application Codex et de l’état de l’adaptateur
OpenClaw, et non de commandes de hooks natifs Codex. before_compaction,
after_compaction, llm_input et llm_output sont des observations au niveau
de l’adaptateur, et non des captures octet par octet de la requête interne ou
des charges utiles de Compaction de Codex.
Les notifications hook/started et hook/completed du serveur d’application
Codex natif sont projetées sous forme d’événements d’agent
codex_app_server.hook pour la trajectoire et le débogage. Elles n’appellent
pas les hooks de Plugin OpenClaw.
Contrat de prise en charge v1
Pris en charge dans l’environnement d’exécution Codex v1 :
Non pris en charge dans l’environnement d’exécution Codex v1 :
Autorisations natives et sollicitations MCP
PourPermissionRequest, OpenClaw ne renvoie des décisions explicites
d’autorisation ou de refus que lorsque la politique statue. L’absence de
décision ne constitue pas une autorisation : Codex l’interprète comme une
absence de décision du hook et poursuit avec son propre gardien ou son propre
processus d’approbation utilisateur.
Par défaut, les modes d’approbation du serveur d’application Codex omettent ce
hook natif. Cela s’applique sauf si permission_request est explicitement
inclus dans nativeHookRelay.events ou si un environnement d’exécution de
compatibilité l’installe.
Lorsqu’un opérateur choisit allow-always pour une demande d’autorisation
native de Codex, OpenClaw mémorise l’empreinte exacte du fournisseur, de la
session, de l’entrée de l’outil et du répertoire de travail pour une période
limitée de la session. La décision mémorisée ne s’applique volontairement
qu’aux correspondances exactes : toute modification de la commande, des
arguments, de la charge utile de l’outil ou du répertoire de travail entraîne
une nouvelle approbation.
Les sollicitations d’approbation des outils MCP de Codex sont acheminées par le
flux d’approbation des Plugins d’OpenClaw lorsque Codex définit
_meta.codex_approval_kind sur "mcp_tool_call". Les invites
request_user_input de Codex sont renvoyées à la conversation d’origine, et le
prochain message de suivi mis en file d’attente répond à cette requête du
serveur natif au lieu d’être orienté comme contexte supplémentaire. Les autres
demandes de sollicitation MCP sont refusées par défaut.
Pour le flux général d’approbation des Plugins qui transporte ces invites,
consultez Demandes d’autorisation des Plugins.
Pilotage de la file d’attente
Le pilotage de la file d’attente d’une exécution active correspond àturn/steer du serveur d’application Codex. Avec la valeur par défaut
messages.queue.mode: "steer", OpenClaw regroupe les messages de conversation
en mode de pilotage pendant la période de silence configurée et les envoie dans
leur ordre d’arrivée sous la forme d’une seule requête turn/steer.
Les tours de revue Codex et de Compaction manuelle peuvent refuser le pilotage pendant le même tour. Dans ce cas, OpenClaw attend la fin de l’exécution active avant de lancer le prompt. Utilisez /queue followup ou /queue collect lorsque les messages doivent être mis en file d’attente par défaut au lieu de piloter le tour. Consultez File d’attente de pilotage.
Envoi des commentaires Codex
Lorsque/diagnostics [note] est approuvé pour une session utilisant le harnais Codex natif, OpenClaw appelle également feedback/upload sur le serveur d’application Codex pour les fils Codex concernés, en incluant les journaux de chaque fil répertorié ainsi que ceux des sous-fils Codex générés lorsqu’ils sont disponibles.
L’envoi emprunte le circuit de commentaires normal de Codex vers les serveurs OpenAI. Si les commentaires Codex sont désactivés sur ce serveur d’application, la commande renvoie l’erreur du serveur d’application. La réponse de diagnostic terminée répertorie les canaux, les identifiants de session OpenClaw, les identifiants de fil Codex et les commandes locales codex resume <thread-id> correspondant aux fils envoyés.
Si vous refusez ou ignorez l’approbation, OpenClaw n’affiche pas ces identifiants Codex et n’envoie aucun commentaire Codex. Cet envoi ne remplace pas l’exportation locale des diagnostics du Gateway. Consultez Exportation des diagnostics pour en savoir plus sur l’approbation, la confidentialité, le paquet local et le comportement dans les discussions de groupe.
Utilisez /codex diagnostics [note] uniquement lorsque vous souhaitez envoyer les commentaires Codex pour le fil actuellement associé, sans le paquet de diagnostics complet du Gateway.
Compaction et miroir de transcription
Lorsque le modèle sélectionné utilise le harnais Codex, la Compaction native du fil relève du serveur d’application Codex. OpenClaw n’exécute pas de Compaction préliminaire pour les tours Codex, ne remplace pas la Compaction Codex par celle du moteur de contexte et ne se rabat pas sur la synthèse d’OpenClaw ou de l’API publique OpenAI lorsque la Compaction native ne peut pas être lancée. OpenClaw conserve un miroir de transcription pour l’historique du canal, la recherche,/new, /reset et les futurs changements de modèle ou de harnais.
Les demandes explicites de Compaction, comme /compact ou une opération de Compaction manuelle demandée par un Plugin, lancent la Compaction Codex native avec thread/compact/start. OpenClaw maintient la requête et le bail du client partagé ouverts jusqu’à ce que Codex émette l’élément d’achèvement contextCompaction correspondant, puis signale que le tour de Compaction est terminé. Si ce tour terminal dépasse le délai d’expiration de Compaction configuré, OpenClaw demande une interruption native du tour. Le bail et le verrou de Compaction propre au fil restent détenus jusqu’à ce que Codex signale un état terminal ou confirme l’appel RPC d’interruption. Si Codex ne confirme pas dans le délai de grâce de l’interruption, OpenClaw retire la connexion avant de libérer le verrou. Les connexions distantes dissocient également la liaison du fil correspondant afin que les travaux ultérieurs ne puissent pas chevaucher un tour distant non confirmé. Les autres tours sur une connexion retirée échouent et peuvent être réessayés avec un nouveau client. La fermeture du client, l’annulation de la requête ou l’échec d’un tour de Compaction renvoie une opération ayant échoué. La Compaction automatique due à la pression du contexte relève de Codex ; OpenClaw ne lance la Compaction native que pour les déclencheurs demandés manuellement.
Lorsqu’un moteur de contexte demande la projection d’amorçage d’un fil Codex, OpenClaw projette dans le nouveau fil Codex les noms et identifiants des appels d’outils, les structures d’entrée et le contenu expurgé des résultats d’outils. Il ne copie pas les valeurs brutes des arguments d’appels d’outils dans cette projection.
Le miroir inclut le prompt de l’utilisateur, le texte final de l’assistant et des enregistrements légers du raisonnement ou du plan Codex lorsque le serveur d’application les émet. OpenClaw enregistre le démarrage de la Compaction native et son état terminal, mais ne présente ni résumé de Compaction lisible par un humain ni liste vérifiable des entrées conservées par Codex après la Compaction.
Comme Codex détient le fil natif canonique, tool_result_persist ne réécrit pas les enregistrements natifs de résultats d’outils Codex. Il ne s’applique que lorsqu’OpenClaw écrit un résultat d’outil dans la transcription d’une session détenue par OpenClaw.
Médias et diffusion
OpenClaw continue de gérer la diffusion des médias et la sélection de leur fournisseur. La compréhension des images, des vidéos, de la musique, des PDF, de la synthèse vocale et des médias utilise les paramètres de fournisseur et de modèle correspondants, tels queagents.defaults.imageGenerationModel, videoGenerationModel, pdfModel et messages.tts.
Le texte, les images, les vidéos, la musique, la synthèse vocale, les approbations et les sorties des outils de messagerie continuent d’emprunter le circuit de diffusion normal d’OpenClaw ; la génération de médias ne nécessite pas l’ancien environnement d’exécution. Lorsque Codex émet un élément natif de génération d’image comportant un savedPath, OpenClaw transmet ce fichier exact par le circuit normal des médias de réponse, même si le tour Codex ne contient aucun texte de l’assistant.