Présentation des stratégies de système de fichiers pour le bac à sable local dans GitHub Copilot CLI

Introduction

Lorsque vous activez le bac à sable local, Copilot CLI exécute les commandes qu’il appelle pour votre compte à l’intérieur d’un bac à sable du système d’exploitation. Le bac à sable applique une politique du système de fichiers : un ensemble de règles qui déterminent quels chemins d’accès un processus ou une opération exécuté dans le bac à sable peut lire, lesquels il peut écrire et auxquels il ne peut pas accéder du tout.

La plupart de cette stratégie est assemblée automatiquement, de sorte que les commandes quotidiennes continuent de fonctionner sans configuration. Cet article explique comment Copilot détermine la stratégie et comment vérifier les autorisations qu’elle accorde dans un répertoire donné.

Pour obtenir une vue d’ensemble du bac à sable local, notamment comment l’activer et l’désactiver, consultez À propos des environnements isolés dans le cloud et locaux pour GitHub Copilot et Utiliser le sandbox local. Pour plus d’informations sur la configuration du bac à sable local, consultez Configuration des paramètres de bac à sable local.

À quoi s’applique la stratégie

La stratégie de système de fichiers couvre le travail Copilot en votre nom, mais elle est appliquée de différentes manières en fonction du type de travail :

• Les commandes shell et les recherches intégrées s’exécutent comme des processus enfants isolés, de sorte que le système d’exploitation applique directement la politique. Les outils grep et glob, par exemple, exécutent ripgrep comme processus enfant isolé.
• Les processus MCP locaux et les serveurs de langage (LSP) s’exécutent dans le sandbox par défaut. Par conséquent, le système d’exploitation leur applique également la stratégie. Vous pouvez modifier ce paramètre dans les paramètres du bac à sable, sauf si une stratégie gérée l’exige.
• Les outils intégrés de lecture et de modification de fichiers font partie de Copilot CLI lui-même, plutôt que de s’exécuter comme un processus enfant isolé. Ils vérifient la même politique de système de fichiers avant de lire ou d’écrire un fichier, mais comme la sandbox du système d’exploitation n’a jamais connaissance de ces opérations, ce contrôle ne constitue qu’une protection logicielle, et non une protection appliquée par le système d’exploitation.
• Les serveurs MCP distants s’exécutent à l’extérieur de votre machine, il n’existe donc aucun processus enfant local à sandboxer et la politique du système de fichiers ne s’applique pas à eux. Leurs connexions depuis le CLI peuvent toujours être limitées par la stratégie réseau lorsque Sandbox MCP servers est activé.
• Les subagents utilisent d’autres outils pour effectuer leur travail. Le fait de savoir si la politique s’applique, et de quelle manière, dépend de l’outil qu’un sous-agent invoque.

Un processus isolé dans un bac à sable est donc contraint par le système d’exploitation, tandis qu’une opération au sein du processus applique la même politique au niveau logiciel, c’est pourquoi cet article parle d’un processus isolé ou d’une opération au sein du processus plutôt que seulement de commandes.

Niveaux d’autorisation

Le bac à sable est refusé par défaut : sauf si un chemin d’accès est explicitement accordé, une commande ne peut pas l’utiliser. Chaque chemin d’accès de la stratégie comporte l’un des trois niveaux d’autorisation suivants :

• Lecture/écriture : la commande peut lire et modifier des fichiers à ce chemin d’accès.
• Lecture seule : la commande peut lire des fichiers sur ce chemin d’accès, mais pas les modifier.
• Refusé : la commande ne peut pas lire ou écrire sur ce chemin, même si une règle plus large l’autoriserait autrement.

Puisque l’accès est refusé tant qu’il n’a pas été accordé, Copilot doit accorder à une commande l’accès à tout ce dont elle a légitimement besoin — les fichiers de votre projet, les outils qu’elle exécute et des emplacements annexes tels que les répertoires temporaires — tout en laissant tout le reste inaccessible.

Création de la stratégie

