Comment connecter Codex à WordPress

Codex peut fonctionner avec WordPress par l’intermédiaire d’un dépôt de code local, d’un outil REST conçu à cette fin ou d’un serveur MCP. L’interface en ligne de commande Codex et l’extension IDE prennent en charge les serveurs MCP et partagent leur configuration MCP sur le même hôte Codex. La connexion WordPress a néanmoins besoin de son propre modèle d’authentification et de permissions.

Commencez avec un projet approuvé et une identité WordPress dédiée en lecture seule. Conservez les identifiants dans des variables d’environnement ou un magasin de secrets approuvé, et non dans .codex/config.toml ou le dépôt.

En une phrase : Connectez Codex à une surface d’outils WordPress définie, mais laissez une identité WordPress distincte déterminer ce qu’il est réellement autorisé à faire.

Ce que ce guide vous aide à accomplir

Ce guide sépare la configuration de Codex de l’authentification WordPress et exige une preuve d’exécution avant qu’une affirmation de compatibilité ne devienne publique.

Un flux de travail d’IA utile n’est pas défini seulement par la qualité de la réponse. Il est aussi défini par les données que l’assistant peut atteindre, les actions qu’il est autorisé à effectuer, les preuves que vous pouvez examiner par la suite et la facilité avec laquelle l’accès peut être retiré.

Pourquoi cela importe

Codex est souvent utilisé dans des dépôts, donc les utilisateurs peuvent supposer qu’ouvrir une base de code WordPress équivaut à se connecter au site en direct. Ce n’est pas le cas. L’accès au dépôt peut modifier des fichiers de code ; l’accès REST ou MCP de WordPress peut récupérer et modifier des enregistrements du site. Ces surfaces nécessitent des identifiants et des processus de révision distincts.

La documentation actuelle de Codex d’OpenAI stocke la configuration MCP dans ~/.codex/config.toml ou dans .codex/config.toml limité à un projet pour les projets approuvés. Cette configuration doit indiquer comment lancer ou joindre le serveur, tandis que les secrets demeurent externes.

Résultat attendu

Une exécution réussie doit produire :

• Un flux de travail Codex choisi pour le code, les données ou les actions.
• une portée de projet approuvée et une configuration MCP documentée lorsqu’elle est utilisée.
• Une identité WordPress distincte en lecture seule.
• Un test de lecture réussi, un test d’écriture refusé et un test de révocation.
• Un enregistrement de compatibilité lié à une version.

Séparez l’accès au dépôt de l’accès au site

Codex peut examiner et modifier un dépôt d’extension ou de thème sans aucune connexion à la production WordPress. À l’inverse, un outil REST ou MCP peut manipuler du contenu WordPress sans accorder d’accès au système de fichiers. Décidez de la surface dont la tâche a besoin et n’exposez pas les deux par défaut.

Préparez la configuration MCP de Codex

La documentation officielle actuelle prend en charge les serveurs MCP STDIO et HTTP diffusables. Codex peut être configuré au moyen de commandes CLI ou de config.toml. La configuration au niveau du projet n’est chargée que pour les projets approuvés, ce qui aide à empêcher qu’un dépôt arbitraire fournisse silencieusement des outils.

Consignez la version du client actif, l’identité du serveur configuré et les outils que Codex voit dans la session.

Gardez les identifiants WordPress hors de la configuration

Utilisez une variable d’environnement ou un mécanisme de secrets approuvé pour un mot de passe d’application ou un jeton de connecteur. Le fichier de configuration peut contenir le nom de la variable d’environnement, mais non sa valeur. Si le serveur prend en charge OAuth ou un autre mécanisme, documentez séparément sa révocation et son stockage.

Prouvez la limite effective

Demandez à Codex de lister un ensemble connu de contenu à l’aide de l’outil connecté. Demandez-lui ensuite d’effectuer une opération en dehors du mode de l’identité. Capturez l’appel d’outil et la réponse WordPress. Une réponse soignée de Codex ne suffit pas ; l’environnement doit imposer le refus.

Un flux de travail sécuritaire

1. Classez la tâche comme travail de code local, accès aux données WordPress ou action WordPress.
2. Choisissez un connecteur approuvé et vérifiez sa documentation principale.
3. Créez une identité WordPress dédiée en lecture seule.
4. Placez les identifiants dans des variables d’environnement ou un gestionnaire de secrets.
5. Configurez le serveur MCP dans un projet Codex approuvé ou dans la portée utilisateur.
6. Examinez les outils disponibles avant d’exécuter la tâche.
7. Exécutez une lecture connue et une écriture intentionnellement interdite.
8. Révoquez l’identifiant WordPress et confirmez que l’appel suivant échoue.

Modèle de prompt

