En bref

  • Problème : les Dynamic Workflows de Claude Code donnent une forme très pratique pour lancer plusieurs sous-agents, garder le bruit hors de la conversation principale et synthétiser le résultat.
  • Ce que j’ai testé : un prototype local pour Codex, avec un runtime Node, des workers factices, de vrais workers codex exec en lecture seule, une interface MCP, une skill et un manifeste plugin.
  • Résultat : le lab passe ses tests offline, s’installe via une marketplace Codex, lance des workers authentifiés en lecture seule, a terminé une campagne comparative sur BannerGenerator, puis a montré ses limites sur Hermes.
  • À retenir : l’intérêt principal n’est pas que les agents deviennent magiquement meilleurs. C’est que le workflow garde les prompts, commandes, logs, statuts, identités et synthèses dans un même arbre d’artefacts.
  • Repo : le lab est publié comme artefact expérimental. Je le mets en pause après la version 0.1.12, parce que les campagnes multi-agents consomment trop de tokens pour continuer à itérer à l’aveugle.

Pourquoi je voulais essayer

Le repo Michaelliv/pi-dynamic-workflows m’a donné une piste simple : au lieu de demander à un agent de tout faire dans une seule conversation, on lui fait écrire un petit script de workflow. Le script marque des phases, lance des agents, récupère leurs retours, puis renvoie une synthèse.

Claude Code a maintenant une version native de cette idée avec ses Dynamic Workflows. Ce qui m’intéressait, ce n’était pas de copier le produit. C’était de comprendre si Codex pouvait retrouver presque le même usage avec les surfaces qu’il expose déjà : codex exec, MCP, les skills et les plugins.

La première réponse était trop optimiste. Oui, on peut orchestrer plusieurs runs Codex. Mais non, dans les surfaces que j’ai pu utiliser ici, je n’ai pas trouvé d’équivalent simple à un registerTool() embarqué. Il faut donc traiter Codex comme un worker externe, pas comme une bibliothèque embarquée.

Ce que j’ai construit

J’ai créé un repo lab séparé du site. Il contient un package TypeScript qui s’appelle pour l’instant codex-dynamic-workflows-lab.

Le prototype a quatre couches :

  • un runtime JavaScript qui lit export const meta, exécute le script dans un vm Node et expose agent, parallel, pipeline, phase, log, args, cwd et budget ;
  • un runner codex exec qui passe les prompts par stdin, force le sandbox, capture stdout, stderr, les événements JSONL et les artefacts ;
  • un serveur MCP stdio qui expose workflow_validate, workflow_submit, workflow_status, workflow_result, workflow_cancel et workflow_artifacts ;
  • une skill dynamic-workflow et un manifeste .codex-plugin/plugin.json pour préparer le packaging Codex.

Le workflow de référence est volontairement modeste : une revue de repo en lecture seule. Trois workers partent en parallèle, un pour l’architecture, un pour les tests, un pour la sécurité. Ensuite le workflow synthétise les résultats.

Ce choix n’est pas très spectaculaire, mais il évite le piège habituel : commencer par un workflow qui écrit partout avant d’avoir prouvé l’isolation.

Le test qui compte maintenant

Le premier test important utilisait un faux binaire codex, injecté explicitement, pour vérifier la mécanique sans coût, sans authentification réelle et sans réseau.

Le run local du 2 juin 2026 a validé ces points :

  • npm run check passe avec compilation TypeScript, vérification syntaxique CLI/MCP et tests offline ;
  • le parser accepte une metadata littérale et rejette des formes dangereuses comme Date.now(), Math.random(), require, import(), eval, Function, Buffer et des accès via constructor ;
  • le parser JSONL tolère les lignes de bruit ;
  • la politique refuse le réseau, les connecteurs et danger-full-access ;
  • un worker ne peut pas élargir une policy lecture seule vers workspace-write ;
  • les identifiants d’artefacts refusent les traversées de chemin ;
  • une lecture via symlink d’artefact vers l’extérieur est rejetée ;
  • le CLI valide et exécute le workflow de référence avec trois workers factices ;
  • le serveur MCP répond à initialize et tools/list avec les outils attendus ;
  • npm pack --dry-run inclut bien le code compilé, le README, RESULTATS.md, la skill, le manifeste plugin et l’exemple de workflow.

Ensuite, le lab a avancé. La version 0.1.4 a corrigé la propagation d’authentification locale en copiant uniquement auth.json dans un CODEX_HOME temporaire de worker. La version 0.1.5 a transformé workflow_submit en soumission détachée avec polling, pour éviter qu’un long workflow multi-agents doive finir dans un seul appel outil de Codex app.

La campagne la plus intéressante pour l’instant reste une revue à quatre rôles de BannerGenerator. Le run Dynamic Workflow a terminé en 185 635 ms, produit 27 fichiers d’artefacts locaux, gardé le dépôt cible propre et trouvé des problèmes comparables à ceux d’une orchestration manuelle multi-agents. Les rôles manuels restent très forts pour l’analyse brute, mais le workflow gagne sur la reproductibilité et la traçabilité : les prompts, commandes, logs, identités, hash de policy et synthèse restent ensemble.

