Les hooks Codex donnent corps au cadre d’agent

OpenAI a intégré Codex à l’application mobile ChatGPT le 14 mai 2026. La vraie rupture se trouvait plus bas dans l’annonce : Remote SSH et les hooks sont passés en disponibilité générale, tandis que les jetons d’accès programmatiques arrivaient pour les offres Business et Enterprise.¹

Cela change la nature du travail. Codex ne ressemble plus à un assistant de code enfermé dans un terminal. Il devient une couche d’exploitation qui accompagne le travail entre machines, validations, 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 désormais en charge la forme de flux de travail que les équipes d’agents construisaient déjà en privé : tâches longues, exécution distante, pilotage mobile, validations, hooks, identifiants à portée limitée et signaux d’audit.¹²³ Le prompt compte toujours, mais la couche d’exploitation compte davantage.

La question pratique n’est pas « comment prompter Codex ? ». La vraie question 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 modèle, 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. - 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, 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 OpenAI pour décrire le comportement actuel de Codex. - Présentez les pratiques privées 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.

Qu’est-ce qui a changé le 14 mai ?

L’annonce d’OpenAI du 14 mai a rapproché Codex d’une surface de travail persistante. Codex dans l’application mobile ChatGPT peut se connecter aux machines où Codex s’exécute, charger l’état en direct de cet environnement et permettre à l’utilisateur de relire les sorties, approuver des commandes, changer de modèle, lancer du travail et suivre depuis un téléphone les diffs, la sortie du terminal, les résultats de tests, les validations et les captures d’écran.¹

La même annonce indique que Remote SSH est passé en disponibilité générale. Codex peut se connecter à des environnements distants, détecter les hôtes à partir de la configuration SSH, créer des projets et exécuter des fils de travail sur des machines distantes.¹ La documentation développeur décrit plus concrètement les connexions distantes : 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é.²

OpenAI a aussi fait passer les hooks en disponibilité générale. L’annonce cite des usages précis : analyser les prompts pour détecter des secrets, exécuter des validateurs, journaliser les conversations, créer des mémoires et personnaliser le comportement de Codex pour des dépôts et des dossiers.¹ La documentation des hooks les définit comme un cadre d’extension permettant d’injecter des scripts dans la boucle Codex, tandis que la référence de configuration expose features.hooks pour les hooks de cycle de vie chargés depuis hooks.json ou depuis une configuration inline.⁷⁶

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.

Pourquoi les hooks comptent 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 arrêter l’agent avant une action risquée, après une modification de fichier, avant la fin d’une tâche ou pendant un contrôle de publication. Le téléphone réduit la latence. Le hook impose les standards.

Codex dispose déjà de surfaces de contrôle natives pour le sandboxing et les validations. La documentation de sécurité d’OpenAI explique que Codex combine 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.³ La même documentation indique que l’accès réseau est désactivé par défaut, et que le mode local workspace-write par défaut garde cet accès désactivé sauf activation par l’utilisateur.³

Les hooks se placent à côté de ces contrôles. Les événements de hooks actuels incluent SessionStart, PreToolUse, PermissionRequest, PostToolUse, UserPromptSubmit et Stop ; PreToolUse peut intercepter certains appels Bash pris en charge, les modifications de fichiers via apply_patch et les appels d’outils MCP, mais la documentation OpenAI précise qu’il n’intercepte pas tous les chemins shell, WebSearch ni les autres appels d’outils non shell et non MCP.⁷ Les hooks forment donc une couche de revue et de pilotage, pas un remplacement du sandboxing.

Les hooks peuvent rendre exécutables les standards locaux :

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

Le cadre d’agent est la couche d’exploitation

Un cadre d’agent est la couche d’exploitation autour d’un modèle : permissions, mémoire, outils, hooks, contrôles de sources, seuils 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 une intention en travail responsable.

Codex expose désormais assez de surfaces officielles 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.⁶ OpenTelemetry peut enregistrer des événements tels que les prompts utilisateur, décisions de validation, résultats d’exécution d’outils, usages MCP et décisions du proxy réseau.³⁴

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 points de contrôle. Ils sont immédiatement utiles.

Seuil de preuve

Le billet de lancement initial de Codex insistait sur les preuves vérifiables : journaux de terminal, sorties de tests et étapes traçables pendant l’achèvement d’une tâche.⁵ Rendez cette attente non négociable. Une finalisation sérieuse doit nommer les fichiers modifiés, les commandes exécutées, le comportement observé, les contrôles échoués et les écarts restants.

Pour le travail public, les preuves incluent les liens de sources et l’alignement entre affirmation et source. Pour les publications web, elles incluent les routes rendues, les métadonnées, le schéma, les fichiers de découverte, l’état du déploiement, la fraîcheur du cache et les marqueurs visibles des changements. Pour les traductions, elles incluent la couverture locale, les seuils de qualité, les lignes de stockage ou fichiers de cache, et l’état de revue native quand elle est requise.

Seuil de validation

