Plugins Codex natifs

La prise en charge native des plugins Codex permet à un agent OpenClaw en mode Codex d’utiliser les capacités d’application et de plugin propres à l’app-server Codex dans le même thread Codex que celui qui gère le tour OpenClaw.

OpenClaw ne traduit pas les plugins Codex en outils dynamiques OpenClaw codex_plugin_* synthétiques. 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 une fois que le harness Codex de base fonctionne.

# Exigences

• Le runtime de l’agent OpenClaw sélectionné doit être le harness Codex natif.
• plugins.entries.codex.enabled doit être true.
• plugins.entries.codex.config.codexPlugins.enabled doit être true.
• La V1 prend uniquement en charge les plugins openai-curated que 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 le marketplace, le plugin et l’inventaire des applications attendus.

codexPlugins n’a aucun effet sur les exécutions PI, les exécutions normales du fournisseur OpenAI, les liaisons de conversation ACP ni les autres harnesses, car ces chemins ne créent pas de threads app-server Codex avec une config apps native.

# Démarrage rapide

Prévisualisez la migration depuis le répertoire personnel Codex source :

openclaw migrate codex --dry-run

Utilisez la vérification stricte des applications source lorsque vous voulez que la migration vérifie l’accessibilité des applications source avant de planifier l’activation native des plugins :

openclaw migrate codex --dry-run --verify-plugin-apps

Appliquez la migration lorsque le plan semble correct :

openclaw migrate apply codex --yes

La migration écrit des entrées codexPlugins explicites pour les plugins admissibles et appelle plugin/install de l’app-server Codex pour les plugins sélectionnés. Une config migrée typique ressemble à ceci :

{
  plugins: {
    entries: {
      codex: {
        enabled: true,
        config: {
          codexPlugins: {
            enabled: true,
            allow_destructive_actions: true,
            plugins: {
              "google-calendar": {
                enabled: true,
                marketplaceName: "openai-curated",
                pluginName: "google-calendar",
              },
            },
          },
        },
      },
    },
  },
}

Après avoir modifié codexPlugins, utilisez /new, /reset ou redémarrez le gateway afin que les futures sessions du harness Codex démarrent avec le nouvel ensemble d’applications.

# Fonctionnement de la configuration native des plugins

L’intégration comporte trois états distincts :

• Installé : Codex dispose du bundle de plugin local dans le runtime app-server cible.
• Activé : la config OpenClaw accepte de rendre le plugin disponible aux tours du harness Codex.
• Accessible : l’app-server Codex confirme que les entrées d’application du plugin sont disponibles pour le compte actif et peuvent être mappées à l’identité du plugin migré.

La migration est l’étape durable d’installation et d’admissibilité. Pendant la planification, OpenClaw lit les détails plugin/read de Codex source et vérifie que la réponse du compte app-server Codex source est un compte avec abonnement ChatGPT. Les réponses de compte non ChatGPT ou manquantes ignorent les plugins adossés aux applications avec codex_subscription_required. Par défaut, la migration n’appelle pas app/list sur la source ; les plugins source adossés aux applications qui passent la barrière du compte sont planifiés sans vérification de l’accessibilité des applications source, et les échecs de transport lors de la recherche du compte sont ignorés avec codex_account_unavailable. Avec --verify-plugin-apps, la migration prend un nouvel instantané 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 lors de la recherche du compte passent à la barrière d’inventaire des applications source. L’inventaire des applications au runtime est la vérification d’accessibilité de la session cible après migration. La configuration de session du harness Codex calcule ensuite une config restrictive d’applications de thread pour les applications de plugin activées et accessibles.

La config d’applications de thread est calculée quand OpenClaw établit une session du harness Codex ou remplace une liaison de thread Codex obsolète. Elle n’est pas recalculée à chaque tour.

# Limite de prise en charge de la V1

La V1 est volontairement restreinte :

• Seuls les plugins openai-curated déjà installés dans l’inventaire app-server Codex source sont admissibles à la migration.
• Les plugins source adossés aux applications doivent passer la barrière d’abonnement au moment de la migration. --verify-plugin-apps ajoute la barrière d’inventaire des applications source. Les comptes soumis à abonnement ainsi que, en mode vérification, les applications source inaccessibles, désactivées ou manquantes, ou les échecs d’actualisation de l’inventaire des applications source, sont signalés comme éléments manuels ignorés plutôt que comme entrées de config activées. Les détails de plugin illisibles sont ignorés avant la barrière d’inventaire des applications source.
• La migration écrit des identités de plugin explicites avec marketplaceName et pluginName ; elle n’écrit pas de chemins de cache marketplacePath locaux.
• codexPlugins.enabled est l’interrupteur d’activation global.
• Il n’existe pas de joker plugins["*"] ni de clé de config accordant une autorité d’installation arbitraire.
• Les marketplaces non pris en charge, les bundles de plugin mis en cache, les hooks et les fichiers de config Codex sont conservés dans le rapport de migration pour examen manuel.

