Laissez OpenCode corriger le bug pendant que vous gardez votre espace de travail

Votre modification est à moitié écrite quand quelqu’un signale un bug dans l’analyse des dates. Vous voulez continuer à modifier vos fichiers et confier une autre tâche à l’agent de programmation. Dès que vous touchez au même dossier, même un petit correctif devient difficile à démêler du travail en cours.

Le 6 novembre, OpenCode 2.2.6 a ajouté une option d’arbre de travail pour ses exécutions scriptées en ligne de commande. OpenCode est un agent de programmation libre avec une interface de terminal interactive et une commande distincte pour lancer une consigne depuis un script. La nouvelle option permet de démarrer dans un arbre de travail Git séparé, de lui donner éventuellement un nom et de laisser le dossier d’origine disponible. La version ajoute aussi le partage facultatif des connexions compatibles du Model Context Protocol (MCP). Deux questions se posent donc avant le lancement. Quels fichiers l’agent peut-il modifier et quels services peut-il utiliser ? Version OpenCode v2.2.6 · Documentation de la ligne de commande

Une configuration utile combine une tâche précise, un point de départ prévisible, un endroit où examiner les changements et des autorisations explicites pour ce qui sort du projet.

La capture d’écran du projet OpenCode montre un correctif et une session dans le terminal. Ce visuel de la version publiée illustre l’interface. La notice MIT accompagne l’image. Telli.sh a redimensionné la capture et ajouté une marge.

Un dossier à part donne un diff facile à attribuer

Un arbre de travail Git donne à chaque tâche ses propres fichiers et son propre index. Illustration originale de Telli.sh.

Les arbres de travail Git rattachent plusieurs dossiers à un même dépôt. Chacun a ses fichiers, son index et sa révision active. La plupart des données du dépôt sont partagées. Un arbre séparé permet d’examiner le correctif de l’agent pendant que vos modifications restent en place. Cela change aussi les sources que l’agent voit. Les modifications du premier dossier qui n’ont pas fait l’objet d’un commit n’apparaissent pas dans le second du seul fait que les deux appartiennent au même dépôt. Documentation Git sur les arbres de travail

La version du 6 novembre décrit trois façons d’utiliser l’option. opencode run -w et opencode run --worktree créent un nouvel arbre de travail. --worktree=<name> lui donne un nom. La version précise aussi que l’option ne se combine pas avec --continue ou --session. Il faut un nouveau contexte de départ. Si un rapport d’erreur est déjà accompagné d’un long échange, reprenez les étapes de reproduction et le résultat attendu dans la nouvelle consigne. Version OpenCode v2.2.6 · Implémentation et exemples des arbres de travail

Voyez le dossier séparé comme le lieu de la revue. Avant de lancer l’agent, notez la branche et le commit attendus. Ensuite, vérifiez le commit et l’état de son arbre. Si un test dépend d’une donnée non suivie ou d’un changement qui existe seulement dans l’éditeur, la différence de point de départ explique un désaccord apparent. Un correctif peut fonctionner pour une ancienne version du code tout en étant inadapté à la branche que vous allez livrer.

Essayez une petite correction avant de confier un chantier plus large

Commencez sur un dépôt dont vous êtes responsable et avec une tâche précise. Un test de date bissextile en échec convient mieux qu’une mise à niveau générale, car le résultat attendu est simple à vérifier. Corriger un lien de navigation périmé avec un test de route serait tout aussi délimité. Dans les deux cas, indiquez le comportement à changer et le contrôle à effectuer ensuite.

1. Consignez l’état de départ. Dans le dossier courant, exécutez git status --short et git rev-parse HEAD. Conservez le résultat avec le rapport de bug. Si le test de référence passe déjà, notez comment le relancer. Vérifiez avec opencode --version que votre version dispose de la nouvelle option. Version OpenCode v2.2.6

