Passer au contenu principal

Documentation Index

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

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

Le Plugin codex inclus permet à OpenClaw d’exécuter des tours d’agent OpenAI intégrés via Codex app-server plutôt que via le harnais PI intégré. Utilisez le harnais Codex lorsque vous voulez que Codex possède la session d’agent de bas niveau : reprise native de thread, continuation native des outils, Compaction native et exécution app-server. OpenClaw possède toujours les canaux de chat, les fichiers de session, la sélection de modèle, les outils dynamiques OpenClaw, les approbations, la livraison des médias et le miroir de transcription visible. La configuration normale utilise des références de modèle OpenAI canoniques telles que openai/gpt-5.5. Ne configurez pas de références de modèle openai-codex/gpt-*. Placez l’ordre d’authentification de l’agent OpenAI sous auth.order.openai ; les profils openai-codex:* plus anciens et les entrées auth.order.openai-codex restent pris en charge pour les installations existantes. OpenClaw démarre les threads Codex app-server avec le mode code natif de Codex et code-mode-only activé. Cela conserve les outils dynamiques OpenClaw différés/recherchables dans la surface d’exécution de code et de recherche d’outils propre à Codex, au lieu d’ajouter un wrapper de recherche d’outils de style PI par-dessus Codex. Pour la séparation plus large entre modèle/fournisseur/runtime, commencez par Runtimes d’agent. La version courte est : openai/gpt-5.5 est la référence de modèle, codex est le runtime, et Telegram, Discord, Slack ou un autre canal reste la surface de communication.

Exigences

  • OpenClaw avec le Plugin codex inclus disponible.
  • Si votre configuration utilise plugins.allow, incluez codex.
  • Codex app-server 0.125.0 ou plus récent. Le Plugin inclus gère par défaut un binaire Codex app-server compatible ; les commandes codex locales dans PATH n’affectent donc pas le démarrage normal du harnais.
  • Authentification Codex disponible via openclaw models auth login --provider openai-codex, un compte app-server dans le répertoire Codex home de l’agent, ou un profil d’authentification explicite avec clé d’API Codex.
Pour la priorité d’authentification, l’isolation de l’environnement, les commandes app-server personnalisées, la découverte de modèles et tous les champs de configuration, consultez la référence du harnais Codex.

Démarrage rapide

La plupart des utilisateurs qui veulent Codex dans OpenClaw veulent ce parcours : connectez-vous avec un abonnement ChatGPT/Codex, activez le Plugin codex inclus et utilisez une référence de modèle canonique openai/gpt-*. Connectez-vous avec OAuth Codex :
openclaw models auth login --provider openai-codex
Activez le Plugin codex inclus et sélectionnez un modèle d’agent OpenAI :
{
  plugins: {
    entries: {
      codex: {
        enabled: true,
      },
    },
  },
  agents: {
    defaults: {
      model: "openai/gpt-5.5",
    },
  },
}
Si votre configuration utilise plugins.allow, ajoutez aussi codex à cet endroit :
{
  plugins: {
    allow: ["codex"],
    entries: {
      codex: {
        enabled: true,
      },
    },
  },
}
Redémarrez le Gateway après avoir modifié la configuration des Plugins. Si un chat existant a déjà une session, utilisez /new ou /reset avant de tester les changements de runtime afin que le prochain tour résolve le harnais à partir de la configuration actuelle.

Configuration

