Les hooks Codex donnent corps au cadre d’agent

Depuis Codex 0.150.1 (27 août 2026), les hooks Codex enregistrent douze événements de cycle de vie, refusent d’exécuter tout hook non managé tant que vous n’avez pas relu et approuvé sa définition exacte, et sont activés par défaut. La fonctionnalité passée en disponibilité générale dans le lot de lancement du 14 mai, aux côtés de l’application mobile ChatGPT, a mûri en surface de gouvernance : PreToolUse peut bloquer ou réécrire un appel d’outil avant son exécution, PermissionRequest peut trancher une validation, PostToolUse peut remplacer le résultat que voit le modèle, et Stop peut refuser de laisser un tour se terminer.²³

Codex ne ressemble plus à un assistant de code qui attend dans un terminal. Il ressemble à une couche d’exploitation qui suit le travail entre machines, validations, projets, fils de discussion, diffs, tests, captures d’écran, plugins, identifiants et outils locaux.⁴

Les hooks Codex donnent corps au cadre d’agent. Dès lors que l’agent peut travailler depuis un téléphone, atteindre des environnements de développement distants et exécuter des hooks de cycle de vie, les équipes ont besoin d’un système de contrôle autour du modèle : preuves, validations, discipline Git, rigueur des sources et goût.

TL;DR

Codex prend en charge la forme de flux de travail que les équipes d’agents construisaient jusqu’ici en privé : tâches longues, exécution distante, pilotage mobile, validations, hooks, identifiants à portée limitée et signaux d’audit.²⁴⁵ Le moteur de hooks en 0.150.0 enregistre douze événements, chaque hook non managé reste ignoré tant que vous n’avez pas approuvé son hash actuel, et les hooks se chargent depuis des fichiers hooks.json ou des tables [hooks] inline dans config.toml.³⁷ La question pratique n’est pas « comment prompter Codex ? ». La question pratique est « que doit prouver Codex avant que nous fassions confiance au résultat ? » Les équipes devraient utiliser les hooks et la configuration pour encoder les points de contrôle de revue, les limites de sécurité, les standards de rédaction publique et la discipline de publication. Elles devraient garder leur mécanique privée confidentielle et ne publier que le motif, les critères d’acceptation et le résultat vérifié.

Points clés

Pour les équipes d’ingénierie : - Traitez les hooks Codex comme une infrastructure de processus, pas comme un ornement. Le flux de revue de confiance fait partie de cette infrastructure ; ce n’est pas une friction à contourner. - Commencez par les preuves, les validations, la discipline Git et les contrôles de publication avant d’ajouter de l’automatisation sophistiquée.

Pour les créateurs d’outils d’agents : - Construisez autour des vraies surfaces de Codex : pilotage mobile, hôtes Remote SSH, modes sandbox, politiques de validation, instructions de projet, hooks, télémétrie et gestion de versions. - Portez les tâches à accomplir, pas les anciennes formes de slash commands.

Pour les auteurs publics : - Appuyez-vous sur la documentation officielle sur learn.chatgpt.com pour le comportement actuel de Codex, et vérifiez la source du moteur quand la documentation est en retard d’une version. - Présentez la pratique privée comme une analyse d’auteur, et laissez hors du texte public les prompts privés, corps de hooks, chemins de fichiers, listes de sources, identifiants et règles internes de notation.

D’où viennent les hooks Codex ?

OpenAI a publié « Work with Codex from anywhere » (travailler avec Codex depuis n’importe où) le 14 mai 2026.¹ L’entrée du changelog de la documentation pour cette date consigne le lot de lancement : Codex est devenu utilisable depuis l’application mobile ChatGPT en la connectant à un Mac exécutant l’application Codex, les hooks ont atteint la disponibilité générale, et les jetons d’accès Codex sont arrivés pour l’automatisation de confiance.² Codex s’exécute depuis l’hôte connecté, si bien que les mêmes projets, fichiers, identifiants, plugins, skills et configurations sont disponibles depuis un téléphone.²

