Faire travailler Claude Code et Codex en parallèle : une expérience avec Git worktree

Avant de demander à Claude Code de revoir un texte pendant que Codex corrige un export, donnez à chaque tâche son propre dossier de travail.

Si les deux conversations utilisent le même dossier, le fichier modifié par un agent devient une donnée d’entrée pour l’autre. Face à « les tests passent », vous risquez de ne plus savoir quels changements ont réellement été vérifiés.

Mettre à jour un texte de réglage et corriger l’export d’une date vide sont deux tâches que l’on peut mener en parallèle et examiner séparément. Cette expérience reproductible montre comment préparer les dossiers, répartir les tâches et tester leur résultat combiné. Un script réalise l’expérience ; les prompts sont des exemples à adapter à votre projet.

Définissez d’abord le périmètre et les critères de réussite

Le projet d’exemple comporte un fichier de textes pour les réglages et une fonction convertissant des horodatages en dates d’export.

La tâche de rédaction ne touche que settings.zh-CN.json et remplace la description « 管理设备 » par « 查看已登录设备，并撤销不再使用的设备访问 ». La tâche sur les dates corrige uniquement les valeurs manquantes, sans changer la règle qui exporte les horodatages valides en dates UTC.

Les chaînes chinoises simplifiées sont conservées pour que l’expérience reste reproductible. La première signifie « Gérer les appareils » ; la nouvelle description signifie « Voir les appareils connectés au compte et révoquer l’accès de ceux qui ne sont plus utilisés ».

Voici la fonction d’origine :

export function exportDate(value) {
  return new Date(value).toISOString().slice(0, 10);
}

Pour null, elle renvoie 1970-01-01 ; pour une chaîne vide, elle lève une exception. Aucun de ces comportements ne répond au besoin : une date manquante doit rester vide.

Exécutez d’abord les quatre tests : les deux cas de valeur manquante échouent, tandis que les cas d’horodatage UTC et d’horodatage avec fuseau horaire passent. Cette base est utile : la correction doit réparer les deux premiers sans modifier les deux autres.

Créez deux dossiers à partir du même commit

Dans un dépôt possédant déjà une branche main, vérifiez le commit de départ. Les noms de nouvelles branches et les dossiers cibles ci-dessous ne doivent pas être déjà utilisés :

git worktree add -b feature/settings-copy ../project-settings-copy main
git worktree add -b fix/export-dates ../project-export-dates main
git worktree list

Chaque worktree a son propre dossier de travail et son propre index, ce qui permet de conserver les changements sur une branche distincte. Ils appartiennent toujours au même dépôt Git. Chaque dossier part du commit indiqué ; les modifications non validées du dossier d’origine ne sont pas copiées automatiquement. Préparez les dépendances et la configuration locale selon les besoins du projet. Consultez la documentation officielle de Git worktree.

Vous obtenez les dossiers et branches suivants :

Un dossier par tâche permet de garder les deux copies disponibles en même temps. Changer de branche dans un dossier unique n’apporte pas cette séparation.

Choisissez le bon dossier pour chaque conversation dans Tactic Remote

Connectez-vous à l’ordinateur de développement, ouvrez le choix du projet dans Nouvelle conversation (New Conversation) et utilisez au besoin Choisir un autre dossier (Choose another folder) pour sélectionner le chemin réel du worktree. Choisissez ensuite l’agent.

Si les worktrees existent déjà, sélectionnez directement leurs dossiers. Créer un espace de travail indépendant (Independent Workspace) n’y ajoute pas automatiquement le dépôt ni sa relation avec une branche.

Vous pouvez commencer avec cette demande à Claude Code :

Modifie uniquement la description des appareils dans settings.zh-CN.json, pour expliquer que l’on peut voir les appareils connectés au compte et révoquer leur accès. Confirme d’abord le dossier et la branche. Ne touche pas à l’export des dates. À la fin, présente le diff du texte et vérifie la validité du JSON.

Et celle-ci à Codex :

Corrige export-date.mjs : null et une chaîne vide doivent renvoyer une chaîne vide ; les horodatages valides doivent rester exportés en dates UTC. Confirme d’abord le dossier et la branche, lance les quatre tests existants, reproduis le problème et fais le plus petit changement nécessaire. Ne modifie pas le texte des réglages. Présente les résultats avant et après la correction.

Délimiter les fichiers dans un prompt facilite la revue, mais ne crée pas de bac à sable de sécurité. Les fichiers que l’agent peut réellement lire ou écrire dépendent de ses permissions sur l’ordinateur.

Vérifiez séparément ce que chaque résultat établit

Dans l’exemple, la correction minimale consiste à tester les valeurs manquantes avant la conversion :

export function exportDate(value) {
  if (value === null || value === undefined || value === '') return '';
  return new Date(value).toISOString().slice(0, 10);
}

Ce code traite uniquement les valeurs manquantes convenues. Le comportement des autres chaînes de date invalides nécessite une règle distincte. Les horodatages valides restent exportés en UTC.

Dans chaque dossier, exécutez :

git status --short
git diff --name-only
git diff

Dans l’expérience, seul settings.zh-CN.json a changé dans le dossier de rédaction, et seul export-date.mjs a changé dans celui des dates. Nous avons aussi lu directement les fichiers pour confirmer que chaque dossier conservait la version d’origine du fichier confié à l’autre tâche.

Résultats obtenus :

La branche de rédaction a passé la vérification JSON tout en conservant les deux échecs connus des tests de date. Documentez la base de test et le périmètre de chaque vérification pour que la portée du résultat soit claire.

Intégrez les changements dans une branche bien identifiée

Une fois chaque changement revu et validé par un commit, créez une branche d’intégration dans le dossier d’origine du dépôt d’exemple :

git switch -c review/combine main
git merge --ff-only feature/settings-copy
git merge fix/export-dates
node --test export-date.test.mjs

Ces commandes supposent que le dossier d’origine n’a aucune modification en attente et que les deux branches de travail ont été validées par des commits. Dans un vrai projet, suivez le processus habituel de pull request et de fusion. En cas de conflit, comprenez d’abord les deux changements, puis vérifiez le résultat combiné.

Testez la fusion : deux changements peuvent interagir même s’ils passent séparément leurs vérifications. Des dossiers distincts ne suppriment pas les besoins de coordination autour des configurations, dépendances, bases de données ou ports serveur partagés.

Après avoir confirmé que les changements sont conservés, que l’arbre de travail est propre et que les dossiers ne servent plus, retirez-les avec git worktree remove. Si Git refuse à cause de modifications en attente, traitez d’abord le contenu indiqué par son message.

Sur le téléphone, identifiez d’abord la tâche et son résultat

Pour suivre les tâches parallèles depuis le téléphone, vérifiez l’ordinateur, le projet et la conversation. Lisez ensuite le dernier résultat et repérez ce qui demande votre décision.

Pour la rédaction, il peut suffire de valider un terme. Pour les dates, vous devrez peut-être choisir entre UTC et heure locale. Gardez la décision dans la conversation correspondante afin d’en retrouver la raison lors de la revue.

La méthode fonctionne dès deux tâches : un dossier, une demande claire et un résultat de vérification pour chacune, puis un contrôle de leur comportement combiné. En ajoutant des tâches, gardez chaque dossier, demande et résultat faciles à identifier.

L’expérience a été réalisée dans un dépôt Git local temporaire, sans appeler d’agent. Le script de reproduction et les résultats originaux permettent d’examiner chaque étape.