Aller au contenu principal

Agent Plugins Codex & fédération de catalogues (v0.147.0) : le guide pratique

Intermédiaire

Le 7 août 2026, OpenAI a livré Codex CLI v0.147.0. La plupart des articles l'ont réduit à une seule ligne (« maintenant il y a des plugins, cool »). La vraie livraison change quatre choses en même temps, et trois d'entre elles cassent silencieusement des scripts qui tournent probablement déjà dans votre CI aujourd'hui : les Agent Plugins portables remplacent les installations de skills ad hoc et se fusionnent à travers un catalogue à quatre niveaux ; un nouveau flag --approve-for-me ressemble à « approuve tout automatiquement » mais ne fait pas cela ; l'ancien raccourci --full-auto est supprimé ; et Codex propose désormais MCP 2026-07-28 en opt-in avec démarrage de serveur non bloquant. Chaque changement a un piège qu'il vaut mieux connaître avant la mise à jour.

Cette page est le guide de terrain pratique pour un lecteur qui comprend déjà les Skills Claude Code, les sous-agents et MCP — et qui veut simplement savoir ce que fait vraiment la version Codex, où elle diffère, et ce qu'il faut changer dans un workflow du lundi matin.

What you'll learn
  • Savoir exactement ce qui a été livré dans Codex CLI v0.146.1 (5 août) et v0.147.0 (7 août), et pourquoi les deux ensemble comptent
  • Comprendre le catalogue à quatre niveaux — local, personnel, workspace, distant — et les règles de fusion/dédoublonnage qui décident quel plugin l'emporte réellement
  • Lire `--approve-for-me` correctement : c'est une passe de revue, pas un contournement du sandbox ; le sandbox système reste actif
  • Migrer hors du flag `--full-auto` retiré avant que votre prochain run CI n'échoue silencieusement
  • Décider quand activer MCP 2026-07-28 en opt-in dans Codex — et ce que le démarrage de serveur non bloquant vous apporte

Le tableau à deux versions : 0.146.1 puis 0.147.0​

La livraison d'août est en réalité deux versions à 48 heures d'écart, et les lire comme une seule brouille ce qui a changé.

Guided walkthrough1 of 3
  1. Une version mineure discrète, mais elle a changé la *posture de départ* pour les modèles étiquetés cyber-capables (la même classe qui inclut GPT-5.6-Cyber). Les défauts d'auto-approbation se resserrent : réseau, lecture d'identifiants et gestion de processus exigent désormais une liste blanche explicite au lieu de s'appuyer sur l'ancienne base permissive. Codex a aussi commencé à expliquer les changements de permission dans le terminal — vous voyez *pourquoi* une requête a été bloquée, pas juste qu'elle l'a été.

Agent Plugins portables : ce qui a changé au niveau fichier​

Codex avait déjà des Skills — un dossier SKILL.md + fichiers voisins que tout agent conforme peut charger — pour toute l'année 2026. La v0.147.0 ajoute une couche paquet au-dessus : les Agent Plugins. Un plugin est une unité distribuable qui peut regrouper un ou plusieurs skills, serveurs MCP, prompts et configuration en un seul artefact que vous installez par nom depuis un catalogue. Les Skills restent portables entre agents ; les plugins sont la couche de packaging et de distribution propre à Codex.

Le changement important est comment ils sont découverts. Avant la v0.147.0, vous copiiez un dossier de skill dans votre projet ou dossier personnel à la main. Après la v0.147.0, Codex regarde à quatre endroits et fusionne les résultats.

Le catalogue à quatre niveaux — et la règle de fusion qui décide qui gagne​

Codex parcourt quatre catalogues dans un ordre de priorité fixe. Quand deux catalogues contiennent un plugin du même nom, celui de plus haute priorité gagne et la copie de plus basse priorité est masquée.

NiveauEmplacementPropriétaireUsage typique
1. Local.codex/plugins/ dans le dépôtCommité au projetOutillage spécifique au dépôt ; voyage avec la branche
2. Personnel~/.codex/plugins/Vous seul, sur votre machineVos propres plugins faits maison ou expérimentaux
3. WorkspacePortée workspace partagée en équipeVotre équipeConventions partagées, flux de revue, scripts de déploiement
4. DistantRacines de marketplace que vous configurezVendeurs + communautéPlugins publics depuis marketplace.openai.com ou registres internes

Règle de fusion : les résultats sont dédoublonnés par nom de plugin, et la copie de plus haute priorité est présentée en premier. Un plugin terraform-drift commité à .codex/plugins/terraform-drift/ dans votre dépôt masque silencieusement la version du catalogue distant du même nom. C'est voulu — les dépôts doivent pouvoir figer une version connue-bonne — mais c'est la source numéro un des « pourquoi mon plugin se comporte différemment de ce que dit la doc ? » à la mise à jour.