Avant le démarrage de chaque processus isolé, Copilot CLI détermine la stratégie effective pour ce processus à l’aide du répertoire de travail actuel, de l’environnement, des paramètres et des autorisations automatiques. Cela inclut les emplacements courants nécessaires aux outils, de sorte que vous n’avez pas besoin de les autoriser un par un vous-même. Les outils peuvent également recevoir l’accès aux fichiers de session sélectionnés et aux compétences installées dont ils ont besoin pour fonctionner.

Votre répertoire de travail

Lorsque l’option Inclure le répertoire de travail est activée dans les paramètres du système de fichiers pour le bac à sable local (comme c’est le cas par défaut), le répertoire de travail actuel reçoit un accès en lecture/écriture. Dans un référentiel Git, Copilot ajoute également les subventions Git associées. La désactivation de ce paramètre supprime toutes ces subventions automatiques afin d’ajouter manuellement des règles d’autorisation pour le projet requis et les chemins Git. Consultez « Configuration des paramètres de bac à sable local ».

Outils dans votre variable PATH

Pour exécuter un programme tel que python ou git, le bac à sable doit laisser la commande voir le répertoire dans lequel se trouve le programme. Lorsque l’accès à l’outil de développement est activé, tel qu’il est par défaut,Copilot accorde un accès en lecture seule aux répertoires répertoriés dans votre PATH variable d’environnement, ainsi que les répertoires nommés par des variables d’outil associées telles que GOPATH, JAVA_HOMEet PYTHONPATH. Le mode lecture seule est le niveau d’accès approprié pour les outils externes : une commande doit être exécutée sur git, sans le modifier. Si vous désactivez l’accès à l’outil de développement , ces répertoires ne sont plus accordés automatiquement et doivent provenir de vos propres règles d’autorisation. Pour obtenir la liste complète des variables d’environnement et de chaîne d’outils que le PATH bac à sable inspecte, et comment chacun d’eux est interprété, consultez Référence de commande CLI pour GitHub Copilot.

Emplacements du système et du profil

Sur macOS, les emplacements système standard reçoivent une autorisation en lecture seule afin que les commandes puissent charger des bibliothèques partagées et lire la configuration du système sans pouvoir les modifier. Les répertoires d’application dans votre profil utilisateur (par exemple, les sous-répertoires d’Windows %LOCALAPPDATA%\Programs ou les ~/.local/bin``~/.local/lib répertoires sur macOS et Linux) sont également autorisés en lecture seule lorsque l’accès aux outils de développement est activé, afin que les commandes puissent lire les outils que vous avez installés sans pouvoir les modifier.

Caches du gestionnaire de package

Quand autoriser l’accès aux outils de développement est activé, Copilot accorde l’accès aux caches et registres utilisés par les gestionnaires de package courants et les chaînes d’outils. La plupart des emplacements sont en lecture seule. Les emplacements sélectionnés, tels que le cache de npm, les caches de build et certains magasins de dépendances, sont accessibles en écriture afin que les installations et les builds puissent fonctionner.

Ces autorisations dépendent de la commande et des outils détectés dans votre projet. Ils peuvent suivre les emplacements de cache que vous avez configurés en dehors des répertoires habituels. Certains fichiers de configuration autorisés contiennent des identifiants du registre, et des caches accessibles en écriture peuvent être partagés avec des commandes que vous exécutez en dehors du sandbox. Désactivez l’accès aux outils de développement si vous préférez accorder ces accès vous-même.

Dans le /sandbox policy rapport, la section Outils de développement répertorie les outils détectés et leurs chemins d’accès. Les caches accessibles en écriture sélectionnés sont créés lorsqu’une commande en a besoin. Ils peuvent donc ne pas apparaître dans le rapport avant la première utilisation.

Référentiels Git

Lorsque vous travaillez dans un sous-répertoire d’un référentiel Git, Copilot accorde l’accès en lecture au référentiel entier afin que les commandes puissent voir le projet complet, tout en limitant les écritures dans votre répertoire de travail actuel et les métadonnées Git du référentiel (son .git répertoire). Cela permet à une commande de lire dans le référentiel, mais conserve les modifications axées sur l’endroit où vous travaillez.

Étant donné que l’accès en lecture s’étend sur l’ensemble du référentiel, une commande en bac à sable peut lire des fichiers en dehors de votre sous-répertoire actuel, y compris tout élément sensible stocké ailleurs dans le projet. Pour rendre certains chemins d’accès inaccessibles, vous pouvez ajouter des règles de refus d’accès. Consultez « Configuration des paramètres de bac à sable local ».