Les connexions distantes étendent la portée au-delà d’un seul bureau. La capacité Remote SSH de l’annonce se retrouve dans la documentation sous forme d’hôtes SSH : l’application de bureau ChatGPT peut ajouter des projets distants depuis un hôte SSH et exécuter des fils de discussion contre le système de fichiers et le shell distants. Le cadrage est concret : « Remote access uses the connected host’s projects, chats, files, credentials, permissions, plugins, Computer Use, browser setup, and local tools. » (l’accès distant utilise les projets, fils, fichiers, identifiants, permissions, plugins, Computer Use, configuration de navigateur et outils locaux de l’hôte connecté)⁴

Les hooks eux-mêmes précèdent le lancement en tant qu’expérimentation et l’ont dépassé ensuite. La documentation les définit comme un cadre d’extensibilité qui exécute des scripts ou des outils MCP pendant la boucle agentique, et nomme des tâches concrètes : envoyer les fils de discussion vers un moteur de journalisation, bloquer des clés API collées par accident, résumer les conversations en mémoires persistantes, lancer un contrôle de validation quand un tour s’arrête, et personnaliser le prompting par répertoire.³ Les hooks sont désormais activés par défaut ; features.hooks dans config.toml sert d’interrupteur d’arrêt, et features.codex_hooks ne survit que comme alias déprécié.³⁶

Ces détails comptent, car ils transforment le travail d’agent : on ne parle plus d’un échange de chat, mais d’opérations gouvernées.

À quoi ressemblent les hooks Codex en configuration ?

Un billet sur les hooks doit montrer un hook. Codex découvre les hooks à côté des couches de configuration actives, le plus utilement ~/.codex/hooks.json, <repo>/.codex/hooks.json, ou des tables inline dans le config.toml de l’une ou l’autre couche ; quand plusieurs sources existent, tous les hooks correspondants se chargent et s’exécutent.³ Un hooks.json minimal avec une barrière d’outil et une barrière d’achèvement :

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "^Bash$",
        "hooks": [
          {
            "type": "command",
            "command": "python3 ~/.codex/hooks/pre_tool_use_policy.py",
            "timeout": 30,
            "statusMessage": "Checking Bash command"
          }
        ]
      }
    ],
    "Stop": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "python3 ~/.codex/hooks/evidence_gate.py"
          }
        ]
      }
    ]
  }
}

La même forme écrite inline dans config.toml :

[[hooks.PreToolUse]]
matcher = "^Bash$"

[[hooks.PreToolUse.hooks]]
type = "command"
command = "python3 ~/.codex/hooks/pre_tool_use_policy.py"
timeout = 30
statusMessage = "Checking Bash command"

Trois niveaux organisent chaque hook : un événement, un groupe de correspondance (matcher) qui décide quand l’événement s’applique, et un ou plusieurs gestionnaires (command ou mcp_tool).³ Les événements actuels, avec la liste de douze entrées du moteur comme autorité :³⁷