:::tip Lisez codex plugin list avant de déboguer un comportement codex plugin list affiche les plugins installés avec le niveau source depuis lequel chacun a été résolu. Si un plugin fait quelque chose de surprenant, c'est la première commande à lancer — la version que vous utilisez n'est peut-être pas celle que vous croyez utiliser. :::

Configurer les catalogues — le config.toml minimal​

Les endpoints marketplace et le comportement d'auto-update se règlent dans le config.toml de Codex. Le défaut v0.147.0 garde auto_update = false, ce qui est le bon choix pour la reproductibilité mais implique de lancer les mises à jour délibérément.

# ~/.codex/config.toml
[plugins]
enabled = true
marketplace_roots = [
  "https://plugins.internal.example.com",
  "https://marketplace.openai.com"
]
auto_update = false
update_check_interval_hours = 24

La limite d'entrées de catalogue est passée de 512 à 2 048 en v0.147.0 — un petit nombre qui compte si vous pointez Codex vers un large registre interne. Sous 512, les plugins au-delà du plafond étaient silencieusement tronqués des résultats de recherche ; les équipes d'entreprise l'ont assez rencontré pour qu'OpenAI relève le plafond.

Travailler avec les plugins — les commandes du quotidien​

Parcourir le catalogue fusionné dans un sélecteur interactif

/plugins

Chercher les quatre niveaux à la fois

codex plugin marketplace search "terraform"

Installer la correspondance de plus haute priorité par nom

codex plugin install terraform-drift

Voir ce qui est installé ET de quel niveau chacun vient

codex plugin list

Mettre à jour tous les plugins installés (opt-in — auto_update désactivé par défaut)

codex plugin update

Trois durcissements de sécurité dans l'install de plugin​

Le chemin d'installation de plugin en v0.147.0 a discrètement resserré trois choses — toutes utiles à connaître car elles changent ce que « l'install fonctionne » signifie.

Guided walkthrough1 of 3
  1. Si un paquet de plugin contient un lien symbolique, Codex ignore le lien au lieu de le suivre. Cela bloque toute une classe d'attaques par traversée de chemin — un plugin malveillant ne peut plus lier `plugin/config` → `/etc/passwd`. Le compromis : les paquets légitimes qui utilisaient des liens symboliques pour des ressources partagées doivent les intégrer directement.

--approve-for-me : ce qu'il fait réellement (et ne fait pas)​

Le nom se lit comme « approuve automatiquement toute requête ». Ce n'est pas ce que le flag fait. --approve-for-me route les demandes d'approbation via une passe de revue automatique qui juge chaque requête contre votre mode sandbox actif et votre configuration de politique d'approbation. Si la politique dit « oui, c'est dans la liste blanche », la requête passe sans prompt. Si la politique dit « non ou incertain », la requête est refusée — on ne vous demande simplement pas au milieu d'un run.

Deux choses qui restent vraies :

  • Le sandbox système reste appliqué. Sur Linux via Bubblewrap ; sur macOS via le sandbox de la plateforme. --approve-for-me ne peut pas s'échapper du sandbox ; il peut seulement décider s'il faut auto-répondre aux prompts à l'intérieur.
  • Les modèles cyber-capables reçoivent automatiquement les défauts plus sûrs de la v0.146.1. Accès réseau, lecture d'identifiants et gestion de processus restent refusés sauf mise en liste blanche explicite, peu importe ce que dit --approve-for-me.

Le bon modèle mental : --approve-for-me transforme votre fichier de politique en humain. Si votre politique est lâche, ce flag est dangereux ; si votre politique est stricte, ce flag est la pièce manquante pour les runs non surveillés.

Run interactif — la politique juge les approbations, le sandbox reste actif

codex --approve-for-me --sandbox workspace-write "refactor auth and run tests"

Run exec (non interactif) avec un contrat de sortie structuré

codex exec --approve-for-me --sandbox workspace-write \
--output-schema '{"type":"object","properties":{"passed":{"type":"boolean"}}}' \
"run the full test suite"

Une politique d'approbation minimale qui va sensément avec le flag :

# ~/.codex/config.toml
[approval_policy]
sandbox_mode = "workspace-write"

[approval_policy.network]
allowed = ["api.github.com", "registry.npmjs.org"]

Tout ce qui n'est pas sur cette liste blanche est refusé — y compris par --approve-for-me.

Le breaking change silencieux : --full-auto est supprimé​

Si vous avez des CI ou Makefiles qui appellent codex exec --full-auto, ils cassent en v0.147.0. Le flag a disparu. Le remplaçant est explicite :

# Avant v0.147.0 (cassé maintenant)
codex exec --full-auto "run tests"

# Syntaxe v0.147.0
codex exec --sandbox workspace-write "run tests"

Les deux ne sont pas identiques : --full-auto combinait un choix de sandbox et un choix de politique d'approbation. La nouvelle forme exige de déclarer le sandbox explicitement, et si vous voulez récupérer la moitié « ne me demande pas », ajoutez --approve-for-me. Ça vaut le coup de grep avant de mettre à jour un runner partagé.

