Si vous avez lu mon article sur les worktrees avec Claude Code, vous savez que la clé c’est un simple drapeau : --worktree. Vous lancez une commande et un agent fonctionne sur sa propre copie isolée. Vous en lancez trois et vous obtenez trois agents en parallèle sans conflits. Du pur génie.
Et puis vous ouvrez Codex CLI, vous cherchez le drapeau équivalent et… il n’existe pas.
Pas de --worktree. Pas de --tmux. Pas de isolation: worktree pour les agents personnalisés. L’issue #12862 est ouverte sur GitHub et des gens ont déjà développé des solutions dans leurs forks, mais aucune n’a été intégrée. À l’heure où cet article est écrit, le parallélisme natif avec Codex CLI n’existe pas.
Cela signifie-t-il que vous ne pouvez pas travailler en parallèle avec Codex ? Non. Mais cela signifie que vous allez devoir bricoler. Et par “bricoler”, j’entends trois commandes git et quelques précautions pour éviter de vous planter.
Le plan : des worktrees manuels + un Codex par répertoire
L’idée est la même que pour Claude Code, mais sans automatisation. Vous créez les worktrees vous-même, vous lancez les agents vous-même, et vous nettoyez les déchets vous-même. Artisanat pur, mais ça fonctionne.
| |
Vous voilà avec quatre répertoires : le principal et trois worktrees. Chacun avec sa propre branche, son propre staging area et son propre HEAD indépendant. Ils partagent la base de données git (.git/), mais pour le reste, ce sont des copies isolées.
L’étape suivante consiste à lancer un Codex dans chacun d’eux :
| |
Trois agents, trois tâches, zéro interférence. Chaque Codex ne voit que son worktree et travaille sur sa propre branche.
Le bug qui va vous faire perdre la tête : les sessions partagées
Voilà la partie que vous ne trouverez dans aucun tutoriel officiel. Il existe un bug connu (#11435) dans Codex CLI : toutes les instances partagent le répertoire de session ~/.codex/. Si vous lancez trois Codex en parallèle, ils peuvent lire le contexte d’une autre instance et corrompre l’exécution.
Pour dire les choses simplement : l’agent censé corriger les tests peut soudainement croire qu’il est en train d’implémenter l’authentification, parce qu’il a lu les données de session d’un autre.
La solution consiste à forcer un répertoire de session différent pour chaque instance :
| |
Si CODEX_HOME ne fonctionne pas dans votre version (la variable a changé de nom entre différentes versions), vous pouvez opter pour une alternative moins élégante en créant un fichier config.toml séparé dans chaque worktree :
| |
Ce n’est pas la méthode la plus propre. C’est une bidouille. Mais ça fonctionne, et c’est tout ce que nous avons jusqu’à ce que l’issue #12862 soit intégrée.
Automatiser un peu : un script wrapper
Si vous prévoyez de faire ça souvent, un script peut réduire les erreurs tout en vous faisant gagner du temps :
| |
Comment l’utiliser :
| |
Chaque exécution crée un worktree, une session isolée, lance Codex et nettoie la session à la fin. Le worktree reste actif pour que vous puissiez inspecter le résultat avant de fusionner.
Avec tmux : le parallélisme visuel
Si vous voulez voir les trois agents travailler en simultané, tmux est votre meilleur allié :
| |
Trois panneaux, trois agents, tout visible d’un coup. Ce n’est pas comme claude --worktree --tmux, mais le résultat visuel est identique.
Outils tiers qui simplifient tout
Si tout ce bricolage vous semble être du boulot, sachez que des outils automatisent déjà ce processus :
parallel-code : Exécute Claude Code, Codex et Gemini CLI dans des worktrees séparés de manière automatisée. Vous définissez une tâche et un agent, et il se charge de tout.
ccmanager : Gestionnaire de sessions pour plusieurs agents avec isolation par worktree. Plus complet et compatible avec plusieurs CLIs d’agents.
Ce sont des solutions issues de la communauté, non officielles. Mais elles comblent le vide laissé par OpenAI.
Ce que l’app Codex a (et le CLI n’a pas)
Pour être clair : l’application Codex de bureau (sortie en mars 2026) a des worktrees natifs. Quand vous créez un thread, vous pouvez choisir le mode “Worktree”, et les automations fonctionnent en arrière-plan dans des worktrees dédiés.
Cependant, l’application nécessite que vous la lanciez sur votre bureau. Si vous travaillez sur un serveur ou via le terminal, ou si vous préférez simplement une interface ligne de commande, l’application ne vous servira pas. Et le CLI, que vous utiliserez dans ces contextes, reste dépourvu de cette fonctionnalité.
C’est comme si Git avait des worktrees uniquement sur l’interface graphique mais pas en ligne de commande. Incohérent, mais c’est la réalité.
La comparaison honnête
| Fonction | Claude Code | Codex CLI | Codex CLI + worktrees manuels |
|---|---|---|---|
| Créer un worktree | --worktree (1 flag) | Non disponible | git worktree add (manuel) |
| Sessions parallèles | --tmux (1 flag) | Bug #11435 | tmux manuel + sessions séparées |
| Agents isolés | isolation: worktree | Non disponible | Script wrapper |
| Nettoyage automatique | Oui | N/A | Manuel (git worktree remove) |
| Fusion des branche | Automatique | N/A | git merge standard |
Claude Code a fait des worktrees une simple pièce invisible de la mécanique. Avec Codex CLI, c’est à vous d’assurer la plomberie.
Est-ce que ça marche ? Oui. Est-ce pareil ? Non. La différence entre automatisation native et bricolage est comme la différence entre une voiture automatique et une voiture à manivelle. Les deux vous mèneront à destination, mais l’un est un plaisir, l’autre une corvée.
En attendant l’issue #12862
La bonne nouvelle, c’est que des gens travaillent déjà sur ce problème. L’issue a des implémentations dans des forks, elle est votée, elle progresse. C’est juste une question de temps.
En attendant, les worktrees manuels fonctionnent. Ce n’est ni élégant ni automatique, mais vous pouvez obtenir un véritable parallélisme avec Codex CLI dès maintenant. Trois commandes git, un peu de tmux, et attention aux sessions partagées. C’est tout ce qu’il vous faut.
Et si vous vous demandez pourquoi Claude Code a résolu ce problème il y a des mois et que Codex en est toujours au même point, eh bien — parfois, l’avantage d’être deuxième, c’est de pouvoir copier ce qui marche. Mais il faut encore le copier, et ce n’est pas encore fait.
TL;DR : Codex CLI n’a ni --worktree, ni --tmux. Pour travailler en parallèle, créez des worktrees avec git worktree add, lancez un Codex dans chacun avec des sessions séparées (attention au bug #11435 des sessions partagées) et utilisez tmux pour tout voir d’un coup. Sinon, installez parallel-code ou ccmanager, qui automatisent le tout. L’app Codex de bureau a des worktrees natifs, mais pas le CLI.