Claude Code et Codex en parallèle dans des checkouts séparés

Claude Code et Codex peuvent avancer dans des checkouts Paneflow séparés si leurs tâches sont indépendantes. Attribue les fichiers de chaque tâche, relis ses changements, puis intègre et teste les deux branches ensemble. Diviser le terminal ne sépare pas les fichiers accessibles aux agents.

Deux tâches qui peuvent avancer seules

Pour un premier essai, demande à Claude Code de mettre à jour docs/setup.md et à Codex d'ajouter des tests dans tests/parser.test.js pour un parseur existant. Les deux partent de la même base commitée. Fixe d'abord le comportement attendu du parseur ; si les tests nécessitent une implémentation encore absente, effectue les tâches successivement.

Prévois Paneflow 0.17.4, un dépôt Git avec une base commitée et des agents installés et authentifiés. La syntaxe a été vérifiée avec Claude Code 2.1.286 et Codex CLI 0.159.2 sous Windows x64 le 1er octobre 2026. L'authentification, l'accès aux modèles et leur facturation dépendent du fournisseur de chaque agent.

Choisir le checkout avant de lancer l'agent

1. Suis la référence des worktrees pour créer docs/setup-guide et test/parser-cases depuis la même base, avec Worktree activé. Une branche existante peut réutiliser un checkout : vérifie son chemin.
2. Ouvre un terminal dans chaque checkout. Exécute ces commandes dans les deux et vérifie que répertoires et branches diffèrent :

git rev-parse --show-toplevel
git branch --show-current
git status --short

3. Installe les dépendances dans le checkout qui en a besoin. Affecte un port de serveur de dev distinct à chaque tâche, par exemple 3001 et 3002, via les commandes propres au projet.
4. Lance claude dans le checkout de documentation et codex dans celui des tests. Saisis toi-même la tâche bornée. Ne demande pas aux agents de toucher aux fichiers de l'autre tâche ni d'intégrer automatiquement les branches.

Les points d'entrée interactifs figurent dans les références Claude Code et Codex. Une commande introuvable indique un problème d'installation ou de PATH dans ce shell ; vérifie claude --version ou codex --version avant de réessayer.

Suivre l'activité, puis relire

Les indicateurs d'activité de Paneflow dépendent de l'intégration de chaque agent. Un état inactif ne prouve pas que les tests passent. Lis le terminal, réponds aux demandes de permission et inspecte le checkout actif dans Changes. Cette vue compare les changements staged, unstaged et les fichiers non suivis au HEAD du checkout, pas l'ensemble de la branche.

Enregistre les buffers de l'éditeur avant la revue. Exécute les tests pertinents dans leur checkout, relis séparément la documentation, puis conserve le travail relu dans des commits. Intègre-les dans ton checkout d'intégration selon le workflow Git de ton équipe, résous les conflits et lance la suite combinée. Lis le diff complet de branche en complément de Changes. Le résultat attendu est deux contributions relues et un arbre combiné testé, pas seulement deux messages de fin.

Ce qui a été vérifié

La répétition technique de ce guide utilise uniquement des shells sous Windows x64 : deux worktrees Git, modifications indépendantes, inspection de chaque checkout et intégration. Les versions et l'aide des agents ont aussi été vérifiées. Le mainteneur a confirmé la création et la réutilisation des worktrees Paneflow lors de la revue précédente ; leur implémentation en 0.17.4 établit le comportement livré. Cette répétition ne constitue ni un test payant de modèle ni une comparaison de vitesse.

Quand réduire le parallélisme

Deux agents qui modifient le même fichier dans un checkout partagé peuvent écraser leur travail ou créer des conflits. Les worktrees séparent les fichiers de travail, mais les commits peuvent encore entrer en conflit à l'intégration. Attribue les fichiers ou lance la tâche dépendante ensuite.

Ports, bases de données, CPU, mémoire et limites du fournisseur restent partagés. Une collision de ports demande une configuration distincte, pas un panneau supplémentaire. Si les builds saturent la mémoire, si les appels sont limités ou si une tâche attend sans cesse le résultat inachevé de l'autre, mets-en une en pause. Un worktree n'est pas une sandbox de sécurité ; les secrets locaux et permissions réseau demandent leurs propres contrôles.

Garde la référence des worktrees pour gérer les checkouts et le guide Files pour les conflits de sauvegarde pendant la revue du résultat combiné.