La documentation des hooks en ligne documente encore onze de ces événements ; elle n’a pas encore de section Interrupt. L’entrée du changelog 0.150.0 (#40511) et HOOK_EVENT_NAMES: [&str; 12] dans la source du moteur à rust-v0.150.0 portent le douzième.²⁷ Quand une page et le moteur divergent, fiez-vous au moteur.

Quels appels d’outils les hooks peuvent-ils réellement voir ?

Des versions antérieures de la documentation avertissaient que PreToolUse couvrait peu de chose au-delà des appels shell et MCP. La documentation actuelle élargit la surface : « PreToolUse and PostToolUse can observe more than shell and MCP calls. Most local function tools use the same hook path, » (PreToolUse et PostToolUse peuvent observer davantage que les appels shell et MCP ; la plupart des outils-fonctions locaux empruntent le même chemin de hook), si bien qu’un matcher peut nommer directement des outils comme update_plan, et spawn_agent correspond aussi sous le nom Agent.³ Les commandes shell correspondent sous Bash, les modifications de fichiers apply_patch correspondent sous apply_patch, Edit ou Write, et les outils MCP correspondent à des noms comme mcp__filesystem__read_file.³

Les outils hébergés restent en dehors : WebSearch et ses pairs ne passent jamais par le chemin de hook des outils-fonctions locaux.³ La documentation conserve une mise en garde adoucie qui mérite d’être citée en entier : « Some specialized tool paths can opt out of the default hook path. Treat tool hooks as a useful guardrail, not a complete enforcement boundary. » (certains chemins d’outils spécialisés peuvent se soustraire au chemin de hook par défaut ; traitez les hooks d’outils comme un garde-fou utile, pas comme une frontière d’application complète)³ Le sandboxing détient toujours la frontière dure ; les hooks détiennent la revue et le pilotage à l’intérieur.

Comment Codex décide-t-il quels hooks peuvent s’exécuter ?

Les hooks sont du code qui pilote l’agent, donc Codex gouverne les hooks eux-mêmes. Le système de contrôle autour du modèle commence ici.

Avant qu’un hook non managé s’exécute, Codex exige que vous relisiez et approuviez sa définition exacte. La confiance est enregistrée contre le hash actuel du hook, si bien qu’un hook nouveau ou modifié est marqué pour revue et ignoré jusqu’à être approuvé de nouveau.³ La commande /hooks dans la CLI ouvre la surface de revue : inspecter les sources des hooks, relire les hooks nouveaux ou modifiés, les approuver, ou en désactiver individuellement. Quand des hooks nécessitent une revue au démarrage, Codex affiche un avertissement pointant vers /hooks.³

Les hooks managés issus des sources système, MDM, cloud ou requirements.toml se placent au-dessus de ce flux : ils sont approuvés par politique et ne peuvent pas être désactivés depuis le navigateur de hooks utilisateur.³ Les plugins se placent à l’intérieur : installer ou activer un plugin n’approuve pas ses hooks embarqués, qui restent ignorés jusqu’à revue comme n’importe quel autre.³ Les hooks locaux au projet ne se chargent que lorsque la couche .codex/ du projet est approuvée ; un projet non approuvé charge tout de même vos hooks utilisateur et système.³

L’automatisation suit la même règle. Une exécution codex exec n’a pas d’interface de revue, donc un hook non approuvé est ignoré silencieusement jusqu’à ce que vous l’approuviez d’abord dans une session interactive ; la documentation ne le dit pas encore, mais la surface de revue au démarrage du moteur n’existe que dans la TUI interactive.⁷ Pour les pipelines qui vérifient les sources de hooks ailleurs, --dangerously-bypass-hook-trust exécute les hooks activés sans confiance persistée, pour cette seule invocation.³ Approuvez délibérément ou regardez votre barrière ne pas se déclencher : le cadre décide quel code peut piloter l’agent avant que quoi que ce soit s’exécute.

Que se passe-t-il quand un hook bloque, et quand est-ce trop tard ?

Le moment d’exécution décide de ce qu’un hook peut encore changer. La plupart des hooks s’exécutent de manière synchrone avec un timeout par défaut de 600 secondes ; SessionEnd et Interrupt ont une seconde par défaut et sont plafonnés à trois : SessionEnd se déclenche pendant le démontage de la session, et Interrupt se déclenche pendant que l’utilisateur attend.³⁷

PreToolUse agit avant que quoi que ce soit se produise, donc il détient les cartes les plus fortes : refuser l’appel, ou le réécrire en retournant permissionDecision: "allow" avec updatedInput. La forme du refus :

{
  "hookSpecificOutput": {
    "hookEventName": "PreToolUse",
    "permissionDecision": "deny",
    "permissionDecisionReason": "Destructive command blocked by hook."
  }
}

Le code de sortie 2 avec la raison sur stderr bloque aussi.³

PostToolUse agit après l’exécution de l’outil, donc il ne peut pas annuler les effets de bord. Un decision: "block" remplace le résultat de l’outil par votre retour et fait continuer le modèle depuis ce message, ce qui corrige la trajectoire sans prétendre que la commande n’a jamais eu lieu.³ Stop transforme un refus en continuation : bloquez un achèvement et Codex continue de travailler, avec votre raison comme nouveau prompt.³

Pour les contrôles qui ne devraient jamais se trouver sur le chemin critique, définissez async = true sur un gestionnaire de commande. Les hooks en arrière-plan s’exécutent pendant que Codex continue, livrent leur sortie au prochain point sûr, et ne peuvent explicitement rien bloquer, approuver ni réécrire ; gardez synchrones les politiques d’outils, les décisions de permission, le rejet de prompt et la continuation de tour.³

Qu’est-ce qui a changé en 0.149 et 0.150 ?

Deux versions stables de fin août ont resserré l’histoire de gouvernance.

Codex CLI 0.149.0 (20 août 2026) a retiré la politique de validation untrusted (#39630) ; une configuration qui la nomme encore échoue désormais avec une erreur actionnable vous demandant de retirer le réglage.²⁷ Codex CLI 0.150.0 (26 août 2026) a ajouté l’événement de hook Interrupt (#40511) : « New Interrupt hooks can run commands or MCP handlers when an active top-level turn is interrupted. » (les nouveaux hooks Interrupt peuvent exécuter des commandes ou des gestionnaires MCP quand un tour actif de premier niveau est interrompu). Les hooks Interrupt ne s’exécutent jamais pour les sous-agents.²⁷ La même version a empêché les projets non approuvés de fournir des instructions AGENTS.md au niveau projet (#39837), ce qui rejoint la règle existante selon laquelle les hooks locaux au projet ne se chargent que depuis une couche .codex/ approuvée.²³

La direction est cohérente : un répertoire non approuvé obtient de moins en moins d’autorité sur l’agent qui y entre. Instructions, hooks et raccourcis de validation passent tous désormais par des décisions de confiance explicites.

Pourquoi les hooks comptent-ils plus que le mobile ?

L’accès mobile change l’endroit où l’humain peut intervenir. Les hooks changent ce que le système peut imposer.

Un téléphone permet à un opérateur de répondre à une question loin de son bureau. Un hook peut rattraper l’agent avant une action risquée, après une modification de fichier, avant l’achèvement ou pendant un contrôle de publication. Le téléphone résout la latence. Le hook résout les standards.

Codex dispose déjà de surfaces de contrôle natives autour du sandboxing et des validations. La documentation de sécurité associe le mode sandbox, qui définit ce que l’agent peut techniquement faire, et la politique de validation, qui définit quand Codex doit s’arrêter et demander avant d’agir.⁵ L’agent s’exécute avec l’accès réseau désactivé par défaut, et le mode local workspace-write par défaut garde l’accès réseau coupé sauf activation par l’utilisateur.⁵ Les hooks se placent à côté de ces contrôles comme couche de revue et de pilotage, pas comme remplacement du sandboxing.

Les hooks peuvent rendre exécutables les standards locaux :

Le modèle peut oublier une règle. Un hook peut relancer la règle au moment où la règle compte.

Que possède le cadre que le fournisseur ne possède pas ?

Un cadre d’agent est la couche d’exploitation autour d’un modèle : permissions, mémoire, outils, hooks, contrôles de sources, barrières de publication, dossiers de revue et discipline de retour arrière. Le terme peut sembler privé ou précieux, mais la fonction est simple. Cette couche transforme l’intention en travail responsable.

Codex expose désormais assez de surface officielle pour rendre cette couche explicite. Les connexions distantes transportent l’environnement de l’hôte. Les modes sandbox et les politiques de validation définissent les limites d’action. Les fichiers de configuration définissent les modèles, projets, permissions, serveurs MCP, skills, hooks, la télémétrie et les fonctionnalités.⁶ L’export OpenTelemetry reste opt-in et désactivé par défaut ; une fois activé, Codex émet des événements structurés couvrant les conversations, les requêtes API, l’activité de flux, les prompts utilisateur (caviardés par défaut), les décisions de validation d’outils et les résultats d’outils.⁵⁸

Cet ensemble de surfaces crée une séparation utile :

Le fournisseur doit continuer à améliorer l’environnement d’exécution. Le jugement reste à la charge de l’équipe.

Que doivent encoder les équipes en premier ?

Commencez par quatre barrières. Elles se rentabilisent immédiatement.

Barrière de preuves

Le billet de lancement originel de Codex insistait sur des preuves vérifiables : journaux de terminal, sorties de tests et étapes traçables pendant l’accomplissement des tâches.⁹ Rendez cette attente non négociable. Un achèvement digne de ce nom doit nommer les fichiers modifiés, les commandes exécutées, le comportement observé, les contrôles en échec et les manques restants.

Pour le travail public, les preuves incluent les liens de sources et l’alignement entre affirmations et sources. Pour les publications web, les preuves incluent les routes rendues, les métadonnées, le schéma, les fichiers de découverte, l’état de déploiement, la fraîcheur du cache et les marqueurs de changement en ligne. Pour les traductions, les preuves incluent la couverture des locales, les barrières de qualité, les lignes de stockage ou fichiers de cache, et le statut de revue native quand il est requis.

Barrière de validation

N’utilisez pas une seule posture de validation pour toutes les actions. Le tableau de combinaisons actuel de la documentation des validations va du préréglage Auto (sandbox workspace-write avec validations on-request) jusqu’à la navigation sûre en lecture seule, la CI non interactive en lecture seule, le mode auto-review et l’accès complet dangereux.⁵ Une ligne est en retard sur la réalité : la politique untrusted figure encore sur la page, mais 0.149.0 l’a retirée et les configurations explicites échouent désormais.²⁵ Pour une posture « toujours demander » aujourd’hui, combinez le sandbox read-only avec les validations on-request. Une politique locale solide garde la même forme : les lectures à faible risque passent sans bruit, le travail à effets de bord obtient une revue, et le travail destructif ou visible de l’extérieur obtient des preuves explicites.

Barrière de discipline Git

Le travail d’agent a besoin de poignées de retour arrière. La propre documentation de sécurité de Codex dit que Codex fonctionne mieux avec la gestion de versions : gardez le statut propre avant de déléguer, committez fréquemment, lancez des vérifications ciblées, relisez les diffs et documentez les décisions dans les messages de commit.⁵

Ce conseil doit devenir un processus. Committez après des points de sauvegarde cohérents et vérifiés. Indexez des chemins exacts. Découpez les commits par préoccupation indépendamment réversible. Demandez avant de pousser, sauf si le flux de publication accorde déjà l’autorité de publier. Ne balayez pas dans un commit des fichiers sales sans rapport parce que l’agent les a vus au passage.

Barrière de goût

Le code assisté par IA rend l’implémentation moins chère. Une implémentation moins chère augmente la valeur du goût.

Le goût ne désigne pas une préférence décorative. Il signifie que le travail améliore le produit entier. Il signifie que l’agent peut refuser un chemin techniquement possible qui affaiblit le résultat. Il signifie qu’un texte public évite la mécanique privée, les affirmations non étayées et le remplissage. Il signifie qu’un correctif local correct peut quand même échouer si le parcours visible par l’utilisateur reste cassé.

Une barrière de goût devrait demander :

Que prouve le travail de Mozilla sur Firefox ?

Le billet de Mozilla du 7 mai sur le durcissement de Firefox avec Claude Mythos Preview fait le même constat depuis une autre pile. L’équipe dit que les premières tentatives d’audit de code par LLM étaient prometteuses mais produisaient trop de faux positifs pour passer à l’échelle. Les cadres agentiques ont changé l’équation économique parce qu’ils pouvaient créer et exécuter des cas de test reproductibles pour éprouver dynamiquement les hypothèses de bugs.¹⁰

La phrase importante de Mozilla ne porte pas sur le modèle seul. L’équipe dit que la découverte était nécessaire mais pas suffisante. Le système utile devait s’intégrer au cycle de vie complet des bugs de sécurité : cibles, déduplication, suivi de bugs, triage, correctifs et publication.¹⁰ Les auteurs disent aussi que le pipeline reflétait la sémantique du code de Firefox, son outillage et ses processus.¹⁰

C’est la leçon pour Codex. De meilleurs modèles comptent. Le système opérationnel autour du modèle décide si le travail devient une sortie digne de confiance.

Que doit rester hors du texte public ?

Un article public sur Codex ne doit pas déverser le système de travail privé.

Gardez hors du texte public :

• les prompts privés et les corps de hooks ;
• les chemins locaux sensibles ;
• les cartes de sources exactes et les règles internes de notation ;
• les identifiants de comptes et la gestion des identifiants ;
• les raccourcis de flux de travail privés ;
• le comportement de plugins non publiés ;
• tout ce qui aide un inconnu à reconstruire des opérations internes.

Publiez plutôt le motif : ce que la barrière protège, quelles preuves elle exige, quel échec elle rattrape, et comment une équipe peut implémenter l’idée avec les surfaces officielles de Codex.

Cette ligne protège la confiance. Elle améliore aussi l’écriture. La mécanique privée se lit généralement comme du folklore. Des critères d’acceptation publics aident d’autres équipes à raisonner sur leurs propres systèmes.

À quoi ressemble une carte minimale de cadre Codex ?

Construisez la plus petite carte de contrôle qui prouve un travail utile.

Commencez explicite. Lancez une vraie tâche. Notez où la barrière a aidé et où elle a gêné. Ne promouvez que les parties qui améliorent le résultat visible par l’utilisateur.

Résumé rapide

Les hooks Codex, Remote SSH, le pilotage mobile, le sandboxing, les validations, la configuration, la télémétrie et la gestion de versions pointent dans la même direction : les agents de code ont besoin de systèmes d’exploitation autour d’eux.²⁴⁵⁶ L’agent peut écrire du code. Le cadre décide de ce qui compte comme travail.

Les meilleures équipes ne gagneront pas en produisant le plus grand volume de sortie d’agent. Elles gagneront en rendant le travail d’agent inspectable, réversible, sourcé, de bon goût et digne d’être publié.

FAQ

Que sont les hooks Codex ?

Les hooks Codex exécutent des scripts ou des outils MCP pendant la boucle agentique, chargés depuis des fichiers hooks.json ou des tables [hooks] inline dans config.toml. La documentation nomme les tâches sans détour : envoyer les fils de discussion vers un moteur de journalisation, bloquer des clés API collées par accident, résumer les conversations en mémoires persistantes, lancer une validation quand un tour s’arrête, et personnaliser le prompting par répertoire.³ Le moteur en 0.150.0 enregistre douze événements, de PreToolUse, PermissionRequest et PostToolUse jusqu’à Stop et le nouveau Interrupt ; la page de documentation en liste encore onze, le temps de rattraper.³⁷

Pourquoi les hooks Codex comptent-ils ?

Les hooks permettent aux équipes de placer des standards aux points de décision au lieu de s’en remettre aux seuls prompts. Un hook peut vérifier les preuves, la qualité des sources, l’état Git ou la préparation à la publication quand l’agent agit ou tente de terminer.

Pourquoi mon hook ne s’est-il pas exécuté ?

La réponse habituelle est la confiance. Codex ignore tout hook non managé dont vous n’avez pas relu le hash actuel, affiche un avertissement au démarrage dans les sessions interactives, et ignore silencieusement dans l’automatisation codex exec.⁷ Ouvrez /hooks pour le relire et l’approuver, ou passez --dangerously-bypass-hook-trust uniquement dans des pipelines qui vérifient les sources de hooks ailleurs.³

Codex mobile remplace-t-il le flux de travail d’agent local ?

Non. Le pilotage mobile permet d’orienter le travail loin du bureau, mais l’hôte connecté fournit toujours les projets, fils, fichiers, identifiants, permissions, plugins et outils locaux.⁴ Les équipes ont toujours besoin d’une politique locale, d’identifiants sûrs, de gestion de versions et de vérification.

Que doit inclure un cadre Codex en premier ?

Commencez par des instructions de projet, une posture de sandbox et de validation, une frontière pour les secrets, une barrière d’arrêt sur preuves, une discipline Git à chemins exacts, la vérification des sources pour les affirmations publiques et une barrière de publication pour le travail visible par l’utilisateur.

Les équipes doivent-elles publier leurs hooks Codex ?

Publiez des motifs et des critères d’acceptation, pas des corps de hooks privés ni des détails sensibles de flux de travail. Un billet public utile peut expliquer le rôle d’un hook sans exposer chemins privés, cartes de sources, prompts, identifiants ou règles de notation.

Références