OpenCode 2.0 n’exécute pas automatiquement ses commandes sur un Mac parce que vous pouvez vous y connecter en SSH : placez son environnement de projet sur le Mac, ou configurez explicitement l’exécution distante, puis vérifiez séparément les fichiers modifiés, xcodebuild et les résultats de test. Ce guide s’adresse aux développeurs qui utilisent Windows ou Linux comme machine principale, aux équipes qui maintiennent une CI macOS et aux responsables qui doivent définir des preuves d’exécution fiables.

Dernière vérification : 24 octobre 2026. Les informations sur OpenCode ont été confrontées à sa documentation des outils et à son journal officiel des versions ; celles sur Xcode aux documentations Apple sur les outils en ligne de commande et les tests.

01

Le lieu d’exécution avant le nom de l’outil

Le premier contrôle n’est pas « Xcode est-il installé ? », mais « quel système exécute la commande demandée par OpenCode ? ». La documentation d’OpenCode décrit son outil bash comme exécuté dans l’environnement du projet. Il faut donc distinguer le poste qui héberge le processus OpenCode, le répertoire de travail qu’il utilise et le Mac distant auquel un terminal séparé peut se connecter.

Cette distinction explique un faux positif fréquent. Vous réussissez ssh <utilisateur>@<hote-mac>, mais une commande lancée par l’agent affiche encore les outils de Windows ou Linux. La connexion SSH établit un accès réseau et une session distante ; elle ne transforme pas, à elle seule, le terminal local d’OpenCode en terminal macOS. Cette conclusion découle de la séparation des environnements décrite par OpenCode, et non d’une garantie de transfert automatique.

Option d’exécution Où se trouvent les fichiers lus par l’agent ? Où s’exécutent les commandes Xcode ? À privilégier lorsque…
OpenCode local, commande locale Sur le poste Windows ou Linux Sur le poste local La tâche ne nécessite pas les outils Apple
OpenCode local, commande distante explicite À vérifier : copie locale, copie distante ou les deux Sur le Mac si l’appel SSH y lance réellement la commande Vous maîtrisez le transfert des commandes et la cohérence des fichiers
OpenCode et dépôt dans l’environnement du Mac Sur le Mac, dans le répertoire de travail utilisé Sur le Mac Vous voulez que lecture, modification et compilation visent le même environnement

À retenir : le nom d’un hôte dans votre configuration SSH ne prouve ni le répertoire courant de l’agent, ni l’endroit où ses outils s’exécutent. Vérifiez ces deux éléments depuis le contexte qui lance effectivement la commande.

Pour établir un point de départ, demandez au terminal utilisé par OpenCode d’afficher le répertoire courant et des informations permettant d’identifier l’hôte. Exécutez ensuite les mêmes contrôles dans une session SSH vers le Mac. Comparez les sorties. Si l’hôte ou le chemin diffère, vous avez identifié une séparation d’environnement avant même d’examiner Xcode.

02

Le dépôt réellement modifié

Un agent peut modifier un fichier sans toucher à la copie que votre Mac compile. Ce cas apparaît quand un dépôt existe à la fois sur le poste de développement et sur le Mac, ou quand un répertoire synchronisé ressemble au dépôt attendu sans être le même état de travail. La compilation peut alors être correcte tout en portant sur des modifications absentes.

Choisissez un repère commun avant de relancer la tâche : le chemin du dépôt et le commit attendu. Depuis le répertoire utilisé par OpenCode, relevez l’état Git et le commit courant. Faites la même vérification dans le répertoire qui sera compilé sur le Mac. Un commit identique est un bon repère de base, mais il ne suffit pas si des changements non validés existent ; comparez aussi les fichiers modifiés et leur contenu pertinent.

Indice observé Ce qu’il permet de conclure Vérification suivante
Chemins de dépôt différents L’agent et la compilation peuvent viser deux copies Confirmez le chemin attendu et choisissez une seule copie de travail
Commit identique, mais fichiers modifiés différents Les copies ont divergé après le commit Comparez l’état Git et les fichiers touchés par l’agent
Modification visible dans OpenCode, absente du Mac La modification n’a pas été transférée ou le Mac utilise un autre répertoire Vérifiez le mécanisme de transfert et le chemin consommé par la compilation
Même dépôt et mêmes modifications, mais échec inchangé Le décalage de copie n’est probablement pas la cause principale Passez au contrôle du compte, de Xcode et de la destination

