Sandbox local de GitHub Copilot App : configuration et tests

Vous activez le sandbox, mais une session déjà ouverte conserve ses anciens droits, ou l’agent redemande sans cesse un accès pour installer des dépendances, joindre un serveur local ou pousser une branche. Le problème vient généralement de l’interaction entre la valeur par défaut du projet, la dérogation de session et les contrôles distincts des fichiers, du réseau et des identifiants.

À la fin de ce guide, vous saurez choisir une politique de départ pour un dépôt local ou un worktree, appliquer les changements à la bonne session et vérifier les frontières avec des données factices. Le chemin le plus court est : confirmer le type de session → activer Sandbox new sessions → réduire les trois domaines → créer ou redémarrer la session → effectuer des tests sûrs.

GitHub a annoncé cette fonction le 23 septembre 2026. Elle reste en préversion publique, donc l’interface et le comportement peuvent évoluer. Retenez trois limites : le sandbox local est désactivé par défaut, la politique se règle par projet et, si l’hôte ne peut pas l’appliquer, le shell échoue au lieu d’exécuter silencieusement la commande sans protection.

Commencez par confirmer que votre session est concernée

La politique du projet s’applique uniquement aux sessions de dépôt local et de worktree local. Les sandboxes cloud, hôtes distants et GitHub Copilot CLI suivent d’autres mécanismes ; vérifiez donc le tableau avant de modifier un réglage que la session cible ne lira pas.

Type de session	Couverte ?	Limite à retenir
Session de dépôt local	Oui	Utilise les paramètres de sandbox du projet courant
Session dans un worktree local	Oui	Un worktree sépare les branches et les fichiers, mais ne limite pas l’accès au reste de la machine ; le sandbox fournit cette frontière d’autorisation
Session dans un sandbox cloud	Non	Utilise l’isolation propre à la session cloud
Session exécutée sur un hôte distant	Non	La politique du projet local ne s’applique pas à l’hôte distant
GitHub Copilot CLI	Configuration séparée	Les paramètres de sandbox de Copilot app et de Copilot CLI ne se remplacent pas mutuellement

Des paramètres gérés par l’entreprise peuvent rendre la politique effective plus restrictive que celle demandée dans les paramètres du projet. La page du projet décrit donc les droits sollicités par l’application, pas nécessairement l’accès maximal que l’organisation autorisera.

Comment activer le sandbox pour les nouvelles sessions

Pour que les prochaines sessions locales héritent de la politique, activez Sandbox new sessions puis créez une nouvelle session ; le commutateur ne modifie pas une session déjà ouverte. Procédez ainsi :

1. Ouvrez les paramètres de GitHub Copilot app.
2. Sélectionnez le projet à configurer.
3. Repérez la section Sandbox.
4. Activez Sandbox new sessions.
5. Démarrez une nouvelle session locale.

Le commutateur n’agit que sur les sessions créées ensuite. Il ne modifie pas une session déjà en cours. De même, une modification ultérieure des règles de fichiers, de réseau ou d’identifiants ne s’applique qu’aux nouvelles sessions, ou après redémarrage de la session actuelle.

Pour recharger la politique sans perdre l’historique de la conversation, saisissez /restart-session dans la session existante.

GitHub recommande de commencer avec la politique par défaut pour la plupart des projets. Elle autorise des tâches courantes comme l’installation de dépendances, la connexion à un serveur de développement local, le push d’une branche et la création d’une pull request. Resserrez-la si le projet côtoie des dossiers sensibles, n’a pas besoin du réseau ou ne doit pas utiliser vos identifiants.

Comment limiter séparément fichiers, réseau et identifiants

Ces trois contrôles sont indépendants : limiter les fichiers ne désactive pas les identifiants, et couper les identifiants ne protège pas un dossier sensible encore lisible. Resserrez chaque domaine selon la tâche plutôt que de tout désactiver.

1. Système de fichiers : décider ce qui peut être lu et modifié

Commencez par le périmètre minimal : conservez la lecture-écriture dans l’espace de travail et n’ajoutez d’autres chemins que si la tâche l’exige. Par défaut, la session peut lire et écrire dans son espace de travail et son répertoire courant ; trois listes complètent ce réglage :

