Comment déployer VS Code Agent Host sur un Mac cloud ? Tutoriel 2026

Vous fermez votre ordinateur portable et le long traitement de l’agent s’arrête, ou vous retrouvez un dépôt modifié sans savoir quel outil a écrit quoi.

La solution la plus rapide consiste à déployer l’Agent Host sur un Mac cloud indépendant, proche du dépôt et de la chaîne Xcode, puis à vous y connecter par SSH ou tunnel de développement avec une arborescence Git isolée. La persistance de session ne sécurise toutefois pas l’exécution : vous devez encore tester la reprise, les accès, les outils et le retour arrière.

Cet article est destiné aux développeurs iOS et macOS qui veulent laisser GitHub Copilot, Claude ou Codex exécuter une tâche longue dans un projet Xcode, aux ingénieurs plateforme qui administrent plusieurs sessions distantes, ainsi qu’aux responsables AI Coding qui évaluent une capacité Mac élastique.

Mise à jour : dernière vérification le 3 septembre 2026, à partir de la documentation officielle de l’architecture Agent Host, de la gestion des sessions, des connexions distantes, des paramètres IA et des références Xcode citées dans ce guide. Les fonctions encore en développement restent signalées comme telles.

Le bon périmètre avant le premier lancement

Le déploiement de VS Code Agent Host sur un Mac cloud ne consiste pas à déplacer « l’IA » sur une autre machine. L’Agent Host est le processus qui conserve l’état de la session, lance le harness de l’agent et exécute les modifications de fichiers ou les commandes dans l’espace de travail distant. Le modèle et son fournisseur restent une couche distincte ; VS Code constitue le client ; les extensions et outils MCP ajoutent encore une autre surface de permissions.

L’architecture officielle confirme qu’un Agent Host peut fonctionner comme processus local ou comme service distant indépendant, auquel plusieurs clients peuvent se connecter selon la documentation d’architecture de VS Code. Cette séparation répond au problème des fenêtres VS Code éphémères, mais elle ne crée ni bac à sable automatique ni frontière de sécurité entre les dépôts.

Avant de réserver une machine, écrivez une fiche de responsabilité :

• Session : quelles conversations, sorties de terminal et demandes de confirmation doivent rester disponibles après la fermeture du client ?
• Exécution : quels dossiers, scripts, simulateurs, outils de compilation et commandes système l’agent peut-il utiliser ?
• Identité : quel compte Git, quelle clé SSH, quel jeton de modèle ou quelle configuration MCP sont autorisés ?
• Données : où se trouvent le dépôt, les artefacts, les journaux et les éventuels fichiers contenant des secrets ?
• Nettoyage : qui supprime la branche de travail, révoque les identifiants et efface les artefacts à la fin de la tâche ?

Un Mac distant est réellement justifié lorsque la tâche doit appeler Xcode, un simulateur, des outils de signature, des dépendances macOS ou un environnement de test audio, vidéo ou graphique propre à Apple. Pour une simple transformation de texte ou une vérification indépendante du système, un environnement non macOS peut être plus simple à administrer. Cette distinction évite de payer une machine persistante pour une tâche qui n’utilise aucun composant Apple.

Choix de connexion et préparation du Mac

SSH ou tunnel de développement pour l’accès distant ?

SSH offre une entrée réseau familière : vous contrôlez les clés, le compte distant, la journalisation et les règles de filtrage. Il convient à une équipe qui possède déjà une gestion centralisée des identités et qui veut réduire les composants spécifiques à VS Code. En revanche, vous devez traiter vous-même l’exposition réseau, la rotation des clés, l’accès aux ports et la disponibilité de la machine.

Le tunnel de développement évite généralement d’ouvrir directement le Mac sur l’Internet entrant et s’intègre au mécanisme de connexion documenté par VS Code. La documentation officielle des tunnels distants détaille néanmoins les conditions d’authentification et les implications de sécurité : un tunnel n’est pas une autorisation implicite pour tous les collaborateurs, ni un remplacement de la gestion des comptes.

Ne choisissez pas les deux simultanément pour un premier pilote. Vous ne saurez plus quelle couche est responsable d’une panne et vous risquez de multiplier les identités actives. Le choix correct est celui que votre équipe sait révoquer, auditer et remettre en service sans intervention improvisée.