MCP 2026-07-28 dans Codex — trois choses que vous obtenez vraiment​

Codex a rendu la nouvelle spec MCP opt-in en v0.147.0. Activez-la quand un serveur dont vous dépendez a migré ; laissez-la off sinon. Trois gains concrets si vous basculez :

  • Découverte paginée. Les serveurs qui exposent 200+ outils ne forcent plus une liste géante d'un coup ; le client les feuillette par pages. La latence jusqu'au premier outil devient bien plus basse.
  • Requêtes multi-tours. Une seule opération logique peut s'étendre sur plusieurs allers-retours client↔serveur — pensez à un formulaire interactif, une confirmation en deux temps, ou une lecture de ressource qui retourne un token de suivi. Avant 2026-07-28, il fallait tout caser dans une seule charge utile.
  • Démarrage de serveur non bloquant. Codex ne bloque plus son propre démarrage sur des serveurs MCP lents. Un serveur qui met 4 secondes à chauffer gelait auparavant tout le CLI ; maintenant Codex démarre, et le serveur est marqué prêt quand il l'est.

Comment cela se mappe sur Claude Code, en un tableau​

Si votre instinct est Claude, voici la table de traduction pour les mêmes concepts.

ConceptCodex CLI (v0.147.0)Claude Code
Unité d'instruction portableSkill (dossier SKILL.md)Skill (dossier SKILL.md) — même standard ouvert
Packaging / distributionAgent Plugin (regroupe skills, MCPs, config)Marketplace de plugins + install de skill
Portée de découverteCatalogue à quatre niveaux (local → personnel → workspace → distant)Projet + utilisateur + marketplace
Auto-approuver dans le sandbox--approve-for-me + approval_policyPermissions dans ~/.claude/settings.json
Application du sandboxBubblewrap (Linux) / sandbox macOSSandbox avec masquage d'identifiants
Serveurs MCP longue duréeDémarrage non bloquant (MCP 2026-07-28)Démarrage bloquant sauf opt-in
« Instructions dans le dépôt ».codex/plugins/, AGENTS.md.claude/, CLAUDE.md

La plus grande différence pratique : le catalogue à quatre niveaux de Codex avec le masquage in-repo .codex/plugins/ est plus agressif que le défaut Claude Code. C'est une fonctionnalité — un dépôt peut épingler une version de plugin et être sûr que tout le monde la lance — mais cela veut dire que « j'ai mis à jour mon plugin et rien n'a changé » est souvent « ton dépôt épinglait une ancienne copie ».

Une checklist de migration pour les équipes déjà sur Codex​

Guided walkthrough1 of 6
  1. C'est la cause la plus fréquente d'un CI vert qui passe au rouge après le saut de `codex --version`.

Quand les plugins Codex battent les sous-agents Claude — et quand non​

Les plugins Codex sont les plus forts quand l'unité de réutilisation est un paquet de workflow — un flux de revue, une séquence de déploiement, un sweep Terraform-drift — que vous voulez livrer comme un artefact unique à toute une équipe, avec versioning et marketplace derrière. Le catalogue à quatre niveaux est vraiment utile dans les organisations qui ont besoin de « le plugin de reviewer que l'équipe plateforme livre, sauf si mon dépôt le surcharge ».

Le modèle sous-agent-plus-skill de Claude Code est plus fort quand l'unité de réutilisation est un rôle (« code-reviewer », « debugger ») qui se compose librement dans une seule session interactive, et quand vous voulez que le même fichier tourne dans ChatGPT, Cursor, Gemini CLI et Codex sans re-packaging. Les Skills restent la primitive la plus portable ; les plugins sont la couche de distribution la plus puissante.

La réponse pratique pour la plupart des équipes en août 2026 est les deux : garder les skills comme primitive au niveau fichier pour qu'ils voyagent entre agents, et les emballer dans un Codex Agent Plugin quand vous avez besoin de la marketplace, de la fédération de catalogues et de l'épinglage.

Check yourself

0/4
  1. Deux catalogues contiennent un plugin nommé `terraform-drift` : un commité à `.codex/plugins/` dans le dépôt, un sur `marketplace.openai.com`. Lequel Codex utilise-t-il ?
  2. Vous lancez `codex exec --approve-for-me --sandbox workspace-write "install curl and hit a random URL"`. Votre politique d'approbation n'autorise que `api.github.com`. Que se passe-t-il ?
  3. Votre Makefile CI appelle encore `codex exec --full-auto "run tests"`. Après la mise à jour vers v0.147.0, le job échoue. Quel est le correctif minimal qui préserve l'intention d'origine ?
  4. Quelle fonctionnalité MCP 2026-07-28 corrige le plus directement « Codex met 4 secondes à démarrer parce qu'un serveur MCP est lent à chauffer » ?

Sources et lectures complémentaires​