Si vous envoyez explicitement une commande avec SSH, rendez son répertoire de départ visible dans la commande ou dans le journal. Un appel distant lancé depuis le mauvais dossier peut trouver un autre projet ou ne trouver aucun fichier de configuration. Évitez de résoudre le problème en copiant aveuglément tout le répertoire : vous risquez de compiler une version différente, d’écraser des changements ou d’inclure des secrets dans une copie non prévue.

03

Les contrôles du Mac et de Xcode

Quand le répertoire est confirmé, vérifiez le contexte du processus distant. Le compte interactif utilisé pour votre connexion SSH peut ne pas être celui qui exécute l’agent, le service ou la tâche de CI. Les variables d’environnement, le PATH et le répertoire développeur actif peuvent différer. Un contrôle effectué dans votre session personnelle n’est donc pas une preuve suffisante pour un processus lancé sous un autre compte.

Apple précise que les outils en ligne de commande sont distribués avec Xcode ou peuvent être installés séparément ; la présence de macOS seule ne garantit pas que la chaîne attendue soit disponible. La référence Apple à l’installation des outils en ligne de commande détaille cette dépendance. Vérifiez l’installation sur le Mac et dans le compte qui exécutera réellement la compilation.

Depuis ce contexte, contrôlez le chemin de xcodebuild, le répertoire développeur actif et la version de l’outil. Les commandes de référence d’Apple permettent notamment de consulter les informations de configuration de la chaîne Xcode ; consultez la référence des outils en ligne de commande Xcode pour les options pertinentes. Si xcodebuild est absent, ou si le chemin pointe vers une installation inattendue, corrigez d’abord le contexte ou la sélection de la chaîne, puis relancez un contrôle minimal.

Ne concluez pas qu’un projet est prêt parce qu’une commande locale du même nom fonctionne. La preuve utile vient de la machine distante, avec le compte et le mode de lancement réellement employés. Dans un environnement automatisé, inscrivez la sortie des contrôles dans le journal de tâche afin que l’échec soit reproductible, plutôt que de dépendre d’une vérification manuelle effectuée sous un compte différent.

04

Les accès au dépôt et les autorisations

Un dépôt lisible n’implique pas que toutes les opérations nécessaires soient autorisées. La lecture des sources, l’écriture des modifications, l’accès à une dépendance privée et l’usage de certificats de signature sont des droits distincts. Un échec de téléchargement d’une dépendance ne prouve pas que l’agent ne peut pas modifier le projet ; une erreur de signature ne signifie pas que xcodebuild est absent.

Lisez le journal au niveau de l’opération qui échoue. Repérez si la commande ne peut pas ouvrir un fichier, accéder à un dépôt de dépendances, lire un trousseau ou produire un artefact. Vérifiez ensuite l’identité du compte exécutant et les permissions de la ressource concernée. Ne répondez pas à une erreur ciblée en donnant des droits étendus à tout le dépôt ou au compte distant.

OpenCode fournit une configuration des autorisations de ses outils ; la documentation officielle des permissions décrit les règles à examiner. Utilisez-la pour limiter les actions de l’agent à ce dont la tâche a besoin, puis distinguez ces permissions de celles du système macOS. Une autorisation accordée à l’outil OpenCode ne crée pas automatiquement un accès à une clé de signature ; inversement, un compte système privilégié ne justifie pas d’autoriser sans contrôle toute commande de l’agent.

Pour une CI macOS, évitez de mêler les informations d’accès personnelles à celles du processus de compilation. Déterminez quel compte lit les sources, quel mécanisme fournit les justificatifs nécessaires aux dépendances et quel processus peut accéder aux éléments de signature. Consignez uniquement les informations nécessaires au diagnostic ; les journaux ne doivent pas révéler de secrets.

Point de vigilance : accordez le droit qui correspond à l’erreur constatée, puis répétez le test. Élargir les permissions avant d’avoir identifié la ressource fautive masque la cause et augmente le périmètre de risque.

05

La destination de test et le paquet de résultats