• Additional read/write : dossiers supplémentaires que les outils exécutés par l’agent peuvent lire et modifier.
• Additional read-only : dossiers supplémentaires qu’ils peuvent lire, mais pas modifier.
• Denied : dossiers auxquels ils ne peuvent pas accéder.

Un dossier refusé plus précis reste interdit même si un dossier parent plus large bénéficie d’un accès en lecture ou en écriture. Il vaut mieux autoriser le chemin minimal nécessaire que d’ouvrir tout le répertoire personnel puis de compter sur une longue liste d’exceptions.

Sous Windows, une limite d’application mérite une attention particulière. Vous pouvez enregistrer un chemin refusé dans les paramètres du projet, mais si les capacités actives du sandbox Windows ne garantissent pas ce refus, la commande échoue avec un message unsupported-policy. Elle ne continue pas avec le chemin exposé et ne désactive pas automatiquement le sandbox.

2. Réseau : distinguer Internet du réseau local

Si la tâche installe des dépendances ou utilise un serveur local, ne bloquez pas automatiquement les deux voies ; décidez séparément si Internet sortant et le réseau local sont nécessaires. Par défaut, la session peut atteindre les deux, et vous pouvez contrôler :

• Outbound internet : accès à GitHub, aux registres de paquets et aux autres services Internet.
• Local network : connexions de boucle locale et de réseau local, y compris les serveurs de développement locaux.

Les restrictions réseau peuvent bloquer l’installation de dépendances, les appels d’API, les serveurs de prévisualisation et tout outil nécessitant une connexion. Considérez donc l’interdiction du réseau comme un compromis fonctionnel, et non comme un bouton sans conséquence.

Linux présente une limitation spécifique : le sandbox ne peut pas contrôler séparément l’accès au réseau local pour les processus lancés, tels que les commandes shell et les serveurs MCP ou LSP locaux. Le réglage continue toutefois de s’appliquer aux opérations effectuées dans le processus, par exemple les requêtes Web et les connexions MCP distantes. Sous Linux, vérifiez les deux chemins au lieu de ne tester qu’un seul type d’opération.

3. Identifiants : contrôler Git et GitHub CLI séparément

Pour une revue de code ou une analyse hors ligne, désactivez d’abord les identifiants Git et GitHub CLI ; activez-les seulement si vous devez pousser une branche ou créer une pull request. Par défaut, les opérations authentifiées sont disponibles et vous pouvez désactiver :

• Git credentials : identifiants utilisés pour les opérations Git HTTPS authentifiées.
• GitHub CLI credentials : authentification utilisée par GitHub CLI.

Leur désactivation peut empêcher des actions comme pousser une branche ou créer une pull request. Les règles de fichiers et d’identifiants forment deux frontières distinctes : même sans identifiants, protégez par des règles de système de fichiers les dossiers contenant des clés, des configurations ou d’autres données sensibles.

Quand modifier le projet, la session courante ou une seule opération

Modifiez le projet lorsque les futures sessions doivent hériter de la règle ; utilisez /sandbox on ou /sandbox off pour la session courante ; après un changement de projet, lancez /restart-session si la session active doit le recharger.

Action	Moment d’application	Effet sur les autres sessions
Modifier les paramètres Sandbox du projet	Nouvelles sessions ou session redémarrée	Modifie la valeur par défaut héritée par les futures sessions de ce projet
Saisir /sandbox on dans une session locale active	Immédiatement, comme dérogation persistante pour cette session	Ne change pas la valeur par défaut du projet pour les autres sessions
Saisir /sandbox off dans une session locale active	Désactive immédiatement le sandbox pour cette session	Ne change pas les autres sessions ; les commandes obtiennent alors le même accès aux fichiers, au réseau et aux identifiants que votre compte utilisateur
Saisir /sandbox on ou /sandbox off avant le démarrage d’une session	Modifie la valeur par défaut du projet héritée par les nouvelles sessions	Affecte ensuite les sessions démarrées depuis cette valeur par défaut
Saisir /restart-session	Redémarre la session courante, conserve son historique et recharge la politique	Ne modifie pas en lui-même la politique du projet

Lorsqu’un outil a besoin d’un accès interdit par la politique, l’application peut afficher Run outside the sandbox?. Selon la politique effective, vous pouvez annuler, exécuter cette opération une seule fois hors sandbox ou désactiver le sandbox pour le reste de la session courante. Un propriétaire d’entreprise peut interdire aux utilisateurs d’exécuter des outils hors sandbox.