Lorsque les règles d’accès se chevauchent

Étant donné que Copilot accorde plusieurs emplacements, et que vous pouvez ajouter les vôtres, les règles peuvent se chevaucher. Lorsque les octrois en lecture seule et en lecture/écriture se chevauchent, le chemin plus spécifique gagne. Par exemple, si /project est accessible en écriture, mais que vous marquez /project/secrets en lecture seule, tout ce qui se trouve dans /project reste accessible en écriture, sauf /project/secrets. Les chemins refusés sont prioritaires sur les deux types d’autorisation.

Les autorisations de répertoire d’outils découvertes sont remplacées par un accès en lecture/écriture qui les couvre déjà. Considérez un projet Python avec un environnement virtuel local (.venv) qui apparaît sur votre PATH. Considérer ce répertoire comme un emplacement d’outil ordinaire en lecture seule le rendrait en lecture seule, même s’il se trouve dans votre projet accessible en écriture, et une commande telle que pip install pourrait alors échouer lorsqu’elle tenterait de mettre à jour l’environnement. Copilot laisse cela modifiable en écriture dans le cadre de votre espace de travail. Les autres règles en lecture seule, y compris celles que vous configurez vous-même, ne sont pas ignorées de cette façon.

Les règles que vous configurez ne sont pas supprimées uniquement parce que le même chemin d’accès a été découvert automatiquement. Vous pouvez les utiliser pour restreindre l’accès à un emplacement sensible, tel qu’un .env fichier existant. Les chemins manquants et les liens symboliques nécessitent des soins supplémentaires, comme décrit dans Résolution des problèmes d’accès au système de fichiers.

Vérification de ce que la stratégie actuelle autorise

Étant donné que la stratégie est définie pour chaque répertoire et chaque commande, le moyen le plus simple de connaître les accès dont vous disposez est d’interroger Copilot CLI. Dans une session, saisissez :

/sandbox policy

/sandbox policy

Copilot imprime la politique effective pour votre répertoire actif. Les chemins d’accès sont regroupés par source, tels que les chemins configurés par l’utilisateur et les outils de développement, et par niveau d’accès. Le rapport inclut également les paramètres réseau et une section Capacités couvrant les paramètres tels que le contournement, le bac à sable MCP/LSP et l’authentification. Il s’agit du résultat de la combinaison de l’octroi automatique, de vos paramètres et des restrictions gérées, et pas seulement d’une copie de vos paramètres enregistrés.

Pour inspecter l’accès à l’outil développeur pour une commande particulière, ajoutez la commande après policy. Par exemple:

/sandbox policy npm install

/sandbox policy npm install

Cela ne s’exécute pas npm install. Il montre le niveau d’accès que la commande recevrait. L’aperçu ne crée aucun répertoire, y compris les chemins d’accès manquants ou refusés et les caches d’outils.

Voici quelques points à garder à l’esprit lorsque vous lisez le rapport :

• Elle reflète votre répertoire actif. Comme les autorisations sont détectées par répertoire, les mêmes paramètres peuvent correspondre à des chemins différents selon l’endroit où vous exécutez la commande.
• Consultez Notes pour les chemins d’accès configurés qui n’ont pas pu être inclus. Les autorisations en lecture/écriture ou en lecture seule manquantes sont omises. Sur Linux, les chemins refusés manquants sont omis de cet aperçu, mais la préparation du lancement les crée avant d’appliquer la stratégie. L’aperçu les conserve sur macOS et sur des hôtes Windows qui prennent en charge les chemins interdits.
• Si le sandboxing est désactivé, /sandbox policy vous l’indique au lieu d’afficher une politique, puisqu’aucune restriction ne s’applique.

Pour vérifier uniquement si le bac à sable est actuellement activé, utilisez /sandbox status. Pour plus d’informations sur ces commandes, consultez Utiliser le sandbox local.

Résolution des problèmes d’accès au système de fichiers