Une compilation réussie ne démontre pas qu’un test a été lancé. Le schéma, la destination et l’environnement de simulation doivent correspondre à la tâche. Une destination indisponible peut bloquer l’exécution des tests alors que le projet se compile ; à l’inverse, un paquet de résultats existant peut ne pas correspondre au commit que vous examinez.

Contrôlez le schéma choisi et les destinations visibles depuis le Mac exécutant la commande. Vérifiez aussi que le simulateur requis est disponible sur cette machine et que son environnement correspond au projet. Apple sépare les instructions pour l’exécution sur simulateur ou appareil de celles portant sur les tests et l’interprétation de leurs résultats. Utilisez ces références pour distinguer la préparation de la destination de l’analyse du résultat.

Quand la destination manque, ne classez pas immédiatement le problème comme un échec d’OpenCode. Le message peut révéler un schéma erroné, une cible de test non sélectionnée ou un simulateur absent. Notez la destination demandée et celle réellement disponible. Si la tâche doit s’exécuter sur un simulateur précis, adaptez la destination ou préparez l’environnement distant avant d’évaluer le résultat du test.

La vérification des résultats doit couvrir la commande entière, pas uniquement sa dernière ligne affichée :

  • relevez le code de sortie de la commande exécutée sur le Mac ;
  • conservez la sortie du terminal qui identifie le schéma et la destination ;
  • demandez explicitement un paquet de résultats à un chemin connu lorsque la commande le permet ;
  • confirmez que le paquet existe sur l’hôte distant et qu’il a été récupéré ou archivé par la CI ;
  • associez le fichier au commit réellement compilé et ouvrez-le pour lire les résultats.

La référence Apple sur les tests explique comment examiner les résultats dans Xcode. Pour éviter qu’un journal « terminé » soit pris pour une validation, définissez l’artefact attendu avant le lancement. Si le paquet n’existe pas, le test peut ne pas avoir démarré, la commande peut avoir échoué avant l’export ou l’étape d’archivage peut avoir omis le fichier. Ces causes appellent des corrections différentes.

06

Questions fréquentes sur OpenCode et Xcode distant

Où les commandes bash d’OpenCode s’exécutent-elles réellement ?

Elles s’exécutent dans l’environnement de projet utilisé par OpenCode. Si l’application et son répertoire de travail sont sur votre machine Windows ou Linux, une connexion SSH ouverte séparément vers un Mac ne déplace pas automatiquement ces commandes. Vérifiez le répertoire courant et l’hôte depuis le terminal appelé par l’agent, puis confirmez ces éléments sur le Mac si vous y envoyez explicitement la commande.

Comment faire travailler OpenCode sur le dépôt présent sur mon Mac distant ?

Faites en sorte que l’environnement d’exécution d’OpenCode et le dépôt soient réellement accessibles sur le Mac, ou configurez une orchestration explicite qui exécute les commandes distantes. Comparez le commit, le chemin du dépôt et l’état des fichiers avant et après une modification. Un dépôt homonyme ou un dossier synchronisé ne prouve pas que l’agent a modifié la copie destinée à la compilation.

Pourquoi xcodebuild reste-t-il introuvable alors que SSH fonctionne ?

SSH confirme l’accès au Mac, mais pas la présence de Xcode dans l’environnement du compte qui lance la commande. Depuis ce même contexte, contrôlez le chemin de xcodebuild et le répertoire développeur actif, puis vérifiez l’installation des outils en ligne de commande. Si l’agent exécute encore ses commandes sur votre poste, il ne verra pas le jeu d’outils du Mac distant.

Comment vérifier qu’OpenCode a bien enregistré les résultats des tests ?

Ne vous fiez pas uniquement à la ligne indiquant que la commande s’est terminée. Relevez son code de sortie, le chemin du paquet de résultats, puis vérifiez que ce fichier a été conservé ou récupéré par l’étape d’archivage. Ouvrez le résultat avec les outils Xcode appropriés et associez-le au même commit que celui utilisé pour la compilation.

07

Procédure de diagnostic reproductible