La configuration de démarrage rapide est la configuration minimale viable du harnais Codex. Définissez les options du harnais Codex dans la configuration OpenClaw, et utilisez la CLI uniquement pour l’authentification Codex :
BesoinDéfinir
Activer le harnaisplugins.entries.codex.enabled: trueConfiguration OpenClaw
Conserver une installation de Plugin autoriséeInclure codex dans plugins.allowConfiguration OpenClaw
Router les tours d’agent OpenAI via Codexagents.defaults.model ou agents.list[].model comme openai/gpt-*Configuration d’agent OpenClaw
Se connecter avec OAuth Codexopenclaw models auth login --provider openai-codexProfil d’authentification CLI
Ajouter une clé d’API de secours pour les exécutions CodexProfil de clé d’API openai:* listé après l’authentification par abonnement dans auth.order.openaiProfil d’authentification CLI + configuration OpenClaw
Échouer de façon fermée lorsque Codex est indisponibleFournisseur ou modèle agentRuntime.id: "codex"Configuration modèle/fournisseur OpenClaw
Utiliser le trafic direct de l’API OpenAIFournisseur ou modèle agentRuntime.id: "pi" avec l’authentification OpenAI normaleConfiguration modèle/fournisseur OpenClaw
Ajuster le comportement d’app-serverplugins.entries.codex.config.appServer.*Configuration du Plugin Codex
Activer les applications Plugins natives Codexplugins.entries.codex.config.codexPlugins.*Configuration du Plugin Codex
Activer Codex Computer Useplugins.entries.codex.config.computerUse.*Configuration du Plugin Codex
Utilisez les références de modèle openai/gpt-* pour les tours d’agent OpenAI adossés à Codex. Préférez auth.order.openai pour l’ordre abonnement d’abord/clé d’API en secours. Les profils d’authentification openai-codex:* existants et auth.order.openai-codex restent valides, mais n’écrivez pas de nouvelles références de modèle openai-codex/gpt-*.
{
  auth: {
    order: {
      openai: ["openai-codex:user@example.com", "openai:api-key-backup"],
    },
  },
}
Dans cette forme, les deux profils s’exécutent toujours via Codex pour les tours d’agent openai/gpt-*. La clé d’API est uniquement une solution de secours d’authentification, pas une demande de basculer vers PI ou vers OpenAI Responses simple. Le reste de cette page couvre les variantes courantes entre lesquelles les utilisateurs doivent choisir : forme de déploiement, routage à échec fermé, politique d’approbation guardian, Plugins Codex natifs et Computer Use. Pour les listes complètes d’options, les valeurs par défaut, les énumérations, la découverte, l’isolation de l’environnement, les délais d’expiration et les champs de transport app-server, consultez la référence du harnais Codex.

Vérifier le runtime Codex

Utilisez /status dans le chat où vous attendez Codex. Un tour d’agent OpenAI adossé à Codex affiche :
Runtime: OpenAI Codex
Vérifiez ensuite l’état de Codex app-server :
/codex status
/codex models
/codex status indique la connectivité app-server, le compte, les limites de débit, les serveurs MCP et les Skills. /codex models liste le catalogue Codex app-server en direct pour le harnais et le compte. Si /status est surprenant, consultez Dépannage.

Routage et sélection de modèle

Gardez les références de fournisseur et la politique de runtime séparées :
  • Utilisez openai/gpt-* pour les tours d’agent OpenAI via Codex.
  • N’utilisez pas openai-codex/gpt-* dans la configuration. Exécutez openclaw doctor --fix pour réparer les références héritées et les anciennes épingles de route de session.
  • agentRuntime.id: "codex" est facultatif pour le mode automatique OpenAI normal, mais utile lorsqu’un déploiement doit échouer de façon fermée si Codex est indisponible.
  • agentRuntime.id: "pi" fait opter un fournisseur ou un modèle pour le comportement PI direct lorsque cela est intentionnel.
  • /codex ... contrôle les conversations Codex app-server natives depuis le chat.
  • ACP/acpx est un chemin de harnais externe distinct. Utilisez-le uniquement lorsque l’utilisateur demande ACP/acpx ou un adaptateur de harnais externe.
Routage courant des commandes :
Intention de l’utilisateurUtiliser
Joindre le chat actuel/codex bind [--cwd <path>]
Reprendre un thread Codex existant/codex resume <thread-id>
Lister ou filtrer les threads Codex/codex threads [filter]
Envoyer uniquement un retour Codex/codex diagnostics [note]
Démarrer une tâche ACP/acpxCommandes de session ACP/acpx, pas /codex
Cas d’utilisationConfigurerVérifierNotes
Abonnement ChatGPT/Codex avec runtime Codex natifopenai/gpt-* plus Plugin codex activé/status affiche Runtime: OpenAI CodexParcours recommandé
Échouer de façon fermée si Codex est indisponibleFournisseur ou modèle agentRuntime.id: "codex"Le tour échoue au lieu d’un repli PIÀ utiliser pour les déploiements Codex uniquement
Trafic direct par clé d’API OpenAI via PIFournisseur ou modèle agentRuntime.id: "pi" et authentification OpenAI normale/status affiche le runtime PIÀ utiliser uniquement lorsque PI est intentionnel
Configuration héritéeopenai-codex/gpt-*openclaw doctor --fix la réécritNe créez pas de nouvelle configuration ainsi
Adaptateur Codex ACP/acpxACP sessions_spawn({ runtime: "acp" })État de tâche/session ACPSéparé du harnais Codex natif
agents.defaults.imageModel suit la même séparation de préfixe. Utilisez openai/gpt-* pour la route OpenAI normale et codex/gpt-* uniquement lorsque la compréhension d’image doit s’exécuter via un tour Codex app-server borné. N’utilisez pas openai-codex/gpt-* ; doctor réécrit ce préfixe hérité en openai/gpt-*.

