Codex prend désormais en charge les subagents

• OpenAI Codex prend en charge les workflows de subagents, avec la possibilité de répartir en parallèle des tâches complexes entre plusieurs agents spécialisés puis de fusionner les résultats
• Les subagents ne sont créés que lorsque l’utilisateur le demande explicitement, et comme chaque agent utilise indépendamment ses propres modèles et outils, la consommation de tokens augmente par rapport à un agent unique
• Il est possible de définir des agents personnalisés via des fichiers TOML afin de configurer indépendamment, pour chaque agent, le modèle, le mode sandbox, les serveurs MCP, etc.
• La fonctionnalité expérimentale spawn_agents_on_csv est également incluse, pour créer en lot des agents worker en utilisant chaque ligne d’un fichier CSV comme unité de travail
• La documentation officielle présente directement des modèles de combinaison d’agents personnalisés selon des cas d’usage concrets comme la revue de code ou le débogage frontend

---

Vue d’ensemble des subagents et disponibilité

• Codex prend en charge les workflows de subagents qui créent (spawn) en parallèle des agents spécialisés et rassemblent leurs résultats dans une seule réponse
• Cela est particulièrement utile pour les tâches complexes nécessitant un haut degré de parallélisme, comme l’exploration d’une codebase ou la planification d’une implémentation fonctionnelle en plusieurs étapes
• Dans un workflow de subagents, il est aussi possible de définir des agents personnalisés avec des paramètres de modèle et des instructions différents selon la tâche
• Dans la version actuelle de Codex, le workflow de subagents est activé par défaut
• L’activité des subagents est actuellement visible dans l’application Codex et la CLI, et sa visibilité dans l’extension IDE sera ajoutée prochainement
• Les subagents ne sont créés que lorsque l’utilisateur le demande explicitement, et comme chaque subagent exécute ses propres opérations de modèle et d’outils, la consommation de tokens est plus élevée qu’avec une exécution à agent unique

Workflow général

• Codex gère l’orchestration entre agents : création de nouveaux subagents, routage des instructions de suivi, attente des résultats et fermeture des threads d’agent
• Lorsque plusieurs agents sont en cours d’exécution, Codex attend que tous les résultats soient prêts avant de renvoyer une réponse unifiée
• Exemple de prompt : demander qu’un agent soit créé pour chacun des aspects suivants d’une PR en cours — problèmes de sécurité, qualité du code, bugs, race conditions, instabilité des tests, maintenabilité — puis qu’un résumé global soit produit

Gestion des subagents

• Dans la CLI, la commande /agent permet de basculer entre les threads d’agents actifs et d’inspecter les threads en cours
• Il est possible de demander directement à Codex de piloter, arrêter ou fermer des threads terminés de subagents en cours d’exécution

Contrôle des approbations et de la sandbox

• Les subagents héritent de la politique sandbox actuelle de l’utilisateur
• Dans les sessions CLI interactives, les demandes d’approbation provenant de threads d’agents inactifs peuvent s’afficher même pendant l’utilisation du thread principal, et la surcouche d’approbation indique le libellé du thread source
  • Appuyer sur o permet d’ouvrir ce thread, puis d’approuver, de refuser ou de répondre
• Dans les flux non interactifs, il n’est pas possible d’afficher de nouvelles approbations ; les opérations qui en nécessitent échouent alors et l’erreur est propagée au workflow parent
• Lors de la création d’un agent enfant, les surcharges runtime actives du tour parent sont réappliquées, y compris les changements /approvals ou les paramètres interactifs comme --yolo
  • Même si le fichier d’agent personnalisé sélectionné définit d’autres valeurs par défaut, les paramètres du parent restent prioritaires
• Il est possible de surcharger séparément les paramètres sandbox pour chaque agent personnalisé (par exemple, définir un agent spécifique en lecture seule)

Agents personnalisés

• Codex fournit trois agents intégrés par défaut
  • default : agent de secours à usage général
  • worker : agent orienté exécution centré sur l’implémentation et les corrections
  • explorer : agent orienté lecture pour l’exploration de la codebase
• Pour définir un agent personnalisé, ajoutez un fichier TOML distinct dans ~/.codex/agents/ (usage personnel) ou .codex/agents/ (portée projet)
• Chaque fichier définit un agent personnalisé, que Codex charge comme couche de configuration pour la session de création
• Champs obligatoires à inclure dans tous les fichiers d’agents personnalisés :
  • name, description, developer_instructions
• Champs optionnels : nickname_candidates, model, model_reasoning_effort, sandbox_mode, mcp_servers, skills.config, etc. ; s’ils sont omis, ils sont hérités de la session parente

Configuration globale

• La configuration globale des subagents se définit dans la section [agents] du fichier de configuration
• agents.max_threads : limite supérieure du nombre de threads d’agents ouverts simultanément (valeur par défaut : 6)
• agents.max_depth : profondeur d’imbrication des agents créés (valeur par défaut : 1, ce qui n’autorise que des agents enfants directs et empêche une imbrication plus profonde)
• agents.job_max_runtime_seconds : timeout par défaut par worker pour les tâches spawn_agents_on_csv (1800 secondes par appel si non défini)
• Si un nom d’agent personnalisé est identique à celui d’un agent intégré comme explorer, l’agent personnalisé est prioritaire

Schéma des fichiers d’agents personnalisés

• name (string, requis) : nom de l’agent utilisé par Codex pour créer ou référencer l’agent
• description (string, requis) : guide à destination des humains indiquant quand Codex doit utiliser cet agent
• developer_instructions (string, requis) : instructions centrales qui définissent le comportement de l’agent
• nickname_candidates (string[], optionnel) : réservoir de pseudonymes d’affichage pour les agents créés
• D’autres clés config.toml prises en charge peuvent aussi être incluses : model, model_reasoning_effort, sandbox_mode, mcp_servers, skills.config, etc.
• Codex identifie les agents via le champ name ; faire correspondre le nom du fichier et celui de l’agent reste la convention la plus simple, mais le champ name fait foi