La désactivation via cette invite ne réécrit ni la valeur par défaut du projet ni la dérogation persistante de la session. Cet état temporaire prend fin lors du redémarrage ou du rattachement de la session. Après l’affichage de Sandbox off for this session, utilisez Re-enable sandbox pour le réactiver.

La séquence de décision la plus sûre consiste d’abord à annuler et à comprendre pourquoi la commande réclame davantage d’accès. Si ce besoin est récurrent, modifiez précisément la politique du projet puis redémarrez. N’autorisez une exécution unique hors sandbox qu’après avoir vérifié la commande, ses arguments et ses effets. Pour un dépôt inconnu ou une commande construite dynamiquement à partir d’une instruction, évitez de désactiver le sandbox pour toute la session par simple commodité.

Si l’hôte ne peut pas appliquer la politique, la commande s’arrête

Si le système d’exploitation ne peut pas imposer une règle, le résultat sûr est l’échec de la commande, pas une exécution automatique hors sandbox.

GitHub Copilot app accepte les paramètres de sandbox avant de savoir si le système d’exploitation peut tous les faire respecter. La compatibilité est vérifiée au démarrage du premier shell placé en sandbox.

Si l’hôte ne peut pas appliquer la politique demandée :

• le shell affiche un message unsupported-platform ou unsupported-policy ;
• la commande ne continue pas sans sandbox ;
• si l’application affiche Sandbox unavailable, corrigez le problème signalé puis sélectionnez Retry sandbox.

Il s’agit d’un échec fermé, et non d’une exécution au mieux. La réussite de l’enregistrement des paramètres ne prouve donc pas que la politique est active sur la machine. Lancez au moins un shell en sandbox, vérifiez qu’aucun message d’incompatibilité n’apparaît, puis effectuez un contrôle minimal.

Comment vérifier la politique avec des données factices

GitHub décrit le comportement attendu, mais seul un test sur votre machine confirme que cette combinaison de système et de règles fonctionne. La procédure utilise des dossiers jetables et des fichiers factices, sans toucher à de vraies clés ni à une configuration de production.

Créez hors de l’espace de travail des dossiers de test jetables et placez-y uniquement des fichiers factices. Ne testez pas avec de vraies clés SSH, des identifiants cloud ou une configuration de production.

Vérification	Procédure sûre	Comportement attendu de la politique
Héritage par une nouvelle session	Activez Sandbox new sessions, puis créez une nouvelle session locale	La nouvelle session utilise la politique du projet ; l’ancienne ne change pas automatiquement
Application d’une modification	Changez une règle puis saisissez /restart-session	La session redémarre, conserve l’historique et recharge la politique
Dossier en lecture seule	Ajoutez un dossier jetable à Additional read-only, lisez un fichier factice puis tentez de créer un fichier de test	La lecture doit fonctionner ; la modification doit être bloquée
Dossier interdit	Ajoutez un autre dossier jetable à Denied, puis tentez de lister ou lire un fichier factice	L’accès doit être bloqué même si un chemin parent plus large est autorisé
Accès Internet	Désactivez Outbound internet et effectuez un contrôle de connexion inoffensif	La connexion externe doit échouer ; réactivez-la et comparez
Réseau local	Désactivez Local network et connectez-vous à un service local de test jetable	Le résultat doit suivre les capacités de la plateforme ; tenez compte de la limite Linux pour les processus lancés
Identifiants Git	Désactivez Git credentials et effectuez un contrôle d’authentification non destructif dans un dépôt de test	Les opérations Git HTTPS authentifiées peuvent devenir indisponibles
Identifiants GitHub CLI	Désactivez GitHub CLI credentials et effectuez un contrôle non destructif, par exemple gh auth status	GitHub CLI ne doit plus recevoir la capacité d’authentification précédente ; le message exact peut varier
Échec fermé	Si unsupported-platform ou unsupported-policy apparaît, vérifiez qu’un fichier factice ciblé n’a pas été créé	La commande ne doit pas continuer sans sandbox ni produire l’effet prévu