Première heure d’installation

Commencez avec un compte macOS dédié à l’agent, sans privilèges administrateur permanents. Préparez le dépôt dans un volume dont la sauvegarde et la suppression sont comprises par l’équipe ; ne montez pas d’emblée votre répertoire personnel complet. Installez Xcode et les outils de ligne de commande selon la référence Apple consacrée aux outils en ligne de commande Xcode, puis vérifiez que l’utilisateur distant peut lancer les commandes nécessaires sans dialogue graphique inattendu.

Suivez ensuite cette séquence, en conservant une preuve à chaque étape :

1. Vérifier la version et le canal VS Code. Comparez la version installée avec la documentation et les notes de version officielles. Une fonction observée dans VS Code Insiders ne doit pas être présentée comme disponible dans la version stable.
2. Contrôler les fonctions IA activées. Consultez les paramètres IA de VS Code et notez les options expérimentales, les fournisseurs autorisés et les modes de confirmation.
3. Installer l’Agent Host comme processus indépendant. Enregistrez la commande de lancement, le compte macOS, le répertoire de travail et la méthode prévue pour le redémarrage.
4. Exposer une seule voie d’accès. Configurez SSH ou le tunnel de développement, puis testez l’authentification avec le compte réellement utilisé par l’équipe.
5. Ouvrir une session sans modification. Connectez un client VS Code, affichez l’état de l’Agent Host et confirmez que le terminal distant correspond bien au Mac prévu.
6. Consigner le premier échange. Sauvegardez la version, l’horodatage, l’identité, le chemin du dépôt et le résultat de la connexion.

Le critère d’arrêt est simple : si vous ne pouvez pas expliquer en une phrase quel processus tourne, avec quel compte et dans quel dossier, n’envoyez pas encore de tâche à l’agent. Revenez à la configuration minimale et corrigez la traçabilité.

Séparer les outils, les comptes et les modifications

GitHub Copilot, Claude ou Codex : un même hôte, des capacités différentes

Le choix du harness ne doit pas être traité comme un simple changement de modèle. GitHub Copilot, Claude et Codex peuvent différer par leur mode d’authentification, leur accès aux outils, leurs demandes de confirmation et la gestion des options expérimentales. L’Agent Host Protocol étant encore en développement continu, vous devez vérifier chaque combinaison de client, d’agent et de fournisseur dans la version effectivement déployée.

Pour chaque harness, créez une fiche d’essai comprenant :

• le compte utilisé et la méthode de connexion ;
• le modèle ou le point d’entrée sélectionné ;
• les outils autorisés ;
• les commandes qui exigent une confirmation ;
• le comportement lorsque le client disparaît ;
• le contenu conservé dans la session après reconnexion.

Ne déduisez pas qu’un fonctionnement constaté avec GitHub Copilot s’applique automatiquement à Claude ou Codex. Les capacités propres au fournisseur, les clés gérées par l’utilisateur et certains outils clients peuvent être expérimentaux ou dépendre d’une extension particulière.

Arborescences Git isolées

Une session par fenêtre VS Code n’est pas une isolation de dépôt. Deux agents peuvent écrire dans le même répertoire, modifier le même fichier ou produire des tests incohérents avant que vous ne voyiez la différence. Pour une tâche parallèle, créez une branche et une arborescence de travail dédiées, ou adoptez une convention équivalente que votre équipe sait supprimer proprement.

La meilleure option de départ est généralement l’arborescence dédiée sur un Mac réservé à l’expérimentation, à condition que les caches, les fichiers ignorés et les services auxiliaires ne réintroduisent pas un état partagé. Le guide interne sur l’isolation de tâches parallèles avec Git worktree peut servir de point de comparaison pour formaliser cette organisation.

Faites exécuter une tâche réversible : modifier un texte visible, lancer la suite de tests ciblée, produire le diff, puis simuler successivement le commit, l’abandon et la restauration. Vérifiez également si l’Agent Host écrit directement dans le dépôt, dans l’arborescence de travail ou dans un répertoire temporaire. La preuve utile n’est pas « l’agent a généré du code », mais « chaque changement peut être attribué, revu et supprimé ».