2. Donnez une tâche à l’agent dans un arbre nommé. Mettez les étapes de reproduction et le test ciblé dans la consigne. L’exemple utilise un analyseur de dates fictif et suppose que le dépôt contient déjà un test adapté. Demander de laisser les modifications sans commit facilite la revue. Fixez les limites plus strictes dans les autorisations et l’environnement d’exécution.

   ShellExécuter dans Terminal

   opencode run --worktree=date-parser "Reproduce the leap-day parsing bug in the date parser tests. Fix the narrow cause, run the targeted tests, and leave the changes uncommitted for review."
   

3. Localisez le dossier avant d’examiner le résultat. Exécutez git worktree list depuis le dépôt d’origine et utilisez le chemin affiché. Dans le nouveau dossier, consultez git status --short, git diff et git diff --cached. La dernière commande compte si l’agent a indexé des fichiers. Examinez les fichiers non suivis à part. Relancez vous-même les tests depuis le dossier de l’agent et vérifiez qu’ils couvrent le 29 février d’une année bissextile et une année où la date est invalide. Documentation Git sur les arbres de travail

4. Intégrez seulement le travail examiné. Conservez la proposition à part jusqu’à pouvoir appliquer un commit ou un correctif revu à la bonne branche. Vérifiez à nouveau l’état du dossier d’origine. Gardez le dossier de l’agent jusqu’à avoir noté les informations utiles et confirmé qu’il ne contient plus de modifications à conserver. La liste Git aide à associer chaque dossier à sa tâche. Documentation Git sur les arbres de travail

Le même principe aide si deux problèmes sans rapport arrivent ensemble. Donnez une portée limitée à chacun et comparez les deux diffs avant d’intégrer quoi que ce soit. Les modifications de test non indexées d’un agent resteront dans son dossier. Les correctifs peuvent encore entrer en conflit sur la même branche, surtout s’ils touchent une fonction commune. L’intégration et le test de non-régression restent dans la revue habituelle.

Déterminez qui peut agir en dehors du dépôt

Deux arbres de travail peuvent s’exécuter sous le même compte système. Ils peuvent accéder au même environnement, aux mêmes gestionnaires d’identifiants et au même réseau. L’option choisit où démarre l’exécution et sépare les modifications ordinaires. Fixez des limites distinctes de compte ou d’environnement lorsque la tâche l’exige. Une demande d’autorisation contrôle les outils qui la respectent. Le système d’exploitation ou l’environnement d’exécution fixe ce que le processus peut atteindre.

Distinguez l’emplacement des changements, l’autorisation des outils et l’accès du processus. Illustration originale de Telli.sh.

La documentation V2 décrit des règles ordonnées pour chaque action. Les effets comprennent allow, ask et deny, et la dernière règle correspondante l’emporte. Un exemple officiel demande une confirmation pour les commandes shell, puis autorise les commandes courantes d’inspection et interdit les envois vers le dépôt distant. Si personne n’est présent pour valider, testez la réaction d’une règle ask dans ce parcours avant de la mettre dans une tâche récurrente. Fixez des interdictions claires dans la configuration et utilisez des identifiants de courte durée et à portée limitée pour les services indispensables. Documentation OpenCode sur les autorisations

Une tâche limitée à la documentation permet d’essayer ces couches simplement. Autorisez l’agent à modifier une section d’un projet exemple. Donnez-lui un fournisseur autorisé et aucun identifiant de production. Après le script, vérifiez que le correctif touche uniquement le fichier attendu. Si une automatisation future a besoin d’un dépôt distant ou d’un outil de suivi, donnez à chaque capacité une raison et vérifiez ses droits séparément.

Le partage d’une connexion convient à des projets qui partagent déjà les mêmes droits