Si un chemin d’accès en lecture/écriture ou en lecture seule configuré n’existe pas, créez-le en dehors du sandbox avant de recommencer la commande. Un processus enfant en cours d’exécution conserve la stratégie reçue lors du lancement. La création ultérieure d’un chemin d’accès n’ajoute pas d’autorisation manquante à ce processus. Redémarrez un serveur exécuté depuis longtemps s’il a besoin de l’accès mis à jour.

Avant qu’un processus en bac à sable démarre, Copilot CLI crée les chemins d’accès interdits manquants et leurs répertoires parents sur votre ordinateur. Cela inclut les chemins d’accès destinés aux fichiers, de sorte qu’un .env manquant devient un répertoire. Les répertoires restent une fois le processus terminé.

Si un chemin non autorisé ne peut pas être préparé, le processus ne démarre pas. L’aperçu en lecture seule /sandbox policy n’effectue pas cette préparation, c’est pourquoi les chemins refusés absents y sont omis sur Linux. Pour la résolution des problèmes, consultez Utiliser le sandbox local.

Un lien symbolique à l’intérieur d’un répertoire autorisé ne garantit pas l’accès à une cible en dehors de ce répertoire. Si un message de refus nomme une telle cible, inspectez-le et accordez l’accès uniquement si cela est voulu. L’ajout d’un lien symbolique résolvable lui-même via /sandbox config ajoute également sa cible actuelle pour l’accès en lecture/écriture ou en lecture seule. Les règles de chemin définies manuellement et les octrois d’outils de développement détectés automatiquement n’ajoutent pas automatiquement cette cible.

Les chemins refusés sont gérés différemment des autorisations : l’interface CLI résout leur chemin d’accès écrit et leur cible actuelle. Sur Linux, un lien symbolique refusé protège sa cible, mais n’empêche pas de manière fiable le lien lui-même d’être remplacé. Préférez interdire l'accès au répertoire sensible réel plutôt que de recourir à une règle de liaison symbolique seule.

Pour les défaillances réseau, les restrictions gérées et les choix de contournement, consultez Résolution des problèmes liés aux commandes bloquées.

Personnalisation de la stratégie

Vous pouvez accorder des chemins d’accès en lecture/écriture ou en lecture seule, refuser des chemins d’accès et modifier d’autres comportements de système de fichiers, à partir de la /sandbox config boîte de dialogue ou dans votre fichier de paramètres. Après avoir apporté une modification, exécutez /sandbox policy pour confirmer le résultat. Pour obtenir des instructions pas à pas, consultez Configuration des paramètres de bac à sable local.

Stratégies gérées par l’entreprise

Si vous obtenez Copilot via une organisation détenue par l’entreprise, un administrateur peut appliquer une stratégie relative au système de fichiers via des paramètres gérés. Les paramètres managés agissent comme une base de référence restrictive : ils peuvent nécessiter le bac à sable, ajouter des chemins refusés et limiter les chemins que vous êtes autorisés à accorder. Lorsqu’un paramètre managé s’applique, la /sandbox config boîte de dialogue l’affiche sous la forme d’une valeur verrouillée (gérée) et /sandbox policy la reflète dans la stratégie résolue. Si la stratégie effective autorise le contournement du bac à sable, un utilisateur peut désactiver explicitement le bac à sable pour le reste de la session active, à partir d’une invite d’autorisation de contournement active ou en exécutant /sandbox disable. Cette désactivation pour cette session n’assouplit pas la stratégie enregistrée.

Contrairement à la plupart des configurations, où une seule source prévaut, la politique de sandbox est définie par toutes les sources en vigueur simultanément. Les paramètres gérés peuvent arriver simultanément par plusieurs canaux — gérés par le serveur, MDM et basés sur des fichiers — et ils se combinent entre eux, ainsi qu’avec vos propres paramètres, selon l’option la plus restrictive, au lieu qu’une source en remplace une autre : une option requise reste activée, les chemins interdits provenant de toutes les sources s’additionnent, et les chemins que vous êtes autorisé à accorder ne peuvent qu’être davantage restreints. Pour plus d’informations, consultez « Paramètres gérés par l’entreprise ».

Lectures complémentaires

• À propos des environnements isolés dans le cloud et locaux pour GitHub Copilot
• Utiliser le sandbox local
• Configuration des paramètres de bac à sable local