Modèles de déploiement

Déploiement Codex de base

Utilisez la configuration de démarrage rapide lorsque tous les tours d’agent OpenAI doivent utiliser Codex par défaut.
{
  plugins: {
    entries: {
      codex: {
        enabled: true,
      },
    },
  },
  agents: {
    defaults: {
      model: "openai/gpt-5.5",
    },
  },
}

Déploiement à fournisseurs mixtes

Cette forme conserve Claude comme agent par défaut et ajoute un agent Codex nommé :
{
  plugins: {
    entries: {
      codex: {
        enabled: true,
      },
    },
  },
  agents: {
    defaults: {
      model: "anthropic/claude-opus-4-6",
    },
    list: [
      {
        id: "main",
        default: true,
        model: "anthropic/claude-opus-4-6",
      },
      {
        id: "codex",
        name: "Codex",
        model: "openai/gpt-5.5",
      },
    ],
  },
}
Avec cette configuration, l’agent main utilise son chemin de fournisseur normal et l’agent codex utilise Codex app-server.

Déploiement Codex à échec fermé

Pour les tours d’agent OpenAI, openai/gpt-* se résout déjà vers Codex lorsque le Plugin inclus est disponible. Ajoutez une politique de runtime explicite lorsque vous voulez une règle écrite d’échec fermé :
{
  models: {
    providers: {
      openai: {
        agentRuntime: {
          id: "codex",
        },
      },
    },
  },
  agents: {
    defaults: {
      model: "openai/gpt-5.5",
    },
  },
  plugins: {
    entries: {
      codex: {
        enabled: true,
      },
    },
  },
}
Avec Codex forcé, OpenClaw échoue tôt si le Plugin Codex est désactivé, si l’app-server est trop ancien, ou si l’app-server ne peut pas démarrer.

Politique app-server

Par défaut, le Plugin démarre localement le binaire Codex géré par OpenClaw avec le transport stdio. Définissez appServer.command uniquement lorsque vous voulez intentionnellement exécuter un autre exécutable. Utilisez le transport WebSocket uniquement lorsqu’un app-server est déjà en cours d’exécution ailleurs :
{
  plugins: {
    entries: {
      codex: {
        enabled: true,
        config: {
          appServer: {
            transport: "websocket",
            url: "ws://gateway-host:39175",
            authToken: "${CODEX_APP_SERVER_TOKEN}",
          },
        },
      },
    },
  },
}
Les sessions locales de serveur d’application stdio utilisent par défaut la posture d’opérateur local approuvé : approvalPolicy: "never", approvalsReviewer: "user" et sandbox: "danger-full-access". Si les exigences locales de Codex interdisent cette posture YOLO implicite, OpenClaw sélectionne plutôt les permissions guardian autorisées. Lorsqu’un sandbox OpenClaw est actif pour la session, OpenClaw restreint danger-full-access de Codex à workspace-write de Codex afin que les tours en mode code natif de Codex restent dans l’espace de travail sandboxé. Utilisez le mode guardian lorsque vous voulez une revue automatique native de Codex avant les sorties de sandbox ou les permissions supplémentaires :
{
  plugins: {
    entries: {
      codex: {
        enabled: true,
        config: {
          appServer: {
            mode: "guardian",
            serviceTier: "priority",
          },
        },
      },
    },
  },
}
Le mode guardian s’étend aux approbations du serveur d’application Codex, généralement approvalPolicy: "on-request", approvalsReviewer: "auto_review" et sandbox: "workspace-write" lorsque les exigences locales autorisent ces valeurs. Pour chaque champ du serveur d’application, l’ordre d’authentification, l’isolation de l’environnement, la découverte et le comportement des délais d’expiration, consultez la référence du harnais Codex.

