codex_plugin_*. Les appels de Plugin restent dans la transcription Codex native, et l’app-server Codex possède l’exécution MCP adossée aux applications.
Utilisez cette page après que le harnais Codex de base fonctionne.
Exigences
- Le runtime d’agent OpenClaw sélectionné doit être le harnais Codex natif.
plugins.entries.codex.enableddoit être true.plugins.entries.codex.config.codexPlugins.enableddoit être true.- La V1 prend uniquement en charge les Plugins
openai-curatedque la migration a observés comme installés depuis la source dans le répertoire personnel Codex source. - L’app-server Codex cible doit pouvoir voir l’inventaire de marketplace, de Plugin et d’applications attendu.
codexPlugins n’a aucun effet sur les exécutions OpenClaw, les exécutions normales du fournisseur OpenAI, les liaisons de conversation ACP ni les autres harnais, car ces chemins ne créent pas de fils d’app-server Codex avec une configuration apps native.
L’accès Codex côté OpenAI, la disponibilité des applications et les contrôles d’applications/Plugins d’espace de travail proviennent du compte Codex connecté. Pour le compte OpenAI et le modèle d’administration, consultez Utiliser Codex avec votre forfait ChatGPT.
Démarrage rapide
Prévisualisez la migration depuis le répertoire personnel Codex source :codexPlugins explicites pour les Plugins éligibles et appelle plugin/install de l’app-server Codex pour les Plugins sélectionnés. Une configuration migrée typique ressemble à ceci :
codexPlugins, les nouvelles conversations Codex récupèrent automatiquement l’ensemble d’applications mis à jour. Utilisez /new ou /reset pour actualiser la conversation actuelle. Un redémarrage du Gateway n’est pas requis pour les changements d’activation ou de désactivation de Plugin.
Gérer les Plugins depuis le chat
Utilisez/codex plugins lorsque vous voulez inspecter ou modifier les Plugins Codex natifs configurés depuis le même chat où vous exploitez le harnais Codex :
/codex plugins est un alias de /codex plugins list. La sortie de liste affiche les clés de Plugin configurées, l’état activé/désactivé, le nom du Plugin Codex et le marketplace depuis plugins.entries.codex.config.codexPlugins.plugins.
enable et disable écrivent uniquement dans la configuration OpenClaw à ~/.openclaw/openclaw.json ; ils ne modifient pas ~/.codex/config.toml et n’installent pas de nouveaux Plugins Codex. Seul le propriétaire ou un client Gateway avec le périmètre operator.admin peut modifier l’état des Plugins.
Activer un Plugin configuré active également le commutateur global codexPlugins.enabled. Si le Plugin a été écrit désactivé parce que la migration a renvoyé auth_required, réautorisez l’application dans Codex avant de l’activer dans OpenClaw.
Fonctionnement de la configuration native des Plugins
L’intégration comporte trois états distincts :- Installé : Codex possède le bundle de Plugin local dans le runtime de l’app-server cible.
- Activé : la configuration OpenClaw accepte de rendre le Plugin disponible pour les tours du harnais Codex.
- Accessible : l’app-server Codex confirme que les entrées d’application du Plugin sont disponibles pour le compte actif et peuvent être associées à l’identité du Plugin migré.
plugin/read du Codex source et vérifie que la réponse de compte de l’app-server Codex source est un compte avec abonnement ChatGPT. Les réponses de compte non ChatGPT ou manquantes ignorent les Plugins adossés à des applications avec codex_subscription_required. Par défaut, la migration n’appelle pas app/list source ; les Plugins sources adossés à des applications qui passent le contrôle de compte sont planifiés sans vérification de l’accessibilité des applications sources, et les échecs de transport de consultation du compte sont ignorés avec codex_account_unavailable. Avec --verify-plugin-apps, la migration prend un instantané frais de app/list source et exige que chaque application possédée soit présente, activée et accessible avant de planifier l’activation native. Dans ce mode, les échecs de transport de consultation du compte basculent vers le contrôle de l’inventaire des applications sources. L’inventaire d’applications au runtime est le contrôle d’accessibilité de la session cible après migration. La configuration de session du harnais Codex calcule ensuite une configuration restrictive des applications de fil pour les applications de Plugin activées et accessibles.
La configuration des applications de fil est calculée lorsqu’OpenClaw établit une session du harnais Codex ou remplace une liaison de fil Codex obsolète. Elle n’est pas recalculée à chaque tour ; ainsi, /codex plugins enable et /codex plugins disable affectent les nouvelles conversations Codex. Utilisez /new ou /reset lorsque la conversation actuelle doit récupérer l’ensemble d’applications mis à jour.
Limite de prise en charge V1
La V1 est volontairement étroite :- Seuls les Plugins
openai-curateddéjà installés dans l’inventaire de l’app-server Codex source sont éligibles à la migration. - Les Plugins sources adossés à des applications doivent passer le contrôle d’abonnement au moment de la migration.
--verify-plugin-appsajoute le contrôle de l’inventaire des applications sources. Les comptes bloqués par abonnement ainsi que, en mode vérification, les applications sources inaccessibles, désactivées ou manquantes, ou les échecs d’actualisation de l’inventaire des applications sources, sont signalés comme éléments manuels ignorés au lieu d’entrées de configuration activées. Les détails de Plugin illisibles sont ignorés avant le contrôle de l’inventaire des applications sources. - La migration écrit des identités de Plugin explicites avec
marketplaceNameetpluginName; elle n’écrit pas de chemins de cachemarketplacePathlocaux. codexPlugins.enabledest le commutateur global d’activation.- Il n’existe pas de joker
plugins["*"]ni de clé de configuration qui accorde une autorité d’installation arbitraire. - Les marketplaces non pris en charge, les bundles de Plugin mis en cache, les hooks et les fichiers de configuration Codex sont conservés dans le rapport de migration pour examen manuel.
Inventaire d’applications et propriété
OpenClaw lit l’inventaire des applications Codex viaapp/list de l’app-server, le met en cache pendant une heure et actualise les entrées obsolètes ou manquantes de manière asynchrone. Le cache est uniquement en mémoire ; le redémarrage de la CLI ou du Gateway le supprime, et OpenClaw le reconstruit à partir de la lecture app/list suivante.
La migration et le runtime utilisent des clés de cache distinctes :
- La vérification de migration source utilise le répertoire personnel Codex source et les options de démarrage de l’app-server source. Cela ne s’exécute que lorsque
--verify-plugin-appsest défini, et force un parcoursapp/listsource frais pour cette exécution de planification. - La configuration du runtime cible utilise l’identité de l’app-server Codex de l’agent cible lorsqu’elle construit la configuration des applications du fil Codex. L’activation de Plugin invalide cette clé de cache cible, puis force son actualisation après
plugin/install.
- id d’application exact depuis le détail du Plugin
- nom de serveur MCP connu
- métadonnées stables uniques
Configuration des applications de fil
OpenClaw injecte un patch restrictifconfig.apps pour le fil Codex : _default est désactivé et seules les applications possédées par des Plugins migrés activés sont activées.
OpenClaw définit destructive_enabled au niveau de l’application depuis la politique effective globale ou par Plugin allow_destructive_actions et laisse Codex appliquer les métadonnées d’outils destructifs à partir de ses annotations d’outils d’application natives. true, "auto" et "ask" définissent destructive_enabled: true ; false le définit à false. La configuration de l’application _default est désactivée avec open_world_enabled: false. Les applications de Plugin activées sont émises avec open_world_enabled: true ; OpenClaw n’expose pas de réglage de politique open-world séparé pour les Plugins et ne maintient pas de listes de refus de noms d’outils destructifs par Plugin.
Le mode d’approbation des outils est automatique par défaut pour les applications de Plugin afin que les outils de lecture non destructifs puissent s’exécuter sans interface d’approbation dans le même fil. Les outils destructifs restent contrôlés par la politique destructive_enabled de chaque application.
Politique d’action destructive
Les sollicitations destructives de Plugin sont autorisées par défaut pour les Plugins Codex migrés, tandis que les schémas non sûrs et la propriété ambiguë échouent toujours en mode fermé :- Le paramètre global
allow_destructive_actionsvauttruepar défaut. - Le paramètre par Plugin
allow_destructive_actionsremplace la politique globale pour ce Plugin. - Lorsque la politique vaut
false, OpenClaw renvoie un refus déterministe. - Lorsque la politique vaut
true, OpenClaw accepte automatiquement uniquement les schémas sûrs qu’il peut mapper à une réponse d’approbation, par exemple un champ booléen d’approbation. - Lorsque la politique vaut
"auto", OpenClaw expose les actions destructives de Plugin à Codex, mais transforme les sollicitations d’approbation MCP dont la propriété est prouvée en approbations de Plugin OpenClaw avant de renvoyer la réponse d’approbation Codex. - Lorsque la politique vaut
"ask", OpenClaw utilise le même contrôle Codex d’écriture/destruction que"auto", efface les remplacements durables d’approbation par outil Codex pour l’application avant le démarrage du fil, et ne propose qu’une approbation ou un refus ponctuel afin que les approbations durables ne puissent pas supprimer les invites ultérieures d’action d’écriture. - Pour chaque application admise qui utilise
"ask", OpenClaw sélectionne le réviseur d’approbations humaines de Codex pour cette application afin que Codex envoie ses sollicitations d’approbation à OpenClaw. Les autres applications et les approbations de fil hors application conservent leur réviseur et leur politique configurés. - Une identité de Plugin manquante, une propriété ambiguë, un id de tour manquant, un mauvais id de tour ou un schéma de sollicitation non sûr entraîne un refus au lieu d’une invite.
Dépannage
auth_required : la migration a installé le Plugin, mais l’une de ses applications nécessite encore une authentification. L’entrée de Plugin explicite est écrite désactivée jusqu’à ce que vous réautorisiez et activiez celui-ci.
app_inaccessible, app_disabled ou app_missing :
la migration n’a pas installé le Plugin car l’inventaire des applications Codex source n’indiquait pas toutes les applications possédées comme présentes, activées et accessibles lorsque --verify-plugin-apps était défini. Réautorisez ou activez l’application dans Codex, puis relancez la migration avec --verify-plugin-apps.
app_inventory_unavailable : la migration n’a pas installé le Plugin car la vérification stricte des applications sources a été demandée et l’actualisation de l’inventaire des applications Codex source a échoué. Corrigez l’accès à l’app-server Codex source ou réessayez sans --verify-plugin-apps si vous acceptez le plan plus rapide contrôlé par le compte.
codex_subscription_required : la migration n’a pas installé le Plugin adossé à des applications car le compte de l’app-server Codex source n’était pas connecté avec un compte avec abonnement ChatGPT. Connectez-vous à l’application Codex avec une authentification d’abonnement, puis relancez la migration.
codex_account_unavailable : la migration n’a pas installé le Plugin adossé à des applications car le compte de l’app-server Codex source n’a pas pu être lu. Corrigez l’authentification de l’app-server Codex source ou relancez avec --verify-plugin-apps si vous voulez que l’inventaire des applications sources décide de l’éligibilité lorsque la consultation du compte échoue.
marketplace_missing ou plugin_missing : l’app-server Codex cible ne peut pas voir le marketplace ou le Plugin openai-curated attendu. Relancez la migration sur le runtime cible ou inspectez l’état des Plugins de l’app-server Codex.
app_inventory_missing ou app_inventory_stale : la disponibilité des applications provient d’un cache vide ou obsolète. OpenClaw planifie une actualisation asynchrone et exclut les applications de Plugin jusqu’à ce que la propriété et la disponibilité soient connues.
app_ownership_ambiguous : l’inventaire des applications ne correspondait que par nom d’affichage ; l’application n’est donc pas exposée au fil Codex.
Configuration modifiée, mais l’agent ne voit pas le plugin : utilisez /codex plugins list pour confirmer l’état configuré, puis utilisez /new ou /reset. Les liaisons de fil
Codex existantes conservent la configuration de l’application avec laquelle elles ont démarré jusqu’à ce qu’OpenClaw
établisse une nouvelle session de harness ou remplace une liaison obsolète.
Action destructive refusée : vérifiez les valeurs globales et propres à chaque plugin de
allow_destructive_actions. Même lorsque la stratégie vaut true, "auto" ou
"ask", les schémas d’élicitation non sûrs et l’identité ambiguë du plugin échouent toujours
en mode fermé.