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.

À 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 ceux des serveurs de langage (LSP) peuvent également s’exécuter dans le bac à sable, de sorte que le système d’exploitation leur applique lui aussi la stratégie.
• 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.
• Sous-agents n’agissent pas directement ; ils orchestrent d’autres outils. 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 limite le processus uniquement à l’accès dont il a besoin et signifie que vous n’avez pas besoin de gérer vous-même ces emplacements communs.

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 sont accordés 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’applications de votre profil utilisateur sont également accordé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

Pour permettre aux installations et aux compilations de fonctionner dans la sandbox, Copilot autorise également l’accès aux caches et aux dépôts utilisés par les gestionnaires de paquets courants et les chaînes d’outils — en lecture seule pour la plupart des emplacements, et en lecture/écriture pour certains emplacements accessibles en écriture, tels que les caches de compilation et les magasins de dépendances des gestionnaires de paquets. Dans le rapport /sandbox policy, cela s’affiche sous la forme de accès aux outils de développement.

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. Quand ils le font, 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. Il s’agit d’un moyen utile de protéger un sous-dossier sensible.

Les chevauchements sont également résolus en votre faveur lorsqu’une autorisation accordée par commodité risquerait autrement de faire obstacle. 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 résout cela pour vous : une allocation qu’elle a ajoutée automatiquement (par exemple, un répertoire d’outils sur PATH) permet d’obtenir une allocation de lecture/écriture plus large qui la couvre déjà. Ainsi, un répertoire .venv, node_modules/.bin ou similaire, local au projet, reste accessible en écriture dans votre espace de travail.

Les règles que vous configurez sont toujours conservées. Si vous marquez un chemin en lecture seule, ou si vous lui refusez l’accès, cette décision reste valable même si le même chemin est découvert et autorisé automatiquement. Cela vous permet de protéger un emplacement sensible, par exemple, de refuser un .env fichier afin qu’aucune commande bac à sable ne puisse lire vos secrets.

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 affiche la stratégie appliquée à votre répertoire courant : les chemins en lecture/écriture, en lecture seule et refusés qui seraient réellement appliqués à une commande lancée depuis ici, ainsi que l’accès réseau et l’accès aux outils de développement en vigueur. Il s’agit du résultat résolu après que les allocations automatiques et vos propres paramètres ont été combinés et que tous les chevauchements ont été résolus, et pas seulement une copie de vos paramètres enregistrés.

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.
• Si un chemin d’accès que vous avez configuré n’existe pas sur le disque, il est laissé hors de la stratégie et indiqué dans une section Notes . Cela explique pourquoi une règle que vous avez ajoutée peut sembler n’avoir aucun effet.
• 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.

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 explicitement désactiver le bac à sable pour le reste de la session en cours depuis une invite active demandant l’autorisation de contourner le bac à sable. 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