MCP permet à l’agent d’utiliser les outils d’autres programmes, comme un moteur de recherche documentaire ou un suivi de tickets. Dans la version du 6 novembre, pool: true permet aux dossiers servis par un seul serveur OpenCode de réutiliser une connexion quand leur configuration correspond. La documentation V2 précise que le partage s’applique à la révision du protocole du 28 juillet 2026. Si un serveur négocie une révision plus ancienne, les connexions restent séparées. Une même adresse ne suffit pas. Les réglages distants et les comptes authentifiés doivent correspondre. Pour un serveur local, il faut aussi comparer la commande, l’environnement et le dossier de travail. Version OpenCode v2.2.6 · Documentation OpenCode sur le partage MCP

Imaginez deux arbres qui interrogent le même service documentaire interne avec le même compte. Le partage peut éviter de préparer deux connexions si le service prend en charge la bonne révision. Confirmez d’abord que les deux dossiers doivent accéder au même contenu et que l’intégration ne donne que les capacités requises. Si le premier a seulement besoin de documents publics et que le second peut ouvrir des tickets internes, des connexions séparées rendent leurs droits plus lisibles.

Un serveur local peut dépendre de son dossier courant. Un processus lancé dans chaque projet peut recevoir un contexte local différent même si le texte de la commande est identique. Selon la documentation, un dossier de travail fixe est nécessaire pour partager des connexions locales entre projets, et une connexion partagée n’a pas de racines MCP. Commencez donc avec un service en lecture seule qui définit clairement son périmètre. Si le comportement de l’outil dépend du dépôt qui l’appelle, mesurez les changements avant de passer à une connexion partagée. Documentation OpenCode sur le partage MCP

Les exécutions scriptées ont aussi besoin d’une fin

OpenCode 2.2.6 ajoute --archived pour démarrer les sessions scriptées ou de CI à l’état archivé et les garder hors de la liste habituelle. Cela modifie la présentation de la session. Consignez le résultat, le chemin de l’arbre et les tests là où les personnes chargées de la revue peuvent les retrouver. Utilisez l’option une fois que le correctif reste accessible sans passer par la boîte de réception habituelle. Les notes du 6 novembre précisent que --continue ignore les sessions archivées. Version OpenCode v2.2.6

La version modifie aussi le cycle de vie d’une exécution scriptée. Avant de quitter, elle attend les commandes d’arrière-plan, les sous-agents et les tâches d’image lancés par la consigne. Les notes ne prévoient pas de limite interne à cette attente. Un serveur de développement ou un outil de surveillance peut donc retenir la session. Pour des tests automatiques, choisissez des commandes qui se terminent une fois le contrôle achevé et bornez l’étape de CI. Distinguez une exécution annulée, un test en échec et un agent qui a annoncé un succès. Après un dépassement de délai, vérifiez l’état du correctif avant de relancer ou d’intégrer. Version OpenCode v2.2.6

Une fois le pilote en place, mesurez autre chose que le message de fin de l’agent. Combien de temps faut-il pour préparer un nouveau lancement, comprendre le changement et le contrôler ? À quelle fréquence quelqu’un doit-il réparer une modification sans rapport ou examiner un outil bloqué ? Comparez des tâches de taille similaire en comptant préparation et revue. L’arbre séparé vaut surtout quand le correctif reste assez petit pour qu’une personne en assume la responsabilité.

Un dossier propre rend la responsabilité lisible

L’option donne un point de départ clair à la personne chargée de la revue. Elle peut voir la référence, examiner le changement et relancer le test pendant que l’autre développeur continue. Rendez le partage des connexions et les droits d’exécution tout aussi explicites. Le meilleur passage de relais est un petit correctif dont on peut lire le point de départ, le changement et la preuve qu’il est prêt à être intégré.

Sources

• Capture officielle du terminal OpenCode et licence du dépôt

• Version OpenCode v2.2.6 du 6 novembre 2026

• Documentation de la ligne de commande OpenCode

• Autorisations OpenCode V2

• Partage des connexions MCP dans OpenCode

• Manuel Git des arbres de travail

---

Pour retrouver les décisions et les essais qui ont guidé votre travail, créez un compte Telli.sh.