Supprimez ensuite les dossiers de test et rétablissez seulement les autorisations minimales dont le projet a réellement besoin. Ne tentez pas de prouver une règle de refus en visant un véritable dossier sensible.

Quelle politique de départ choisir selon la tâche

Le développement quotidien, un dépôt inconnu et une analyse hors ligne ne doivent pas partager la même politique. Gardez les capacités nécessaires au travail normal, commencez plus strictement avec du code inconnu et coupez d’abord réseau et identifiants en mode hors ligne.

Développement quotidien

Activez le sandbox, conservez les capacités réseau et d’identification par défaut, n’ajoutez que les dossiers externes indispensables et refusez explicitement les répertoires sensibles voisins. Ce profil convient aux tâches courantes qui installent des dépendances, exécutent des services locaux, poussent des branches et ouvrent des pull requests.

Revue d’un dépôt inconnu

Limitez la lecture et l’écriture à l’espace de travail, placez les documents de référence supplémentaires en lecture seule, désactivez par défaut les identifiants Git et GitHub CLI et gardez l’accès Internet sortant coupé tant que l’origine des dépendances n’est pas comprise. Si un accès temporaire est nécessaire, ouvrez une capacité précise plutôt que d’utiliser immédiatement /sandbox off.

Analyse locale hors ligne

Désactivez Internet sortant et les identifiants inutiles, en ne conservant que les accès fichiers nécessaires. Si l’isolation du réseau local compte aussi, vérifiez séparément le comportement des processus lancés sous Linux au lieu de supposer qu’un seul commutateur de l’interface contrôle tous les processus de la même manière.

Ces profils ne sont pas des préréglages nommés par GitHub. Ce sont des points de départ construits à partir des dimensions d’autorisation exposées par GitHub. Adaptez la politique finale au dépôt, au système d’exploitation, aux règles de l’entreprise et à la tâche réelle.

Erreurs qui rendent la politique inefficace ou trop permissive

Les erreurs les plus fréquentes consistent à confondre « paramètres enregistrés » et « politique appliquée », ou à désactiver tout le sandbox après le premier refus. Les sept cas ci-dessous faussent le test ou accordent trop de droits.

1. Prendre un worktree pour une frontière de sécurité. Il sépare les branches et les fichiers concurrents, mais n’empêche pas les commandes d’atteindre d’autres emplacements de la machine.
2. Modifier la politique puis continuer les tests dans une ancienne session. Les changements de projet ne sont pas rétroactifs ; démarrez une nouvelle session ou utilisez /restart-session.
3. Supposer que l’application et le CLI partagent un même sandbox. Ils se configurent séparément.
4. Prendre un enregistrement réussi pour une preuve de compatibilité de l’hôte. L’application ne vérifie la possibilité d’appliquer la politique qu’au démarrage du premier shell en sandbox.
5. Sous-estimer la portée de /sandbox off. Les commandes exécutées par l’agent reçoivent alors le même périmètre d’accès que votre compte utilisateur.
6. Supposer un comportement réseau identique sur toutes les plateformes. Linux possède une limite documentée pour le contrôle du réseau local des processus lancés.
7. Utiliser une dérogation large à chaque refus d’accès. Il est généralement plus sûr de confirmer le besoin, d’apporter la plus petite modification possible à la politique et de redémarrer la session.

Que faire maintenant

Commencez par confirmer que vous utilisez une session de dépôt local ou de worktree local, puis activez Sandbox new sessions. Pour le développement quotidien, partez de la politique par défaut et ne gardez que les dossiers, connexions et identifiants nécessaires ; pour du code inconnu ou une analyse hors ligne, partez du profil le plus strict et ouvrez une capacité à la fois.

Après une modification du projet, créez une nouvelle session ou exécutez /restart-session, puis vérifiez les limites de lecture seule, de refus, de réseau et d’identifiants avec des données jetables. Si unsupported-platform, unsupported-policy ou Sandbox unavailable apparaît, corrigez l’incompatibilité au lieu d’utiliser /sandbox off et de prendre une exécution non isolée pour un test réussi.

Références officielles

Consultez ces pages GitHub avant et après la configuration pour vérifier l’interface, le périmètre et le comportement d’échec actuels.

• Configurer le sandbox local dans GitHub Copilot app
• Local sandboxing in the GitHub Copilot app — GitHub Changelog, 23 septembre 2026