N’utilisez pas la même posture de validation pour toutes les actions. La documentation d’OpenAI sur les validations distingue la navigation sûre en lecture seule, l’édition dans l’espace de travail, l’accès réseau soumis à validation, les commandes non fiables, le mode auto-review et l’accès complet dangereux.³ Une bonne politique locale devrait conserver cette forme : les lectures à faible risque passent discrètement, les travaux à effets de bord sont relus, et les actions destructrices ou visibles de l’extérieur exigent des preuves explicites.

Seuil de discipline Git

Le travail d’agent a besoin de poignées de retour arrière. La documentation de sécurité de Codex indique que Codex fonctionne mieux avec la gestion de versions : garder un statut propre avant de déléguer, commiter fréquemment, exécuter des vérifications ciblées, relire les diffs et documenter les décisions dans les messages de commit.³

Ce conseil doit devenir un processus. Faites un commit après chaque point de sauvegarde cohérent et vérifié. Stagez uniquement les chemins exacts. Séparez les commits par préoccupations indépendamment réversibles. Demandez avant de pousser, sauf si le flux de publication accorde déjà l’autorité de publier. N’embarquez pas des fichiers sales sans rapport dans un commit simplement parce que l’agent les a vus.

Seuil de goût

Le code produit par IA rend l’implémentation moins coûteuse. Quand l’implémentation devient moins chère, le goût prend plus de valeur.

Le goût n’est pas une préférence décorative. Il signifie que le travail améliore l’ensemble du produit. Il signifie que l’agent peut refuser une voie techniquement possible si elle 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 patch local correct peut encore échouer si le parcours visible par l’utilisateur reste cassé.

Un seuil de goût devrait poser ces questions :

Mozilla montre le même modèle

Le billet de Mozilla du 7 mai sur le durcissement de Firefox avec Claude Mythos Preview formule le même point depuis une autre stack. L’équipe explique que les premières tentatives d’audit de code avec LLM étaient prometteuses, mais généraient trop de faux positifs pour passer à l’échelle. Les cadres agentiques ont changé l’économie du problème, parce qu’ils pouvaient créer et exécuter des cas de test reproductibles afin de vérifier dynamiquement des hypothèses de bugs.⁸

La phrase importante de Mozilla ne porte pas seulement sur le modèle. L’équipe explique que la découverte était nécessaire, mais insuffisante. Le système utile devait s’intégrer à tout le cycle de vie des bugs de sécurité : cibles, déduplication, suivi des bugs, triage, correctifs et publication.⁸ Les auteurs ajoutent que le pipeline reflétait la sémantique, l’outillage et les processus de la base de code Firefox.⁸

Voilà la leçon pour Codex. De meilleurs modèles comptent. Mais c’est le système opérationnel autour du modèle qui détermine si le travail devient un résultat digne de confiance.

Ce qu’il ne faut pas publier

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 cartographies exactes des sources et les règles internes de notation ;
• les identifiants de comptes et la gestion des credentials ;
• les raccourcis de flux de travail privés ;
• le comportement de plugins non publiés ;
• tout ce qui aiderait un inconnu à reconstruire les opérations internes.

Publiez plutôt le modèle : ce que le point de contrôle protège, quelles preuves il exige, quelle défaillance il attrape et comment une équipe peut mettre l’idée en œuvre avec les surfaces officielles de Codex.

Cette limite protège la confiance. Elle améliore aussi le texte. La mécanique privée ressemble souvent à du folklore. Des critères d’acceptation publics aident les autres équipes à raisonner sur leurs propres systèmes.

Une carte pratique du cadre Codex

Construisez la plus petite carte de contrôle capable de prouver un travail utile.

Commencez explicitement. Exécutez une vraie tâche. Notez où le point de contrôle a aidé et où il a gêné. Ne promouvez que les parties qui améliorent le résultat visible par l’utilisateur.

Résumé rapide

Hooks Codex, Remote SSH, pilotage mobile, sandboxing, validations, configuration, télémétrie et gestion de versions vont tous 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 ce qui compte comme travail.

Les meilleures équipes ne gagneront pas en produisant le plus grand volume de sorties 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 sont des capacités de hooks de cycle de vie qui peuvent s’exécuter depuis hooks.json ou depuis une configuration inline. L’annonce d’OpenAI indique que les hooks peuvent analyser les prompts pour détecter des secrets, exécuter des validateurs, journaliser les conversations, créer des mémoires et personnaliser le comportement de Codex pour des dépôts et dossiers précis ; la documentation des hooks liste des événements comme PreToolUse, PermissionRequest, PostToolUse, UserPromptSubmit et Stop.¹⁷

Pourquoi les hooks Codex sont-ils importants ?

Les hooks permettent aux équipes de placer leurs standards aux points de décision au lieu de s’appuyer seulement sur des 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 finaliser.

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

Non. Le pilotage mobile permet aux utilisateurs d’orienter le travail loin du bureau, mais l’hôte connecté fournit toujours les projets, fichiers, identifiants, permissions, plugins et outils locaux.² Les équipes ont encore besoin de politiques locales, 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 limite contre les secrets, un seuil d’arrêt sur les preuves, une discipline Git à chemins exacts, une vérification des sources pour les affirmations publiques et un seuil de publication pour le travail visible par l’utilisateur.

Les équipes devraient-elles publier leurs hooks Codex ?

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

Références