# Inventaire des applications et propriété

OpenClaw lit l’inventaire des applications Codex via app/list de l’app-server, le met en cache pendant une heure et actualise de manière asynchrone les entrées obsolètes ou manquantes. Le cache est uniquement en mémoire ; redémarrer la CLI ou le gateway le supprime, et OpenClaw le reconstruit à partir de la prochaine lecture app/list.

La migration et le runtime utilisent des clés de cache séparées :

• 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 s’exécute uniquement lorsque --verify-plugin-apps est défini, et force un parcours app/list source frais pour cette exécution de planification.
• La configuration du runtime cible utilise l’identité app-server Codex de l’agent cible lorsqu’elle construit la config d’applications de thread Codex. L’activation d’un plugin invalide cette clé de cache cible, puis force son actualisation après plugin/install.

Une application de plugin n’est exposée que lorsqu’OpenClaw peut la remapper au plugin migré par une propriété stable :

• id exact de l’application depuis le détail du plugin
• nom de serveur MCP connu
• métadonnées stables uniques

La propriété ambiguë ou uniquement basée sur le nom d’affichage est exclue jusqu’à ce que la prochaine actualisation d’inventaire prouve la propriété.

# Config d’applications de thread

OpenClaw injecte un correctif config.apps restrictif pour le thread 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 à partir de la stratégie allow_destructive_actions globale ou par plugin effective et laisse Codex appliquer les métadonnées d’outils destructifs depuis ses annotations d’outils d’application natives. La config 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 stratégie 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 thread. Les outils destructifs restent contrôlés par la stratégie destructive_enabled de chaque application.

# Stratégie d’action destructive

Les élicitations de plugins destructives sont autorisées par défaut pour les plugins Codex migrés, tandis que les schémas dangereux et la propriété ambiguë échouent toujours en mode fermé :

• allow_destructive_actions global vaut true par défaut.
• allow_destructive_actions par plugin remplace la stratégie globale pour ce plugin.
• Lorsque la stratégie est false, OpenClaw renvoie un refus déterministe.
• Lorsque la stratégie est true, OpenClaw accepte automatiquement uniquement les schémas sûrs qu’il peut mapper à une réponse d’approbation, comme un champ booléen d’approbation.
• Une identité de plugin manquante, une propriété ambiguë, un id de tour manquant, un id de tour incorrect ou un schéma d’élicitation dangereux entraînent un refus au lieu d’une demande de confirmation.

# 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 le plugin.

app_inaccessible, app_disabled ou app_missing : la migration n’a pas installé le plugin parce que l’inventaire des applications Codex source n’a pas indiqué 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 parce que la vérification stricte des applications source a été demandée et que 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 soumis à la barrière du compte.

codex_subscription_required : la migration n’a pas installé le plugin adossé à l’application parce que le compte app-server Codex source n’était pas connecté avec un compte d’abonnement ChatGPT. Connectez-vous à l’application Codex avec l’authentification par abonnement, puis relancez la migration.

codex_account_unavailable : la migration n’a pas installé le plugin adossé à l’application parce que le compte 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 source décide de l’admissibilité lorsque la recherche 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 contre le runtime cible ou inspectez l’état des plugins de l’app-server Codex.

app_inventory_missing ou app_inventory_stale : l’état de préparation des applications provenait 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 l’état de préparation soient connus.

app_ownership_ambiguous : l’inventaire des applications ne correspondait que par nom d’affichage, l’application n’est donc pas exposée au thread Codex.

Config modifiée mais l’agent ne voit pas le plugin : utilisez /new, /reset ou redémarrez le gateway. Les liaisons de thread Codex existantes conservent la config d’applications avec laquelle elles ont démarré jusqu’à ce qu’OpenClaw établisse une nouvelle session de harness ou remplace une liaison obsolète.

L’action destructive est refusée : vérifiez les valeurs globales et par plugin de allow_destructive_actions. Même lorsque la stratégie vaut true, les schémas d’élicitation dangereux et l’identité de plugin ambiguë échouent toujours en mode fermé.

# Connexe

• Harness Codex
• Référence du harness Codex
• Runtime du harness Codex
• Référence de configuration
• CLI de migration