Mode sandbox de Copilot : le guide illustré
Le sandboxing local garde les commandes shell, les outils fichiers et les accès réseau de GitHub Copilot dans un périmètre au niveau de l'OS. Ce pas-à-pas suit la démo officielle de GitHub : activer via /sandbox, façonner la politique, désactiver, puis confier des sessions entières au cloud.
L'essentiel
- Le mode sandbox exécute les commandes shell, outils fichiers, serveurs MCP et LSP de Copilot dans une sandbox OS — fichiers, réseau et identifiants restreints, sans VM ni conteneur (Seatbelt sur macOS, bubblewrap sur Linux, ProcessContainer sur Windows).
- Dans l'application Copilot, le sandboxing est désactivé par défaut : ouvrez les réglages, choisissez le projet et activez "Sandbox new sessions". Dans le CLI, lancez /sandbox enable (expérimental).
- Lancez /sandbox pour régler la politique — onglets General, Filesystem et Network dans le CLI ; chemins en lecture/écriture supplémentaires, en lecture seule et refusés, plus les interrupteurs réseau et identifiants dans l'app. Les changements s'appliquent aux nouvelles sessions, ou via /restart-session.
- copilot --cloud déplace toute la session dans une sandbox cloud hébergée par GitHub ; vous la retrouvez via le lien github.com/copilot/tasks ou l'onglet Agents du dépôt. Les réglages locaux ne s'appliquent pas aux sessions cloud.
How to run GitHub Copilot in local and cloud sandboxes | demo
Chaîne:GitHub (official channel)1:31
GitHub Copilot Sandboxes are SO COOL
Chaîne:Gwyneth Peña-Siguenza1:50
Local sandboxing in the GitHub Copilot app (public preview)
Docs:github.blog/changelog
Configuring local sandboxing in the GitHub Copilot app
Docs:docs.github.com
About cloud and local sandboxes for GitHub Copilot
Docs:docs.github.com
Les images de ce guide proviennent de la démo sandbox officielle de GitHub — un enregistrement de terminal sans fioritures. Le texte est rédigé d'après la vidéo et la documentation GitHub ; les noms de réglages sont cités mot pour mot.
Les captures d'écran restent la propriété de leurs créateurs et sont utilisées avec attribution comme références visuelles. Le sandboxing local est en préversion publique — noms et comportements peuvent changer.
Le pas-à-pas : 12 étapes
1 · Activer le sandboxing local
- 1
Lancez Copilot dans votre dépôt
Démarrez le CLI Copilot dans votre projet. Le sandboxing est une fonctionnalité expérimentale du CLI — la bannière affiche le badge /experimental et la barre d'état porte l'indicateur de sandbox que vous apprendrez à lire.
Démarrage du CLI Copilot avec le badge /experimental et l'indicateur de sandbox dans la barre d'état.Voir à 0:08 - 2
Exécutez /sandbox enable
Tapez /sandbox et la palette de commandes ne propose que deux commutateurs : enable et disable. Choisissez enable — le sandboxing s'applique à cette session Copilot et à chaque commande shell qu'elle exécute.
![Copilot CLI slash-command menu listing /sandbox enable and /sandbox disable above the /sandbox [enable|disable] prompt hint](/images/guides/copilot-sandbox-tutorial/copilot-sandbox-tutorial-sandbox-enable-autocomplete.webp "Copilot CLI slash-command menu listing /sandbox enable and /sandbox disable above the /sandbox [enable|disable] prompt hint")
L'autocomplétion /sandbox proposant enable et disable.Voir à 0:24 - 3
Confirmez que la session est sous sandbox
Copilot affiche "Sandboxing has been enabled." et la barre d'état indique désormais "sandbox enabled" à côté de vos AI Credits. À partir de là, les commandes lancées par l'agent s'exécutent dans la sandbox.
"Sandboxing has been enabled." — la confirmation que vous attendez.Voir à 0:12
2 · Délimiter ce que la sandbox peut toucher
- 4
Ouvrez /sandbox pour façonner la politique
La commande /sandbox seule ouvre le panneau Configure sandbox, stocké dans settings.json sous `sandbox`. L'onglet General décide de ce qui tourne dedans : commandes shell, serveurs MCP, serveurs LSP et accès au trousseau macOS pour les helpers git et gh.
L'onglet General : shell, serveurs MCP et LSP, accès au trousseau.Voir à 0:30 - 5
Cadrer le système de fichiers
L'onglet Filesystem ajoute automatiquement votre répertoire de travail aux chemins en lecture/écriture et peut réinitialiser les permissions à la sortie de la sandbox. Les chemins d'outils comme ~/.nvm et ~/.npm sont montés en lecture seule — élargissez la liste si votre chaîne d'outils en a besoin.
Chemins en lecture seule pour nvm et npm, répertoire de travail inclus d'office.Voir à 0:32 - 6
Cadrer le réseau
L'onglet Network expose trois leviers : autoriser l'internet sortant, autoriser le réseau local et une liste Access par hôte. Si la tâche n'exige pas de téléchargements, commencez par resserrer ces options.
Politique réseau : sortant, réseau local et liste blanche par hôte.Voir à 0:36 - 7
Codez normalement — les commandes restent enfermées
Travaillez comme d'habitude. L'agent planifie, édite et exécute des commandes tandis que la barre d'état continue d'afficher "sandbox enabled". Si une commande réclame ce que la politique interdit, Copilot échoue bruyamment au lieu de s'échapper en silence.
Une migration SQLAlchemy planifiée et exécutée avec "sandbox enabled" dans la barre d'état.Voir à 0:20
3 · Travailler, désactiver, ou passer au cloud
- 8
Revenez en arrière avec /sandbox disable
Besoin d'une étape hors de la boîte ? /sandbox disable désactive le sandboxing — "Sandboxing has been disabled." apparaît et le badge sandbox disparaît de la barre d'état. Vous pouvez basculer dans un sens ou l'autre selon la tâche.
"Sandboxing has been disabled." — notez que le badge sandbox a quitté la barre d'état.Voir à 0:38 - 9
Lancez une sandbox cloud avec copilot --cloud
Pour les travaux plus lourds, démarrez Copilot avec le drapeau --cloud (la démo officielle l'associe à --yolo ; la doc de GitHub montre --cloud --experimental). La session tourne dans un environnement éphémère hébergé par GitHub plutôt que sur votre machine.
copilot --cloud --yolo — toute la session s'apprête à quitter votre portable.Voir à 0:50 - 10
Récupérez le lien de contrôle à distance
Une fois la session distante provisionnée, Copilot connecte le contrôle à distance et imprime une URL github.com/copilot/tasks/... — ctrl+e affiche un QR code. L'arborescence de travail vit dans /workspaces/<repo> dans la sandbox cloud.
Contrôle à distance connecté, avec l'URL de session et le raccourci QR code.Voir à 1:00 - 11
Laissez-le construire et tester dans le cloud
L'agent crée les fichiers, installe les dépendances et lance vos scripts de test dans la sandbox cloud — ici création de test_auth.py et exécution de la suite backend. Votre machine reste inactive pendant que les crédits défilent dans la barre d'état.
Tests en cours dans la sandbox cloud, 80.4 AI Credits dépensés à ce stade.Voir à 1:10 - 12
Suivez et reprenez depuis GitHub.com
La session apparaît dans l'onglet Agents du dépôt comme Remote CLI session — suivez la progression, envoyez des messages depuis le navigateur, puis reprenez plus tard avec copilot --resume, qui liste les sessions locales comme distantes.
L'onglet Agents de tailspin-toys suit la session cloud en direct.Voir à 1:14
Où vivent les réglages : application Copilot vs CLI Copilot
Le sandboxing local existe sur deux surfaces, et leurs réglages se configurent séparément — changer l'un ne change jamais l'autre.
- 1Application Copilot : désactivé par défaut. Ouvrez les réglages de l'app, sélectionnez le projet et sous "Sandbox" activez "Sandbox new sessions". La politique du projet décrit ce qu'une session sous sandbox peut demander.
- 2Politique de l'app : l'accès fichiers démarre en lecture/écriture pour l'espace de travail et le répertoire courant, avec des listes lecture/écriture supplémentaires, lecture seule et refusées ; le réseau couvre l'internet sortant et le réseau local ; les identifiants couvrent git et GitHub CLI.
- 3CLI Copilot : le sandboxing est expérimental — démarrez avec --experimental (ou lancez /experimental on), puis utilisez /sandbox enable, /sandbox disable, ou /sandbox seul pour ouvrir le panneau. Les réglages persistent dans settings.json sous `sandbox`.
- 4Les commandes slash dépendent du moment : /sandbox on ou /sandbox off pendant une session active ne vaut que pour cette session, tandis que, saisie avant le démarrage, elle change le défaut du projet. Utilisez /restart-session pour appliquer les changements sans perdre l'historique.
- 5Les sessions cloud forment un monde à part : les réglages locaux ne s'appliquent ni aux sandboxes cloud ni aux sessions sur hôte distant, et le sandboxing cloud doit être activé par un propriétaire d'organisation ou d'entreprise avant d'apparaître.
La démo CLI de ce guide montre le chemin le plus rapide ; l'interrupteur par projet de l'app devient le défaut durable une fois votre politique définie.
Quand la sandbox dit non : échec fermé par conception
La sandbox est conçue pour échouer fermée : si l'OS ne peut pas appliquer la politique demandée, la commande échoue au lieu de tourner sans sandbox.
- 1Plateforme ou politique non prise en charge : si la politique demandée ne peut pas être appliquée, le shell sous sandbox échoue avec une erreur — il ne retombe jamais silencieusement sur une exécution sans sandbox.
- 2"Sandbox unavailable" : l'app signale le problème et propose un bouton Retry sandbox une fois la cause corrigée.
- 3L'échappatoire : une invite "Run outside the sandbox?" peut proposer d'annuler, d'exécuter une fois hors sandbox ou de désactiver le sandboxing pour la session — "Re-enable sandbox" revient en arrière. Cela expire au redémarrage et ne modifie jamais les défauts du projet.
- 4Les propriétaires d'entreprise peuvent trancher : les paramètres gérés peuvent bloquer l'échappatoire hors sandbox, et l'application y aussi échoue fermée.
Notes de plateforme : macOS 15+ recommandé (Seatbelt) ; Linux exige bubblewrap 0.5.0+ dans le PATH ainsi que slirp4netns, util-linux 2.35+, iptables et /dev/net/tun ; Windows passe par le niveau BaseContainer de ProcessContainer — un chemin refusé non garanti fait échouer la commande avec un message unsupported-policy.