Avant de copier ce prompt, remplacez chaque valeur entre crochets. Ne collez pas d’identifiants, de données client ou de renseignements privés dans l’instruction.

Utilisez uniquement les outils WordPress connectés.

Objectif : vérifier l’accès en lecture seule.

1. Listez les cinq pages publiées les plus récentes.
2. Renvoyez l’ID, le titre, l’URL, l’état et l’horodatage de dernière modification.
3. Ne modifiez aucun enregistrement.
4. N’utilisez pas l’interpréteur de commandes, l’automatisation de navigateur ou les fichiers du dépôt comme substitut à l’outil WordPress.
5. Signalez les noms exacts des outils utilisés et tout champ indisponible.
6. Arrêtez-vous après le tableau et le résumé des outils.

Pourquoi le prompt est structuré ainsi

Le prompt maintient Codex sur la surface d’outils WordPress prévue et l’empêche d’utiliser des capacités locales plus larges comme solution de contournement accidentelle. Les noms d’outils et les champs indisponibles créent une piste de preuves pour le test d’intégration.

Limite d’accès recommandée

Utilisez une identité en lecture seule. L’assistant peut examiner les données WordPress incluses dans sa portée, mais toute tentative de créer, modifier, supprimer ou publier du contenu doit être refusée.

Ce flux de travail peut influencer des décisions éditoriales ou créer des changements non publiés. Gardez la portée étroite et examinez chaque changement proposé.

Le niveau d’accès est une recommandation de départ, et non un droit universel. Les capacités WordPress exactes disponibles à une identité doivent provenir de la version de produit installée et de sa couverture publiée, non de cet article seul.

Ce qui doit demeurer hors de la tâche

• Ne faites pas confiance à une configuration limitée au projet dans un dépôt non approuvé.
• Ne stockez pas les identifiants WordPress dans config.toml et ne les validez pas dans le dépôt.
• Ne laissez pas l’accès en écriture au dépôt se substituer à un flux de travail contrôlé de contenu WordPress.
• N’affirmez pas la compatibilité sur la seule base du soutien générique de Codex pour MCP.

Comment WP Agent Control s’intègre

Le dossier privé guidé pour Claude Code ou Codex utilise l’API REST WordPress et un mot de passe d’application avec un profil dédié en lecture seule. Les profils Read Only, Draft, Content Editor et Publisher existants restent dans les options avancées. Ils ne sont pas automatiquement convertis à OAuth et ne reprennent pas le modèle de tâches distantes et d’approbation exacte.

Obtenez des informations structurées sur le site et examinez des pages publiées après la connexion. Cette lecture publique ne nécessite aucune tâche temporaire. Vous pouvez aussi consulter les pages publiques sans le plugin ; Agent Control ajoute un accès structuré et la continuité vers du travail WordPress autorisé.

Connecter votre IA : docs first profile · Voir les fonctions et la compatibilité : coverage

Liste de vérification

• ☐ Le projet Codex est approuvé et sa portée est documentée.
• ☐ Le paquet de connecteur ou le point de terminaison est versionné.
• ☐ Les secrets sont externes à la configuration et au dépôt.
• ☐ Les outils MCP disponibles sont capturés.
• ☐ Les tests de lecture, de refus et de révocation réussissent.
• ☐ Le guide public nomme chaque version incluse dans la portée.

Modes de défaillance fréquents

• Supposer que le dépôt est le site en direct : L’accès au code et l’accès aux données WordPress sont des surfaces distinctes.
• Mettre les identifiants dans TOML : Une configuration pratique devient un problème de distribution de secrets.
• Utiliser un outil Codex plus large comme solution de contournement : L’accès à l’interpréteur de commandes ou au navigateur peut contourner la limite WordPress prévue et invalider le test.
• Traiter la découverte d’outils comme une preuve d’exécution : Voir le nom d’un outil ne prouve ni l’authentification, ni l’application des permissions, ni la justesse du résultat.

Note avancée

Un test Codex rigoureux doit épingler le paquet de connecteur lorsque possible, enregistrer les instructions d’initialisation MCP, capturer le schéma des outils du serveur et le comparer aux capacités effectives de l’identité WordPress. L’exposition des outils doit être inférieure ou égale à la politique, jamais l’unique source de la politique.

Guides connexes

• MCP WordPress expliqué simplement
• Fonctionnement de l’adaptateur MCP officiel de WordPress
• Mots de passe d’application WordPress pour les connexions IA
• Quel niveau d’accès WordPress devriez-vous donner à une IA ?

Continuer

Prochaine étape : ouvrez Quel niveau d’accès WordPress devriez-vous donner à une IA ?, choisissez le plus petit niveau d’accès approprié, puis suivez le guide de connexion pertinent. Lorsque vous êtes prêt à créer une identité distincte et révocable, examinez Produit ou commencez l’essai Solo de 7 jours.