Piloter un seul agent Codex est simple. Vous ouvrez un terminal, décrivez une tâche et le regardez travailler. Les ennuis commencent à trois. Un agent refactorise le module d'authentification, un autre corrige un test instable, un troisième rédige une migration, et chacun vit dans son propre onglet de terminal avec son propre historique de défilement. Dix minutes plus tard, vous ne savez plus quel onglet contient quelle tâche, si la migration est terminée, ni sur quelle branche la correction du test a atterri. Les agents vont bien. C'est votre capacité à les suivre qui a lâché.
Voilà le vrai problème qui se cache derrière « gérer plusieurs agents Codex ». Il ne s'agit pas de concurrence ; Codex s'exécutera volontiers en parallèle dans des répertoires de travail distincts. Le problème, c'est que l'état de ce travail — ce que fait chaque agent, ce qui est terminé, ce qui a échoué, ce qui attend votre relecture — finit éparpillé entre les onglets de terminal, les dossiers worktree et votre propre mémoire. Perdez l'un de ces fils et vous perdez le fil.
Sharkly existe précisément pour combler ce vide. Vous avez déjà des agents de codage ; Sharkly en fait une équipe en donnant à chaque exécution d'agent un enregistrement partagé. Cet article détaille d'abord la configuration manuelle, car il faut comprendre ce que l'on automatise, avant de montrer où un tableau de tâches mérite sa place. Vous terminerez avec une checklist applicable dès aujourd'hui.
Ce que « perdre le fil » signifie vraiment
Perdre le fil n'a rien de vague. C'est une défaillance précise : votre état de travail n'a pas de foyer unique. Quand vous lancez plusieurs sessions Codex à la main, la vérité de chaque tâche est répartie sur quatre endroits à la fois. L'instruction vit dans le terminal où vous l'avez saisie, les modifications vivent dans un répertoire de travail Git, le statut vit dans votre tête, et le résultat vit dans une pull request que vous n'avez pas encore ouverte. Rien ne synchronise ces quatre sources. Fermez le terminal et l'instruction disparaît. Changez d'onglet et le statut devient une supposition. Plus vous ajoutez d'agents, plus vous maintenez de copies de « ce qui se passe », et vous êtes le seul point d'intégration qui les fait tenir ensemble.
L'objectif de la gestion de plusieurs agents Codex est donc étroit et mérite d'être énoncé clairement : garder la tâche, la progression, les modifications et le statut de relecture de chaque agent au même endroit, au lieu de les disperser entre des sessions de terminal privées. Tout ce qui suit est jugé à l'aune de ce seul critère.
Étape 1 : isoler chaque agent avec un worktree
Le premier mode de défaillance est la collision. Pointez deux agents Codex vers le même dossier et ils écrasent mutuellement leurs modifications, indexent les fichiers de l'autre et produisent un diff illisible. Les worktrees Git règlent ce problème proprement en donnant à chaque agent sa propre copie de travail du même dépôt, sur sa propre branche.
# One isolated working directory per task, each on its own branch
git worktree add ../repo-auth -b agent/auth-refactor
git worktree add ../repo-flaky -b agent/flaky-test
git worktree add ../repo-migration -b agent/db-migration
Lancez maintenant une session Codex dans chaque répertoire. Chaque agent ne voit que ses propres fichiers, commite sur sa propre branche et ne peut pas marcher sur les autres.
cd ../repo-auth && codex # agent 1, auth refactor
cd ../repo-flaky && codex # agent 2, flaky test
Mode d'échec à nommer ici : les worktrees règlent les collisions de fichiers, pas le suivi. Vous avez désormais trois dossiers aux noms quasi identiques et aucun enregistrement de la tâche que chacun contient. Adoptez une convention de nommage qui encode la tâche (agent/<task>), car dans une semaine repo-2 et repo-3 ne voudront plus rien dire. Pour les mécanismes plus détaillés, voir Git worktrees pour les agents de codage IA et le schéma plus large dans exécuter plusieurs tâches Codex à la fois.
Étape 2 : garder les sessions sous les yeux
Trois agents dans trois onglets, c'est être à un Cmd+W accidentel de tuer une tâche en cours et de perdre son historique de défilement. Un multiplexeur de terminal comme tmux maintient chaque session en vie dans des fenêtres nommées auxquelles vous pouvez vous détacher et vous rattacher plus tard.
tmux new-session -d -s codex -n auth 'cd ../repo-auth && codex'
tmux new-window -t codex -n flaky 'cd ../repo-flaky && codex'
tmux new-window -t codex -n migration 'cd ../repo-migration && codex'
tmux attach -t codex
Les fenêtres nommées (auth, flaky, migration) restaurent l'étiquette qu'un onglet brut jette aux oubliettes. Détachez-vous avec Ctrl-b d, fermez votre ordinateur portable, rattachez-vous le lendemain matin : les sessions sont toujours là.
Mode d'échec à nommer ici : tmux garde les sessions en cours d'exécution ; il ne vous dit pas lesquelles ont besoin de vous. Un agent qui a terminé il y a vingt minutes et un agent qui a rencontré une erreur sont identiques vus de l'extérieur : un panneau silencieux. Vous devez quand même visiter chaque fenêtre et lire les cent dernières lignes pour connaître son statut. Ce coût de scrutation augmente avec chaque agent ajouté, et c'est la taxe qui alourdit la configuration manuelle au fil du temps.
Étape 3 : consigner le statut et la relecture dans un endroit durable
La dernière pièce manuelle est celle que les gens sautent : noter ce que chaque agent a produit et si vous l'avez accepté. L'historique de défilement n'est pas un enregistrement. Il disparaît, il n'est pas interrogeable d'une tâche à l'autre, et un coéquipier ne peut pas le lire. La version légère est une simple checklist que vous mettez à jour à la main.
TASK BRANCH STATUS REVIEW
auth refactor agent/auth-refactor done needs review
flaky test agent/flaky-test running -
db migration agent/db-migration failed: perm not reviewed
C'est tout le travail en miniature : un endroit durable où progression, blocages, résultats et relecture humaine restent visibles de la demande à la mise en production. Tenez-le fidèlement et vous pourrez gérer plusieurs agents depuis un terminal pendant longtemps. Le hic, c'est que vous êtes le moteur de synchronisation, à le mettre à jour à la main dès que quelque chose change. Pour en savoir plus sur l'auditabilité de la production des agents, voir comment suivre le travail réalisé par les agents de codage IA.
Là où la configuration maison cesse de passer à l'échelle
Soyez honnête sur le moment où l'approche manuelle suffit. Pour un ou deux agents Codex sur des tâches bien délimitées, worktrees + convention de nommage + fichier de statut tenu à la main, c'est franchement très bien. N'ajoutez pas d'outillage dont vous n'avez pas besoin ; les pièces mobiles sont quasi nulles et l'ensemble tient dans votre tête.
L'équation change à un point prévisible. Vous le sentez quand :
- Vous exécutez trois agents ou plus et le coût de scrutation (visiter chaque panneau, lire la fin, mémoriser le statut) consomme plus de temps que les agents n'en font gagner.
- Le travail s'étend sur plus d'un dépôt, si bien que les worktrees seuls cessent d'offrir une image claire.
- Quelqu'un d'autre demande « que font les agents en ce moment ? » et la seule réponse honnête se trouve dans votre terminal et votre mémoire.
Chacune de ces situations a la même cause racine qu'au début de l'article : un état de travail sans foyer partagé. La configuration manuelle le garde au seul endroit qui ne passe pas à l'échelle : vous. Les équipes atteignent ce mur le plus vite, et c'est pourquoi les meilleurs outils pour gérer des agents de codage IA parallèles convergent tous vers le même geste : donner au travail un foyer en dehors du terminal.
Ce qu'apporte un tableau de tâches
Un tableau de tâches fait passer l'unité de gestion de « une session de terminal » à « une Task ». Dans Sharkly, vous connectez le Computer sur lequel Codex tourne déjà, puis vous assignez une Task à un Codex Agent au lieu de taper dans un panneau. L'Agent s'exécute dans son propre worktree isolé, et l'exécution, la progression, les blocages et les résultats reviennent dans la Task. Vous arrêtez de scruter ; le tableau sait déjà ce qui est terminé et ce qui a échoué.
La répartition des rôles est délibérée, et mérite d'être posée comme une frontière : Sharkly ne remplace pas Codex. Codex exécute. Sharkly ajoute autour de lui la couche partagée de tâche, de Computer, de contexte et de relecture. Les agents recherchent, exécutent, testent et rendent compte ; les humains donnent la direction, accordent l'autorité et acceptent le résultat. L'automatisation s'arrête là où votre jugement est requis, c'est-à-dire à la porte de relecture, pas au code.
Voilà ce que le fichier de statut manuel cherchait à atteindre, rendu durable et partagé. Trois choses que le terminal ne peut pas vous offrir en découlent :
- Un statut sans scrutation. Chaque Task affiche en cours, terminée, bloquée ou à relire, sans que vous ayez à visiter un panneau.
- Une vue unique à travers les dépôts. Les Tasks de nombreux dépôts et de nombreux Agents se retrouvent dans un seul Space, si bien que plus d'agents ne veut pas dire plus de terminaux à surveiller. C'est la même raison qui pousse les équipes à exécuter Claude Code et Codex ensemble depuis un seul endroit.
- Une étape de relecture qui tient. Les résultats attendent à une porte human-in-the-loop avec le résumé des modifications et les preuves attachées, afin que rien ne soit fusionné parce que vous avez oublié qu'une revue était en attente.
Vous pouvez construire tout cela à la main avec des worktrees et de la discipline, ou utiliser Sharkly pour gérer le flux de travail quand le nombre d'agents grimpe. Codex reste exactement tel qu'il est ; la gestion quitte vos épaules. Si vous exécutez déjà plusieurs agents Codex, c'est le problème autour duquel Sharkly est conçu.
La checklist à appliquer dès aujourd'hui
Que vous restiez en manuel ou passiez à un tableau, voici le minimum pour ne pas perdre le fil :
- [ ] Un worktree isolé par agent, sur une branche nommée d'après la tâche, jamais deux agents dans un même dossier.
- [ ] Une convention de nommage qui encode la tâche, pour que
agent/auth-refactorl'emporte surrepo-3. - [ ] Des sessions longue durée (tmux ou un tableau) auxquelles vous pouvez vous détacher et vous rattacher sans tuer le travail.
- [ ] Un enregistrement de statut durable en dehors de l'historique du terminal : tâche, branche, statut, état de relecture.
- [ ] Une porte de relecture explicite ; aucune branche n'est fusionnée avant qu'un humain l'accepte.
- [ ] Un contrôle du nombre : à partir de trois agents, ou deux dépôts, sortez le statut de votre tête.
Utilisez la version manuelle jusqu'à ce que la taxe de scrutation fasse mal. Quand ce sera le cas, faites passer vos agents de codage existants par Sharkly pour que le suivi soit le travail du tableau, pas le vôtre.
FAQ
Combien d'agents Codex puis-je réellement exécuter en même temps ? Autant que votre machine et vos limites de débit le permettent ; le plafond que vous atteignez en premier est généralement humain, pas technique. Suivre trois agents ou plus à la main, c'est là que la plupart des gens perdent le fil. Voir threads concurrents et sous-agents Codex pour les limites côté exécution.
Un tableau de tâches remplace-t-il Codex ? Non. Codex exécute ; le tableau gère l'assignation, l'isolation, le contexte et la relecture autour de lui. Ils se complètent.
