GitHub Copilot : fichiers limités, dépôt distant accessible

Le 23 septembre 2026, GitHub a annoncé le bac à sable local de son application Copilot, en préversion publique. Il limite les accès des outils lancés par l’agent sur votre machine, mais ne bloque pas, à lui seul, les actions sur un dépôt distant : la politique initiale autorise le réseau et les opérations Git authentifiées.

Pour laisser un agent modifier un premier projet sans lui donner les voies de publication prévues par cette politique, il faut régler séparément les fichiers, le réseau et les identifiants. L’analyse de BaristaLabs relève le même écart entre l’isolation locale et les accès réseau et Git permis par défaut. Le bac à sable est désactivé au départ et son activation se décide projet par projet.

Ce que la limite locale protège

Le bac à sable encadre les outils que l’agent invoque, en les exécutant dans un environnement isolé par le système d’exploitation. La documentation de l’application Copilot précise que cette politique concerne les sessions locales liées à un dépôt ou à un arbre de travail. Elle ne s’applique ni aux sessions dans un bac à sable distant ni aux sessions exécutées sur un hôte distant.

Dans une session isolée, l’espace de travail et le répertoire courant restent accessibles en lecture et en écriture. L’agent peut donc modifier les fichiers du projet : c’est le travail que cette configuration est censée lui permettre. Les paramètres du projet servent à ajouter des dossiers en lecture et écriture, à n’en ouvrir d’autres qu’en lecture seule ou à interdire des dossiers précis. Un dossier expressément interdit reste inaccessible même si un dossier parent bénéficie d’une autorisation plus large.

Un arbre de travail Git sépare les branches et les fichiers utilisés par des sessions parallèles. Cette séparation ne restreint pas, par elle-même, les emplacements qu’une commande peut atteindre sur la machine ; la politique du bac à sable apporte cette limite supplémentaire. « Protéger les fichiers » signifie ici contrôler les accès des outils selon des chemins et des permissions, non rendre intouchable le code que l’agent est chargé de modifier.

Pourquoi le dépôt distant reste à portée

Le réseau obéit à un réglage distinct de celui des fichiers. Par défaut, une session isolée peut joindre Internet, notamment GitHub et les registres de paquets, ainsi que le réseau local et les services de développement qui y répondent. Une commande peut ainsi être cantonnée aux fichiers autorisés sur la machine tout en conservant une connexion sortante. Les paramètres « Outbound internet » et « Local network » permettent de traiter séparément ces destinations.

L’authentification constitue une autre permission. Le réglage « Git credentials » rend possibles les opérations Git authentifiées en HTTPS ; « GitHub CLI credentials » permet à la commande gh de s’authentifier. Tous deux sont autorisés dans la politique initiale. Si le réseau et les droits du compte le permettent aussi, les outils isolés peuvent donc pousser une branche ou créer une pull request. La frontière autour des fichiers locaux n’est pas une interdiction de publier vers GitHub.

Ces permissions ne se remplacent pas entre elles. Refuser l’accès à un dossier voisin ne coupe pas Internet ; retirer les identifiants Git ne ferme pas la connexion réseau ; et bloquer Internet peut empêcher une publication tout en interrompant le téléchargement des dépendances ou un appel d’API. L’effet recherché dépend de la combinaison des accès, pas du seul interrupteur qui active le bac à sable.

Configurer un premier projet sans publication distante

Dans les paramètres de l’application, sélectionnez le projet, puis activez « Sandbox new sessions » sous « Sandbox ». Ce choix vaut pour les nouvelles sessions locales du projet ; il ne modifie pas une session déjà ouverte. Pour un essai où l’agent doit travailler uniquement sur le code local, la configuration la plus restrictive parmi les réglages décrits consiste à conserver l’écriture dans l’espace de travail, à ne pas ajouter de dossiers accessibles et à désactiver « Outbound internet », « Git credentials » et « GitHub CLI credentials ».

Si l’essai n’a besoin ni d’un serveur de développement local ni d’un autre service du réseau privé, désactivez également « Local network ». Cette configuration retire aux outils isolés la connexion extérieure et les deux mécanismes d’authentification documentés pour Git et gh. C’est une recommandation adaptée à cet objectif précis, pas le réglage initial proposé par GitHub ; elle peut empêcher une installation de paquets, un appel à un service externe ou l’ouverture d’une prévisualisation locale.

Une session locale déjà active peut recevoir la commande « /sandbox on ». Elle active l’isolation pour cette session sans changer le réglage par défaut du projet. En revanche, une modification des permissions de fichiers, de réseau ou d’identifiants prend effet dans une nouvelle session, ou après le redémarrage de la session existante avec « /restart-session ». Les paramètres de l’application GitHub Copilot et ceux de Copilot CLI sont distincts : changer l’un ne configure pas l’autre.

Les exceptions qui changent la portée du réglage

Si un outil réclame un accès refusé, l’application peut afficher « Run outside the sandbox? ». Selon la politique applicable, il est alors possible d’annuler l’opération, de lancer cet outil une fois hors du bac à sable ou de désactiver l’isolation pour le reste de la session. Autoriser l’une de ces exceptions change la portée de l’essai : l’opération concernée ne reste plus soumise aux permissions choisies. Une politique administrée par une entreprise peut empêcher l’exécution d’outils hors du bac à sable et rendre les permissions effectives plus strictes que celles demandées pour le projet.

La limite du réseau local demande une attention particulière sur Linux. Pour les processus lancés par la session, notamment les commandes shell et certains serveurs locaux, le bac à sable ne peut pas contrôler cet accès indépendamment ; le réglage continue de s’appliquer aux opérations exécutées dans le processus de l’application. Il serait donc excessif de présenter la désactivation de « Local network » comme une garantie identique pour toutes les commandes et tous les systèmes.

Enfin, l’application vérifie la capacité du système à appliquer la politique lorsque démarre le premier shell isolé. Si la politique demandée ne peut pas être imposée, ce shell échoue avec une erreur au lieu de s’exécuter sans bac à sable. La fonction reste en préversion publique et ses modalités peuvent évoluer. Son état actuel est clair : elle donne un contrôle par projet sur les outils locaux, tandis que l’accès à un dépôt distant dépend des permissions réseau, des identifiants et des exceptions effectivement accordés à la session.