Pour transformer ces contrôles en une enquête exploitable, gardez le même commit et consignez chaque résultat dans un journal de tâche. La séquence suivante sépare l’environnement, le dépôt, la chaîne Xcode et la preuve de test.

  • Identifier le processus. Depuis le terminal utilisé par OpenCode, relevez l’hôte, le répertoire courant et l’identité d’exécution disponible. Répétez ces vérifications dans la session SSH que vous pensez utiliser. Un résultat différent indique qu’il faut clarifier l’architecture avant de modifier le projet.
  • Fixer la copie de référence. Notez le chemin du dépôt et le commit. Après la modification demandée à l’agent, inspectez les fichiers touchés au même endroit. Si la compilation se déroule ailleurs, comparez les états avant de poursuivre.
  • Vérifier la chaîne distante. Dans le contexte exact de la tâche, vérifiez la disponibilité de xcodebuild et la sélection du répertoire développeur. Si le chemin ou la chaîne ne correspond pas à l’installation attendue, résolvez ce point avant de changer les paramètres du projet.
  • Isoler l’accès qui échoue. Lisez le message d’erreur et identifiez la ressource concernée : source, dépendance, fichier de configuration ou élément de signature. Contrôlez les droits du compte et les autorisations OpenCode séparément, puis n’accordez que l’accès nécessaire.
  • Valider la cible. Confirmez le schéma et la destination demandés, puis vérifiez qu’ils existent dans l’environnement du Mac. Traitez une destination manquante comme un problème de préparation ou de sélection, pas comme la preuve d’un échec de l’agent.
  • Collecter une preuve complète. Conservez le code de sortie, la sortie de commande et le paquet de résultats. Vérifiez son existence sur le Mac, son transfert dans les artefacts de CI et son association au commit attendu.
  • Refaire un essai contrôlé. Gardez les mêmes sources et la même destination, ne changez qu’un élément diagnostiqué et comparez les résultats. Vous pourrez alors décider si le défaut venait de l’exécution locale, d’une copie incohérente, d’un accès manquant ou de la configuration de test.

Le résultat final doit permettre à un autre ingénieur de répondre à trois questions : quelle machine a exécuté la commande, quelle copie du dépôt a été compilée et où se trouve la preuve du test. Si l’une de ces réponses repose uniquement sur une supposition, l’échec n’est pas encore caractérisé.

08

Choisir l’architecture d’exécution

Le modèle local avec commande distante explicite peut convenir si votre équipe maîtrise le chemin du dépôt, le transfert des modifications et la collecte des résultats. Son avantage est de conserver OpenCode sur votre poste principal ; sa limite est la multiplication des points où les fichiers, les identifiants et les journaux peuvent diverger. Une commande SSH réussie ne valide pas le contenu effectivement compilé.

Placer l’environnement de travail et le dépôt sur le Mac réduit cette ambiguïté : l’agent peut lire les fichiers qui seront ensuite présentés à Xcode sur le même hôte. Cette option demande toutefois de définir comment vous accédez au Mac, comment vous protégez les justificatifs et comment vous conservez les artefacts. Pour préparer cet accès, consultez les offres de location de Mac mini et leurs modalités ; vérifiez que le mode d’accès proposé correspond à votre méthode d’exécution, sans présumer des outils ou des permissions disponibles.

Si vos tâches ne nécessitent pas Xcode, un environnement Linux peut rester plus simple à administrer. En revanche, une chaîne de compilation Apple exige un environnement où les outils Apple sont disponibles : ne traitez pas un contournement local comme un substitut durable à la preuve d’exécution sur macOS. Pour comparer l’exploitation d’un nœud distant à un achat matériel, examinez aussi les options de Mac mini en fonction de la durée d’usage, de la présence nécessaire d’interfaces physiques et de votre capacité à administrer la machine.

Si vos contrôles montrent que le blocage vient de l’absence d’un environnement macOS sur votre poste Windows ou Linux, un Mac distant peut éviter de reconstruire toute votre chaîne sur la machine principale. En contrepartie, vous devez gérer l’accès réseau, la cohérence du dépôt et la récupération des résultats ; une dépendance à des interfaces physiques ou une charge durablement stable peut justifier l’achat et l’administration d’un Mac local. Pour un besoin temporaire de compilation ou de validation, vous pouvez d’abord examiner les conditions d’accès à un Mac chez VpsMesh, puis décider à partir de votre mode de travail réel plutôt que d’une promesse de performance.