Commandes et diagnostics

Le Plugin intégré enregistre /codex comme commande slash sur tout canal qui prend en charge les commandes texte OpenClaw. Formes courantes :
  • /codex status vérifie la connectivité du serveur d’application, les modèles, le compte, les limites de débit, les serveurs MCP et les Skills.
  • /codex models liste les modèles actifs du serveur d’application Codex.
  • /codex threads [filter] liste les threads récents du serveur d’application Codex.
  • /codex resume <thread-id> attache la session OpenClaw actuelle à un thread Codex existant.
  • /codex compact demande au serveur d’application Codex de compacter le thread attaché.
  • /codex review démarre la revue native de Codex pour le thread attaché.
  • /codex diagnostics [note] demande confirmation avant d’envoyer les retours Codex pour le thread attaché.
  • /codex account affiche le statut du compte et des limites de débit.
  • /codex mcp liste l’état des serveurs MCP du serveur d’application Codex.
  • /codex skills liste les Skills du serveur d’application Codex.
Pour la plupart des rapports d’assistance, commencez par /diagnostics [note] dans la conversation où le bug s’est produit. Cela crée un rapport de diagnostics Gateway et, pour les sessions du harnais Codex, demande l’approbation pour envoyer le paquet de retours Codex pertinent. Consultez Export des diagnostics pour le modèle de confidentialité et le comportement des discussions de groupe. Utilisez /codex diagnostics [note] uniquement lorsque vous voulez précisément l’envoi des retours Codex pour le thread actuellement attaché, sans le paquet complet de diagnostics Gateway.

Inspecter les threads Codex localement

La façon la plus rapide d’inspecter une mauvaise exécution Codex consiste souvent à ouvrir directement le thread Codex natif :
codex resume <thread-id>
Récupérez l’identifiant de thread dans la réponse /diagnostics terminée, /codex binding ou /codex threads [filter]. Pour les mécanismes d’envoi et les limites des diagnostics au niveau de l’exécution, consultez Exécution du harnais Codex. L’authentification est sélectionnée dans cet ordre :
  1. Les profils d’authentification OpenAI ordonnés pour l’agent, de préférence sous auth.order.openai. Les identifiants de profil openai-codex:* existants restent valides.
  2. Le compte existant du serveur d’application dans le répertoire Codex de cet agent.
  3. Pour les lancements locaux du serveur d’application stdio uniquement, CODEX_API_KEY, puis OPENAI_API_KEY, lorsqu’aucun compte de serveur d’application n’est présent et que l’authentification OpenAI est toujours requise.