Pseudonymes d’affichage

• nickname_candidates sert à afficher dans l’interface des libellés distinctifs lorsqu’un même agent personnalisé est exécuté en plusieurs instances
• Les pseudonymes sont uniquement destinés à l’affichage ; Codex continue d’identifier et de créer les agents à partir de name
• Les candidats doivent constituer une liste non vide de noms uniques, pouvant contenir des caractères ASCII, des chiffres, des espaces, des tirets et des underscores
• Exemple : si l’agent reviewer reçoit les pseudonymes ["Atlas", "Delta", "Echo"], ces pseudonymes s’affichent dans l’application et la CLI, tandis que le type d’agent de base reste reviewer

Exemple 1 : modèle de revue de PR

• Un modèle qui répartit la revue entre trois agents personnalisés spécialisés
  • pr_explorer : agent en lecture seule qui cartographie la codebase et collecte des preuves (modèle : gpt-5.3-codex-spark, reasoning effort : medium)
  • reviewer : relecteur de PR chargé de repérer les problèmes de correction, de sécurité et les risques liés aux tests (modèle : gpt-5.4, reasoning effort : high)
  • docs_researcher : spécialiste de la documentation qui vérifie la documentation des frameworks ou API via un serveur MCP dédié (modèle : gpt-5.3-codex-spark, lecture seule)
• Configuration du projet : max_threads = 6, max_depth = 1
• Instructions de pr_explorer : rester en mode exploration, suivre les chemins d’exécution réels, citer les fichiers et symboles, et éviter de proposer des modifications sauf si l’agent parent le demande
• Instructions de reviewer : relire du point de vue du propriétaire, prioriser la correction, la sécurité, les régressions de comportement et les manques de couverture de tests, inclure si possible des étapes de reproduction, et éviter les commentaires purement stylistiques sauf s’ils masquent un vrai bug
• Instructions de docs_researcher : utiliser le serveur MCP de documentation pour vérifier les API, options et comportements selon les versions, puis répondre de façon concise avec des liens ou des références précises, sans modifier le code
• Exemple de prompt : "Passe cette branche en revue par rapport à main. Que pr_explorer cartographie les chemins de code impactés, que reviewer identifie les risques concrets, et que docs_researcher vérifie les API du framework dont dépend le patch"

Traitement par lots CSV : spawn_agents_on_csv (expérimental)

• Fonctionnalité expérimentale susceptible d’évoluer à l’avenir
• Lorsqu’il existe de nombreuses tâches similaires, des subagents worker peuvent être créés en lot en prenant une ligne de CSV comme unité de travail
• Codex lit le CSV, crée un agent worker par ligne, attend la fin du lot complet, puis exporte les résultats au format CSV
• Cas d’usage adaptés :
  • Relire un fichier, package ou service par ligne
  • Examiner une liste d’incidents, de PR ou de cibles de migration
  • Générer des résumés structurés pour un grand nombre d’entrées similaires
• Paramètres d’entrée de l’outil : csv_path (CSV source), instruction (modèle de prompt worker utilisant des placeholders {column_name}), id_column (ID d’élément stable), output_schema (forme JSON fixe), output_csv_path, max_concurrency, max_runtime_seconds
• Chaque worker doit appeler report_agent_job_result exactement une fois ; s’il se termine sans signaler de résultat, la ligne correspondante est marquée comme erreur
• Lors d’une exécution via codex exec, une mise à jour de progression sur une seule ligne s’affiche dans stderr pendant le traitement du lot
• Le CSV exporté contient les données de ligne d’origine ainsi que des métadonnées comme job_id, item_id, status, last_error, result_json, etc.
• Paramètres runtime associés : agents.max_threads (limite des threads simultanés), agents.job_max_runtime_seconds (timeout par worker, la valeur max_runtime_seconds fournie à l’appel étant prioritaire), sqlite_home (chemin de persistance d’état SQLite utilisé pour les tâches d’agent et les résultats exportés)

Exemple 2 : modèle de débogage intégré frontend

• Un modèle utile pour les régressions UI, les parcours navigateur instables et les bugs d’intégration qui traversent le code applicatif et le produit en cours d’exécution
• Combinaison de trois agents personnalisés :
  • code_mapper : agent d’exploration en lecture seule qui trouve les chemins de code frontend et backend pertinents (modèle : gpt-5.3-codex-spark, reasoning effort : medium)
  • browser_debugger : débogueur UI qui utilise des outils navigateur pour reproduire le problème et capturer des preuves (modèle : gpt-5.4, reasoning effort : high, sandbox : workspace-write)
    • Utilise les outils navigateur pour les captures d’écran, sorties console et preuves réseau, sans modifier le code de l’application
    • Connexion au serveur MCP de Chrome DevTools (http://localhost:3000/mcp, startup_timeout_sec: 20)
  • ui_fixer : agent orienté implémentation chargé d’appliquer de petites corrections ciblées une fois le problème compris (modèle : gpt-5.3-codex-spark, reasoning effort : medium)
    • Effectue le plus petit changement défendable, ne touche pas aux fichiers non liés et ne valide que le comportement modifié
• Exemple de prompt : "Cherche pourquoi la modale de configuration échoue à l’enregistrement. Que browser_debugger reproduise le problème, que code_mapper remonte le chemin de code concerné, et que ui_fixer implémente la correction minimale une fois le mode d’échec identifié"