Attention : la persistance d’une conversation ne garantit pas la persistance d’un processus enfant. Un script peut être interrompu par un redémarrage, une expiration de session, une demande interactive ou la fermeture d’un outil lancé par l’extension cliente.

Reconnexion, reprise et synchronisation des fenêtres

Un ordinateur local fermé laisse-t-il réellement l’agent continuer ?

Oui, l’objectif architectural est que l’Agent Host indépendant conserve la session lorsque le client VS Code local est fermé. Cela ne signifie pas que toutes les opérations se poursuivent sans condition. Le processus hôte, le harness, les commandes enfants, le réseau, le Mac distant et les outils clients doivent rester disponibles. La documentation VS Code sur les sessions distantes décrit le principe de connexion à un agent distant ; votre validation doit porter sur votre propre chaîne d’exécution.

Lancez une tâche représentative mais réversible, par exemple une modification limitée accompagnée d’un test ciblé. Observez l’état et la sortie du terminal, fermez le premier client, attendez un changement identifiable, puis reconnectez-vous. Le journal doit permettre de distinguer :

• la poursuite effective du processus ;
• la simple conservation de l’historique de conversation ;
• l’attente d’une approbation humaine ;
• l’échec d’un outil ou d’un sous-processus.

Plusieurs fenêtres peuvent-elles reprendre la même session ?

Plusieurs clients peuvent se connecter à une même session selon l’architecture confirmée par VS Code, mais « se connecter » ne veut pas dire « écrire en parallèle sans coordination ». Ouvrez une seconde fenêtre ou une entrée navigateur prise en charge, affichez le même identifiant de session, puis comparez l’état du terminal, le journal des événements, le diff et les demandes de confirmation.

N’envoyez pas deux instructions de modification en même temps lors de ce test. Commencez par une fenêtre en observation et l’autre en contrôle. Si l’état diverge, arrêtez l’essai, exportez les journaux et revenez à une seule fenêtre active. La procédure de gestion des sessions et de leur reprise doit être votre référence pour les opérations supportées, plutôt qu’une déduction faite à partir d’un affichage local.

Séparez ensuite trois pannes :

• Client fermé ou réseau local interrompu : l’Agent Host devrait rester joignable depuis un autre client si son processus et le Mac sont sains.
• Mac distant redémarré : la session peut nécessiter un mécanisme de relance et les outils en cours peuvent perdre leur état.
• Processus Agent Host arrêté : la conservation d’une session ne relance pas nécessairement le service ni les commandes enfants.

Le test est réussi uniquement si vous pouvez vous reconnecter, retrouver un état intelligible, identifier les changements et décider entre reprendre, annuler ou restaurer.

Xcode, navigateur et MCP dans le périmètre réel

L’Agent Host peut-il appeler Xcode et les outils MCP ?

Il peut exécuter les commandes disponibles sur le Mac distant, mais l’accès pratique dépend des permissions, de l’installation, du contexte utilisateur et de l’outil qui porte l’intégration. L’Agent Host fournit une base d’exécution ; le client VS Code, son extension ou un serveur MCP peut fournir une capacité supplémentaire. Ne confondez donc pas « le terminal distant fonctionne » avec « le navigateur, le simulateur et MCP sont disponibles après déconnexion ».

Commencez par un projet macOS ou iOS sans enjeu de publication. Vérifiez dans cet ordre :

1. la résolution des dépendances et la présence des certificats nécessaires ;
2. la sélection du projet, de la cible et du schéma Xcode ;
3. la compilation en ligne de commande ;
4. l’exécution des tests ;
5. la localisation des journaux et des artefacts ;
6. la lisibilité du résultat depuis une seconde connexion.

Pour interpréter correctement les résultats, utilisez la documentation Apple sur l’exécution des tests et l’interprétation des résultats. Un fichier généré ou une réponse correcte de l’agent ne vaut pas validation de livraison : il faut confirmer que le projet se construit, que les tests s’exécutent dans le bon environnement et que l’artefact produit est récupérable.

Pour MCP, limitez la configuration initiale à des serveurs nécessaires et documentés. La référence officielle de configuration MCP de VS Code doit être consultée pour les paramètres réellement supportés. Contrôlez le chemin des exécutables, les variables d’environnement, le transfert des demandes d’approbation et les secrets injectés. Si un outil nécessite une interface graphique, une saisie interactive ou un navigateur ouvert dans le client local, il peut devenir indisponible lorsque celui-ci est déconnecté.