Lorsqu’OpenClaw détecte un profil d’authentification Codex de type abonnement ChatGPT, il supprime CODEX_API_KEY et OPENAI_API_KEY du processus enfant Codex lancé. Cela garde les clés API au niveau Gateway disponibles pour les embeddings ou les modèles OpenAI directs sans faire facturer accidentellement les tours natifs du serveur d’application Codex via l’API. Les profils explicites de clé API Codex et le repli local sur clé d’environnement stdio utilisent la connexion au serveur d’application au lieu de l’environnement hérité du processus enfant. Les connexions WebSocket au serveur d’application ne reçoivent pas le repli par clé API d’environnement Gateway ; utilisez un profil d’authentification explicite ou le compte propre du serveur d’application distant. Si un profil d’abonnement atteint une limite d’utilisation Codex, OpenClaw enregistre l’heure de réinitialisation lorsque Codex en signale une et essaie le profil d’authentification ordonné suivant pour la même exécution Codex. Lorsque l’heure de réinitialisation est passée, le profil d’abonnement redevient éligible sans modifier le modèle openai/gpt-* sélectionné ni l’exécution Codex. Si un déploiement nécessite une isolation supplémentaire de l’environnement, ajoutez ces variables à appServer.clearEnv :
{
  plugins: {
    entries: {
      codex: {
        enabled: true,
        config: {
          appServer: {
            clearEnv: ["CODEX_API_KEY", "OPENAI_API_KEY"],
          },
        },
      },
    },
  },
}
appServer.clearEnv n’affecte que le processus enfant du serveur d’application Codex lancé. Les outils dynamiques Codex utilisent par défaut le chargement searchable. OpenClaw n’expose pas les outils dynamiques qui dupliquent les opérations natives de Codex sur l’espace de travail : read, write, edit, apply_patch, exec, process et update_plan. Les autres outils d’intégration OpenClaw comme la messagerie, les sessions, les médias, cron, le navigateur, les nœuds, gateway, heartbeat_respond et web_search sont disponibles via la recherche d’outils Codex sous l’espace de noms openclaw, ce qui réduit le contexte initial du modèle. sessions_yield et les réponses de source réservées à l’outil de messagerie restent directes, car ce sont des contrats de contrôle de tour. Les instructions de collaboration Heartbeat indiquent à Codex de rechercher heartbeat_respond avant de terminer un tour Heartbeat lorsque l’outil n’est pas déjà chargé. Définissez codexDynamicToolsLoading: "direct" uniquement lorsque vous vous connectez à un serveur d’application Codex personnalisé qui ne peut pas rechercher les outils dynamiques différés, ou lors du débogage de la charge utile complète des outils. Champs de Plugin Codex de premier niveau pris en charge :
ChampValeur par défautSignification
codexDynamicToolsLoading"searchable"Utilisez "direct" pour placer les outils dynamiques OpenClaw directement dans le contexte initial des outils Codex.
codexDynamicToolsExclude[]Noms supplémentaires d’outils dynamiques OpenClaw à omettre des tours du serveur d’application Codex.
codexPluginsdésactivéPrise en charge native des plugins/applications Codex pour les plugins organisés migrés installés depuis la source.
Champs appServer pris en charge :
ChampValeur par défautSignification
transport"stdio""stdio" lance Codex ; "websocket" se connecte à url.
commandbinaire Codex géréExécutable pour le transport stdio. Laissez non défini pour utiliser le binaire géré ; définissez-le uniquement pour une surcharge explicite.
args["app-server", "--listen", "stdio://"]Arguments pour le transport stdio.
urlnon définiURL WebSocket du serveur d’application.
authTokennon définiJeton Bearer pour le transport WebSocket.
headers{}En-têtes WebSocket supplémentaires.
clearEnv[]Noms de variables d’environnement supplémentaires supprimés du processus du serveur d’application stdio lancé après qu’OpenClaw a construit son environnement hérité. CODEX_HOME et HOME sont réservés à l’isolation Codex par agent d’OpenClaw lors des lancements locaux.
requestTimeoutMs60000Délai d’expiration pour les appels du plan de contrôle du serveur d’application.
turnCompletionIdleTimeoutMs60000Fenêtre de silence après une requête de serveur d’application Codex limitée à un tour, pendant qu’OpenClaw attend turn/completed. Augmentez cette valeur pour les phases lentes de synthèse après outil ou uniquement de statut.
mode"yolo" sauf si les exigences locales de Codex interdisent YOLOPréréglage pour l’exécution YOLO ou revue par guardian. Les exigences locales stdio qui omettent danger-full-access, l’approbation never ou le réviseur user rendent la valeur implicite par défaut guardian.
approvalPolicy"never" ou une stratégie d’approbation guardian autoriséeStratégie d’approbation native Codex envoyée au démarrage, à la reprise ou au tour du thread. Les valeurs par défaut guardian privilégient "on-request" lorsque c’est autorisé.
sandbox"danger-full-access" ou un sandbox guardian autoriséMode sandbox natif Codex envoyé au démarrage ou à la reprise du thread. Les valeurs par défaut guardian privilégient "workspace-write" lorsque c’est autorisé, sinon "read-only". Lorsqu’un sandbox OpenClaw est actif, danger-full-access est restreint à "workspace-write".
approvalsReviewer"user" ou un réviseur guardian autoriséUtilisez "auto_review" pour laisser Codex examiner les invites d’approbation natives lorsque c’est autorisé, sinon guardian_subagent ou user. guardian_subagent reste un alias hérité.
serviceTiernon définiNiveau de service facultatif du serveur d’application Codex. "priority" active le routage en mode rapide, "flex" demande un traitement flex, null efface la surcharge, et l’ancienne valeur "fast" est acceptée comme "priority".
Les appels d’outils dynamiques détenus par OpenClaw sont limités indépendamment de appServer.requestTimeoutMs : les requêtes Codex item/tool/call utilisent par défaut un chien de garde OpenClaw de 30 secondes. Un argument positif timeoutMs par appel allonge ou raccourcit le budget de cet outil spécifique. L’outil image_generate utilise aussi agents.defaults.imageGenerationModel.timeoutMs lorsque l’appel d’outil ne fournit pas son propre délai d’expiration, et l’outil image de compréhension des médias utilise tools.media.image.timeoutSeconds ou son délai média par défaut de 60 secondes. Les budgets d’outils dynamiques sont plafonnés à 600000 ms. En cas de délai d’expiration, OpenClaw abandonne le signal de l’outil lorsque c’est pris en charge et renvoie à Codex une réponse d’outil dynamique échouée afin que le tour puisse continuer au lieu de laisser la session en processing. Après qu’OpenClaw répond à une requête de serveur d’application à portée de tour Codex, le harnais attend aussi de Codex qu’il termine le tour natif avec turn/completed. Si le serveur d’application reste silencieux pendant appServer.turnCompletionIdleTimeoutMs après cette réponse, OpenClaw interrompt au mieux le tour Codex, enregistre un diagnostic de délai d’expiration et libère la voie de session OpenClaw afin que les messages de chat suivants ne soient pas mis en file derrière un tour natif obsolète. Toute notification non terminale pour le même tour, y compris rawResponseItem/completed, désarme ce court chien de garde, car Codex a prouvé que le tour est encore actif ; le chien de garde terminal plus long continue à protéger les tours réellement bloqués. Les notifications globales du serveur d’application, comme les mises à jour de limite de débit, ne réinitialisent pas la progression d’inactivité du tour. Lorsque Codex émet un élément agentMessage terminé puis reste silencieux sans turn/completed, OpenClaw considère que la sortie de l’assistant est effectivement terminée, interrompt au mieux le tour Codex natif et libère la voie de session. Les diagnostics de délai d’expiration incluent la dernière méthode de notification du serveur d’application et, pour les éléments de réponse assistant bruts, le type d’élément, le rôle, l’id et un aperçu borné du texte de l’assistant. Les substitutions d’environnement restent disponibles pour les tests locaux :
  • OPENCLAW_CODEX_APP_SERVER_BIN
  • OPENCLAW_CODEX_APP_SERVER_ARGS
  • OPENCLAW_CODEX_APP_SERVER_MODE=yolo|guardian
  • OPENCLAW_CODEX_APP_SERVER_APPROVAL_POLICY
  • OPENCLAW_CODEX_APP_SERVER_SANDBOX
