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

Introduction

Lorsque vous activez le bac à sable local, Copilot pour 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 stratégie de système de fichiers : un ensemble de règles qui déterminent les chemins d’accès d’un processus ou d’une opération bac à sable (sandbox) peuvent lire, ce qu’il peut écrire et ce qu’il ne peut pas toucher 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 arriver à la stratégie et comment vérifier l’accès qu’il accorde dans un répertoire particulier.

Pour obtenir une vue d’ensemble du bac à sable local, notamment comment l’activer et l’désactiver, consultez À propos des bacs à sable cloud et locaux pour GitHub Copilot et Utilisation du 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 en tant que processus enfants en bac à sable (sandbox), de sorte que le système d’exploitation applique directement la stratégie. Les grep outils et glob , par exemple, exécutent ripgrep en tant que processus enfant en bac à sable(sandbox).
• Les processus de serveur de langage et MCP locaux peuvent également s’exécuter à l’intérieur du bac à sable. Par conséquent, le système d’exploitation applique également la stratégie.
• Les outils de lecture de fichiers et d’édition de fichiers intégrés s’exécutent dans le cadre de Copilot pour CLI lui-même plutôt qu’en tant que processus enfant en bac à sable. Ils vérifient la même stratégie de système de fichiers avant de lire ou d’écrire un fichier, mais parce que le bac à sable du système d’exploitation ne voit jamais ces opérations, la vérification est une protection logicielle uniquement plutôt qu’un système d’exploitation appliqué.
• Les serveurs MCP distants s’exécutent en dehors de votre machine. Par conséquent, il n’existe aucun processus enfant local pour bac à sable et la stratégie de système de fichiers ne les limite pas.
• Les sous-titres n’agissent pas directement ; ils orchestrent d’autres outils. Indique si la stratégie s’applique et comment dépend de l’outil qu’un sous-agent appelle.

Un processus bac à sable (sandbox) est donc limité par le système d’exploitation, tandis qu’une opération in-process applique la même stratégie dans les logiciels, c’est pourquoi cet article fait référence à un processus ou une opération en bac à sable plutôt qu’à des 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.

Étant donné que l’accès est refusé, sauf si accordé, Copilot doit accorder une commande tout ce dont il a besoin légitimement , vos fichiers projet, les outils qu’il exécute et les emplacements de prise en charge tels que les répertoires temporaires, tout en conservant tout le reste hors limites.

Création de la stratégie

Avant que chaque processus en bac à sable commence, Copilot pour CLI résout la stratégie effective pour ce processus à l’aide du répertoire de travail actuel, de l’environnement, des paramètres et des subventions 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 sur votre chemin d’accès

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. Votre PATH variable d’environnement répertorie ces répertoires et Copilot leur accorde un accès en lecture seule , ainsi que des répertoires nommés par des variables d’outil associées telles que GOPATH, CARGO_HOMEet PYTHONPATH. En lecture seule est le niveau approprié pour les outils externes : une commande doit s’exécuter git, et ne pas la modifier. 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 système et profil

Les emplacements système standard et le répertoire de votre profil utilisateur (accueil) sont accordés en lecture seule, afin que les commandes puissent lire les fichiers de configuration et les bibliothèques partagées sans pouvoir les modifier.

Caches du gestionnaire de package

Pour permettre aux installations et aux builds de fonctionner à l’intérieur du bac à sable, Copilot autorise également l’accès aux caches et registres utilisés par les gestionnaires de package courants et les chaînes d’outils, en lecture seule pour les registres et les chaînes d’outils, ainsi qu’en lecture/écriture pour les caches de build. Dans le /sandbox policy rapport, cela s’affiche en tant qu’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 empêcher les chemins d’accès spécifiques, vous pouvez ajouter des règles de refus. Consultez « Configuration des paramètres de bac à sable local ».

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

Étant donné que Copilot plusieurs emplacements sont accordés et que vous pouvez ajouter vos propres emplacements, les règles peuvent se chevaucher. Quand ils le font, le chemin plus spécifique gagne. Par exemple, s’il /project est accessible en écriture, mais que vous marquez /project/secrets en lecture seule, tout reste accessible en /project é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 subvention de commodité serait autrement obtenu de la façon. Considérez un projet Python avec un environnement virtuel local (.venv) qui apparaît sur votre PATH. Le traitement de ce répertoire comme un emplacement d’outil en lecture seule ordinaire le rendait en lecture seule, même s’il se trouve à l’intérieur de votre projet accessible en écriture, et une commande telle qu’elle pip install pourrait alors échouer lorsqu’elle a essayé 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à. Par conséquent, un répertoire local .venvou node_modules/.binsimilaire reste accessible en écriture dans le cadre de 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 le refusez, cette décision est prise même si le même chemin serait découvert et accordé 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 assemblée pour chaque répertoire et commande, la façon la plus simple de voir l’accès que vous avez est de demander Copilot pour CLI. Dans une session, entrez :

/sandbox policy

/sandbox policy

Copilot imprime la stratégie effective pour votre répertoire actif : les chemins d’accès en lecture/écriture, en lecture seule et refusés qu’une commande lancée à partir d’ici recevrait réellement, avec 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. Étant donné que les subventions sont découvertes par répertoire, les mêmes paramètres peuvent être résolus en différents chemins en fonction de l’emplacement d’exécution.
• 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 bac à sable (sandboxing) est désactivé, /sandbox policy vous le indique au lieu d’imprimer une stratégie, car aucune restriction n’est en vigueur.

Pour vérifier uniquement si le bac à sable est actuellement activé, utilisez /sandbox status. Pour plus d’informations sur ces commandes, consultez Utilisation du bac à sable 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 passez Copilot par une organisation appartenant à l’entreprise, un administrateur peut appliquer une stratégie de système de fichiers via des paramètres managés. Les paramètres managés agissent comme une base de référence que vous ne pouvez pas relâcher : ils peuvent nécessiter un 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.

Contrairement à la plupart des paramètres, où une seule source gagne, la stratégie de bac à sable est composée de chaque source en vigueur à la fois. Les paramètres managés peuvent arriver simultanément via plusieurs canaux (gérés par le serveur, GPM et basés sur des fichiers), et ils se combinent les uns avec les autres, et avec vos propres paramètres, dans la direction la plus restrictive plutôt qu’une source substituant une autre : une bascule requise reste sur, les chemins refusés de toutes les sources s’ajoutent, et les chemins que vous êtes autorisés à accorder ne peuvent être limités que. Pour plus d’informations, consultez « Paramètres gérés par l’entreprise ».

Lectures complémentaires

• À propos des bacs à sable cloud et locaux pour GitHub Copilot
• Utilisation du bac à sable local
• Configuration des paramètres de bac à sable local