Les constats étaient concrets : un .codex-browser/auth.json suivi dans Git, des secrets locaux ignorés mais présents dans le worktree, des cibles make qui ne couvrent pas les vraies suites frontend/backend, de gros modules de coordination et un peu de dérive dans la documentation.

Le test suivant, sur Hermes, a été plus utile comme échec que comme benchmark. Le préflight a fini par passer, mais les deux workflows mesurés ont été invalides : sorties worker trop longues, résultats supprimés par l’hygiène d’artefacts, fallback last-message, et changement du status Git du dépôt cible pendant la campagne. Le run routé a même consommé plus de tokens que le run classique dans ce diagnostic précis. Je ne peux donc pas en faire une preuve de réduction de coût.

Ce qui reste faible

Je ne peux pas écrire que c’est un remplacement prêt pour les Dynamic Workflows.

Il reste encore des choses importantes à tester ou instrumenter :

  • le mode écriture, uniquement en worktree, avec génération de patch sans merge automatique ;
  • l’extinction de tout l’arbre de process quand un worker lance des enfants ;
  • un scan DLP formel des artefacts ;
  • une capture moins bruyante des sorties worker ;
  • des mesures strictes de durée et de tokens pour chaque méthode, sur un dépôt cible dont le status Git reste stable pendant toute la campagne ;
  • des campagnes répétées sur d’autres repos.

Le sujet CODEX_HOME mérite toujours une attention spéciale. Copier ou réutiliser un CODEX_HOME réel peut exposer plus que de l’authentification : plugins, configs MCP, caches, télémétrie, historiques ou connecteurs. Le mode codex-auth-only est donc minimaliste : il copie seulement auth.json. C’est mieux, mais ce n’est pas une preuve que les artefacts ne peuvent jamais contenir de secret si un prompt ou un workflow devient malveillant.

Il y a aussi un coût que je ne veux pas masquer. Ce lab a consommé beaucoup de tokens : campagnes ratées, agents manuels de comparaison, runs réels à plusieurs workers et correctifs successifs. Sur Hermes, les deux méthodes mesurées ont dépassé trois millions de tokens chacune, sans produire un benchmark exploitable. Le prochain vrai benchmark doit donc partir d’un contrat de sortie plus strict, d’un scope plus petit et d’un arrêt clair dès que la validité tombe.

Où je fais une pause

La version 0.1.12 est un bon point d’arrêt temporaire. Elle ajoute les choses que le dernier diagnostic a rendues évidentes : schémas JSON dans les workflows d’exemple, sorties bornées, pas d’extraits de code dans les findings, et garde pré/post du status Git quand les artefacts sont écrits hors du dépôt cible.

Je garde le repo public parce qu’il contient les traces utiles : le runtime, le plugin, les docs, les helpers de benchmark et RESULTATS.md. Mais je ne vais pas continuer les campagnes longues tout de suite. Avant de relancer, il faut un test plus petit, moins bavard, avec un budget de tokens assumé.

Ce que je retiens

La partie facile, c’est de faire écrire un script JavaScript.

La partie difficile, c’est de décider ce qu’un worker a réellement le droit de faire. Un workflow dynamique peut vite devenir une machine à lancer trop d’agents, trop de commandes et trop de logs. Il faut donc que la politique soit extérieure au modèle : nombre maximal d’agents, durée, taille de sortie, sandbox, chemins inscriptibles, modèles autorisés, secrets disponibles, annulation et nettoyage.

Dans ce lab, le script n’est pas une autorité. Il est une demande d’exécution sous une policy immuable. C’est probablement la différence la plus importante avec une simple macro ou un prompt réutilisable.

Le repo contient

Pour aller plus loin, j’ai mis le lab dans le repo pezzos/codex-dynamic-workflows-lab.

Le repo publié contient :

  • un runtime TypeScript ;
  • un CLI codex-flow ;
  • un serveur MCP stdio minimal ;
  • une skill dynamic-workflow ;
  • un manifeste plugin ;
  • un faux binaire codex pour les tests offline ;
  • un RESULTATS.md qui garde les preuves des runs du lab.

Il sert à

Il sert à tester une hypothèse : Codex peut-il retrouver l’usage principal des Dynamic Workflows avec des briques déjà disponibles, sans dépendre d’une API interne ?

Pour le moment, la réponse est : oui pour un workflow borné, en lecture seule, avec installation marketplace, propagation d’authentification, soumission MCP avec polling, artefacts traçables et règles de validité plus strictes. C’est plus qu’une démo à workers factices. Ce n’est pas encore un outil de production, ni une preuve que le routage réduit vraiment les tokens.

Il ne sert pas à

Il ne sert pas encore à automatiser des refactors, piloter des connecteurs ou laisser plusieurs agents modifier un repo en autonomie.

Je ne le lancerais pas les yeux fermés sur un dépôt client, et encore moins avec des connecteurs personnels. Le lab a justement montré que l’intérêt du plugin dépend moins du packaging que des garde-fous autour du runtime.