OPENCLAW_CODEX_APP_SERVER_BIN contourne le binaire géré lorsque appServer.command n’est pas défini. OPENCLAW_CODEX_APP_SERVER_GUARDIAN=1 a été supprimé. Utilisez plutôt plugins.entries.codex.config.appServer.mode: "guardian", ou OPENCLAW_CODEX_APP_SERVER_MODE=guardian pour des tests locaux ponctuels. La configuration est préférable pour les déploiements répétables, car elle conserve le comportement du Plugin dans le même fichier révisé que le reste de la configuration du harnais Codex.

Plugins Codex natifs

La prise en charge des Plugins Codex natifs utilise les propres capacités d’application et de Plugin du serveur d’application Codex dans le même fil Codex que le tour du harnais OpenClaw. OpenClaw ne traduit pas les Plugins Codex en outils dynamiques OpenClaw synthétiques codex_plugin_*. codexPlugins n’affecte que les sessions qui sélectionnent le harnais Codex natif. Il n’a aucun effet sur les exécutions PI, les exécutions normales du fournisseur OpenAI, les liaisons de conversation ACP ni les autres harnais. Configuration migrée minimale :
{
  plugins: {
    entries: {
      codex: {
        enabled: true,
        config: {
          codexPlugins: {
            enabled: true,
            allow_destructive_actions: true,
            plugins: {
              "google-calendar": {
                enabled: true,
                marketplaceName: "openai-curated",
                pluginName: "google-calendar",
              },
            },
          },
        },
      },
    },
  },
}
La configuration de l’application de fil est calculée lorsqu’OpenClaw établit une session de harnais Codex ou remplace une liaison de fil Codex obsolète. Elle n’est pas recalculée à chaque tour. Après avoir modifié codexPlugins, utilisez /new, /reset, ou redémarrez le Gateway afin que les futures sessions de harnais Codex démarrent avec l’ensemble d’applications mis à jour. Pour l’éligibilité à la migration, l’inventaire des applications, la politique d’actions destructrices, les élicitations et les diagnostics de Plugin natif, consultez Plugins Codex natifs.