Le navigateur mérite la même prudence : autorisez un domaine de test, interdisez les actions irréversibles et conservez une validation humaine pour les téléchargements, les changements de compte, les publications et les opérations de signature. Pour les usages audio, vidéo ou design, ajoutez une vérification des volumes montés, des codecs, des licences et de la récupération des fichiers produits ; ces dépendances sont souvent absentes d’un simple test de code.

La première semaine d’exploitation

Après le pilote, ne mesurez pas seulement le temps pendant lequel la conversation est restée visible. Suivez la durée d’exécution, les appels d’outils, les échecs de commande, les relances, les demandes d’intervention, les collisions Git et l’occupation du Mac. Les relevés doivent répondre à une décision : un Mac partagé suffit-il, ou chaque tâche longue doit-elle obtenir un environnement indépendant ?

Établissez un registre par session :

• identifiant de la tâche et dépôt concerné ;
• branche ou arborescence utilisée ;
• identité et secrets temporaires autorisés ;
• commandes ayant modifié le système ou les fichiers ;
• résultat des tests et emplacement des artefacts ;
• moment de la déconnexion et résultat de la reconnexion ;
• action finale : fusion, abandon, archivage ou suppression.

Ajoutez ensuite les tests d’exploitation que le premier essai laisse souvent de côté : snapshot du dépôt, nettoyage d’une arborescence abandonnée, révocation d’un jeton, arrêt brutal du Mac, relance de l’Agent Host et archivage des journaux. Le guide de validation des permissions et de la récupération d’un agent distant fournit une grille complémentaire pour transformer ces contrôles en critères d’acceptation.

Un pilote doit rester limité tant que l’une de ces conditions n’est pas démontrée :

• une session reprend après la fermeture du client ;
• une seconde fenêtre retrouve un état cohérent ;
• un changement est isolé et réversible ;
• Xcode produit un résultat vérifiable ;
• chaque outil MCP possède une permission et un propriétaire identifiables ;
• un redémarrage du Mac ne laisse pas de secret ou de travail orphelin.

Décision d’exploitation : si la reprise fonctionne mais que les outils clients disparaissent hors connexion, réduisez le périmètre aux commandes exécutables par l’hôte. Si les changements ne sont pas attribuables, suspendez le parallélisme avant d’augmenter la capacité.

Décision finale : partager ou isoler le Mac

Le partage d’un Mac peut convenir à des tâches courtes, peu sensibles et séparées par des arborescences Git. Une machine dédiée par tâche devient plus pertinente lorsque les builds Xcode se chevauchent, que les simulateurs conservent un état gênant, que les secrets diffèrent ou qu’un échec doit être reproduit sans pollution de cache. Votre choix doit partir des journaux de la première semaine, non d’une promesse générale de persistance.

Si votre solution actuelle repose sur un ordinateur local laissé allumé, vous supportez les mises en veille, les coupures réseau domestiques, les conflits entre fenêtres et l’absence de séparation nette entre vos fichiers personnels et l’agent. Si vous utilisez un serveur distant non macOS, vous devrez en plus contourner Xcode, le simulateur et certaines étapes de signature. Une location MacPull apporte alors un environnement macOS distant contrôlable pour les essais, les tâches longues et les pics de build, sans vous obliger à acheter immédiatement une machine dédiée.

Avant de choisir une durée de location, comparez vos journaux de sessions avec le guide MacPull d’estimation de capacité pour le développement distant. Si vos tâches restent irrégulières, que les arborescences sont courtes et que la priorité est de tester Xcode ou un agent sans immobiliser du matériel, consultez les offres Mac cloud de MacPull. Si vos charges sont continues, fortement parallèles ou liées à des interfaces physiques, l’achat et l’administration d’un parc dédié peuvent rester plus adaptés qu’une location.

Le bon déploiement n’est donc pas celui qui maintient une conversation visible le plus longtemps. C’est celui qui permet de reprendre une tâche, de comprendre chaque écriture, de reconstruire l’environnement Xcode et de revenir à un état propre lorsque l’agent ou le Mac distant échoue.