Computer Use

Computer Use est couvert dans son propre guide de configuration : Codex Computer Use. En bref : OpenClaw ne vendore pas l’application de contrôle du bureau et n’exécute pas lui-même d’actions sur le bureau. Il prépare le serveur d’application Codex, vérifie que le serveur MCP computer-use est disponible, puis laisse Codex détenir les appels d’outils MCP natifs pendant les tours en mode Codex.

Limites d’exécution

Le harnais Codex ne modifie que l’exécuteur d’agent intégré de bas niveau.
  • Les outils dynamiques OpenClaw sont pris en charge. Codex demande à OpenClaw d’exécuter ces outils, OpenClaw reste donc dans le chemin d’exécution.
  • Les outils natifs shell, patch, MCP et application de Codex sont détenus par Codex. OpenClaw peut observer ou bloquer certains événements natifs via le relais pris en charge, mais il ne réécrit pas les arguments des outils natifs.
  • Codex détient la Compaction native. OpenClaw conserve un miroir de transcription pour l’historique du canal, la recherche, /new, /reset et le futur changement de modèle ou de harnais.
  • La génération de médias, la compréhension des médias, la synthèse vocale, les approbations et la sortie de l’outil de messagerie continuent à passer par les paramètres de fournisseur/modèle OpenClaw correspondants.
  • tool_result_persist s’applique aux résultats d’outils de transcription détenus par OpenClaw, et non aux enregistrements de résultats d’outils natifs Codex.
Pour les couches de hooks, les surfaces V1 prises en charge, la gestion native des permissions, le pilotage de file d’attente, les mécanismes d’envoi des retours Codex et les détails de Compaction, consultez Exécution du harnais Codex.

Dépannage

Codex n’apparaît pas comme un fournisseur /model normal : c’est attendu pour les nouvelles configurations. Sélectionnez un modèle openai/gpt-*, activez plugins.entries.codex.enabled, et vérifiez si plugins.allow exclut codex. OpenClaw utilise PI au lieu de Codex : assurez-vous que la référence de modèle est openai/gpt-* sur le fournisseur OpenAI officiel et que le Plugin Codex est installé et activé. Si vous avez besoin d’une preuve stricte pendant les tests, définissez agentRuntime.id: "codex" pour le fournisseur ou le modèle. Une exécution Codex forcée échoue au lieu de revenir à PI. Une configuration héritée openai-codex/* subsiste : exécutez openclaw doctor --fix. Doctor réécrit les références de modèles héritées en openai/*, supprime les épingles d’exécution de session et d’agent entier obsolètes, et préserve les substitutions de profil d’authentification existantes. Le serveur d’application est rejeté : utilisez le serveur d’application Codex 0.125.0 ou plus récent. Les préversions de même version ou les versions avec suffixe de build comme 0.125.0-alpha.2 ou 0.125.0+custom sont rejetées car OpenClaw teste le plancher de protocole stable 0.125.0. /codex status ne peut pas se connecter : vérifiez que le Plugin codex groupé est activé, que plugins.allow l’inclut lorsqu’une liste d’autorisation est configurée, et que tout appServer.command, url, authToken ou en-tête personnalisé est valide. La découverte de modèles est lente : réduisez plugins.entries.codex.config.discovery.timeoutMs ou désactivez la découverte. Consultez Référence du harnais Codex. Le transport WebSocket échoue immédiatement : vérifiez appServer.url, authToken, les en-têtes, et que le serveur d’application distant parle la même version du protocole de serveur d’application Codex. Un modèle non-Codex utilise PI : c’est attendu sauf si la politique d’exécution du fournisseur ou du modèle le route vers un autre harnais. Les références simples de fournisseurs non-OpenAI restent sur leur chemin de fournisseur normal en mode auto. Computer Use est installé mais les outils ne s’exécutent pas : vérifiez /codex computer-use status depuis une nouvelle session. Si un outil signale Native hook relay unavailable, utilisez /new ou /reset ; si cela persiste, redémarrez le Gateway pour effacer les inscriptions de hooks natifs obsolètes. Consultez Codex Computer Use.

Connexe