VS Code 1.141 : comment sandboxer Copilot et les agents IA locaux

Disponible en version stable depuis le 7 octobre 2026, VS Code 1.141 introduit une évolution concrète dans le travail avec les agents de développement : les outils du Copilot Agent Host peuvent désormais être exécutés dans une sandbox sur Windows, macOS et Linux. Elle contrôle les fichiers et ressources réseau accessibles lorsqu'un agent lance des commandes, au lieu de compter uniquement sur un message de confirmation.

Le même jour, GitHub a annoncé la disponibilité générale du sandboxing local Copilot dans Copilot CLI, l'application Copilot et les sessions VS Code utilisant Agent Host, sans coût additionnel dans Copilot. Attention cependant : les prérequis diffèrent selon les plateformes, et le support Windows est encore décrit comme expérimental dans la documentation VS Code. Ce guide propose une configuration testable, du dépôt courant aux fichiers sensibles, puis montre comment reprendre plusieurs discussions Copilot et Codex.

Pourquoi cette sandbox change le travail avec Copilot

Un agent peut installer des dépendances, explorer un dépôt, modifier des fichiers ou exécuter un script. Sans politique explicite, ces actions peuvent accéder à des ressources plus larges que nécessaire. Dans VS Code 1.141, la sandbox du Copilot Agent Host combine des restrictions du système d'exploitation et des contrôles propres à l'hôte de l'agent. On peut distinguer les chemins accessibles en lecture/écriture, en lecture seule et interdits, tout en gérant le réseau, l'accès à Git, aux identifiants GitHub CLI et, lorsqu'ils sont gérés par Agent Host, aux serveurs MCP et serveurs de langage.

Approbations et sandbox ne sont pas équivalentes : l'approbation décide si l'action peut démarrer ; la sandbox détermine les ressources qu'elle peut utiliser. Dans une session distante, ces limitations s'appliquent sur l'hôte qui exécute les outils, et les chemins configurés sont ceux de cet hôte, pas nécessairement ceux de votre ordinateur local.

Vérifier les prérequis avant de commencer

• VS Code : installer la stable 1.141 ou une version ultérieure, ouvrir le dépôt, et choisir une session utilisant le Copilot Agent Host et ses outils intégrés. Les anciens modes Local et terminaux personnalisés n'utilisent pas toujours les mêmes paramètres.
• macOS : aucun composant supplémentaire n'est requis pour l'Agent Host selon Microsoft.
• Linux ou WSL2 : installer bubblewrap et socat sur l'hôte d'exécution. Sur Debian ou Ubuntu : sudo apt-get install bubblewrap socat. WSL1 n'est pas compatible.
• Windows : pour l'Agent Host, Microsoft mentionne les mises à jour KB5124008 (Windows 11 24H2/25H2) et KB5124012 (26H1). Le support Windows reste expérimental ; les conditions indiquées pour Copilot CLI ne sont pas nécessairement identiques.

Ce tutoriel concerne la sandbox des opérations exécutées par Copilot Agent Host. L'import d'une conversation Codex dans l'interface ne signifie pas que son exécution est automatiquement régie par cette même politique.

Étape 1 — Activer la sandbox et vérifier sa politique

1. Dans VS Code, ouvrir les paramètres JSON de l'hôte qui exécutera Agent Host.
2. Ajouter le paramètre "chat.agent.sandbox.enabled": "on" ; les valeurs acceptées sont on et off, et non des booléens.
3. Créer une nouvelle session Copilot Agent Host. Dans une session ouverte, le menu Permissions → Sandboxing for terminal permet également d'activer la protection pour cette session.
4. Envoyer /sandbox policy dans le chat Agent Host. Le rapport ouvert par VS Code précise si la sandbox est active, quel système l'applique, et quelles autorisations de fichiers et de réseau sont effectives.

Le répertoire de travail courant dispose automatiquement des autorisations de lecture et écriture. Il faut donc ouvrir uniquement le dépôt concerné, plutôt que de donner accès à tout le répertoire utilisateur. Le rapport de politique permet de repérer les concessions implicites et les éventuelles règles de l'organisation.

Étape 2 — Autoriser le dépôt, interdire les secrets et couper Internet

Voici un exemple volontairement restrictif à placer dans le settings.json de l'hôte d'exécution. Il suppose que le dossier /Users/dev/projets/mon-app est ouvert comme répertoire de travail. Remplacez tous les chemins absolus par les vôtres : les exemples ci-dessous sont au format macOS et doivent être adaptés à Linux ou Windows.

{
  "chat.agent.sandbox.enabled": "on",
  "chat.agent.sandbox.fileSystem.userConfiguredPaths": {
    "deniedPaths": [
      "/Users/dev/.ssh",
      "/Users/dev/projets/mon-app/.env",
      "/Users/dev/projets/mon-app/.sandbox-demo-secret"
    ]
  },
  "chat.agent.sandbox.fileSystem.allowDevToolAccess": false,
  "chat.agent.sandbox.network.allowNetwork": false,
  "chat.agent.sandbox.network.allowLocalNetwork": false,
  "chat.agent.sandbox.credentials.authenticategit": false,
  "chat.agent.sandbox.credentials.authenticategh": false,
  "chat.agent.sandbox.allowUnsandboxedCommands": false
}

Dans cette configuration, le dépôt courant demeure accessible pour les modifications de code, mais .ssh, .env et un fichier de test factice sont explicitement interdits. Le paramètre allowDevToolAccess: false retire les autorisations implicites sur certains outils, caches et configurations de développement ; il peut donc empêcher des installations ou compilations. N'ajoutez ensuite que les chemins strictement nécessaires, après contrôle dans /sandbox policy.

Le réseau sortant et le réseau local sont désactivés ; les mécanismes d'accès aux identifiants Git et à gh sont également coupés. Enfin, allowUnsandboxedCommands: false empêche l'agent de proposer une exécution hors sandbox lorsqu'une commande est refusée. Avec la valeur par défaut true, un tel contournement peut être demandé avec confirmation : il faut en comprendre les conséquences avant de l'autoriser.

Étape 3 — Tester une commande autorisée et deux refus

Pour vérifier le résultat sans risquer d'exposer une vraie clé, créer manuellement dans le dépôt un fichier .sandbox-demo-secret ne contenant qu'un texte fictif, et s'assurer que son chemin figure bien dans deniedPaths. Ensuite, depuis le chat de l'agent — pas depuis le terminal classique de VS Code — demander les actions suivantes :

1. Écriture autorisée : créer .sandbox-test-ok.txt à la racine du dépôt. L'opération devrait réussir, car le dossier de travail dispose d'un accès en écriture.
2. Lecture interdite : essayer de lire .sandbox-demo-secret. L'accès devrait être refusé, sans afficher le contenu fictif.
3. Connexion interdite : demander curl -I https://example.com. Avec allowNetwork: false, la requête sortante devrait échouer.
4. Vérification : relancer /sandbox policy et comparer les règles annoncées au comportement observé. Si un accès interdit fonctionne, arrêter le test et vérifier l'hôte, le moteur utilisé et ses paramètres.

Le texte exact des erreurs varie selon la plateforme. L'objectif est d'obtenir un refus réel, pas un message particulier. Une fois les essais terminés, supprimer les fichiers de test. Évitez d'utiliser de vraies données sensibles comme appâts.

Étape 4 — Autoriser seulement les services indispensables

Un build peut avoir besoin du registre npm ou d'une API GitHub. Si le réseau doit être réactivé, mieux vaut définir des destinations explicites que rouvrir toutes les connexions. Exemple de remplacement des clés réseau précédentes :

{
  "chat.agent.sandbox.network.allowNetwork": true,
  "chat.agent.sandbox.network.allowedDomains": [
    "registry.npmjs.org",
    "api.github.com"
  ]
}

Ces domaines sont des exemples : vérifiez ceux dont le projet a réellement besoin. L'accès au réseau local reste une autorisation distincte. Attention : sous Windows, un proxy, un filtrage par nom d'hôte ou un masquage d'identifiants peut exiger l'activation du réseau local, ce qui élargit la surface d'accès. Vérifiez les limitations de votre plateforme avant de l'adopter.

Pour les serveurs lancés ou gérés par Agent Host, les réglages chat.agent.sandbox.mcpServers et chat.agent.sandbox.lspServers permettent de maintenir le confinement lorsqu'il est disponible. Un serveur MCP lancé indépendamment de l'Agent Host n'entre pas automatiquement dans ce périmètre.

Étape 5 — Reprendre Copilot CLI, l'application Copilot et Codex

VS Code 1.141 améliore également le suivi de plusieurs agents. La fenêtre Agents détecte les conversations externes créées dans Copilot CLI et l'application Copilot dès leur activité, puis permet de les ouvrir et de les poursuivre. Elle peut aussi reprendre des échanges commencés dans Codex CLI ou l'application ChatGPT/Codex locale, avec leur historique, lorsque Codex est activé.

1. Ouvrir la fenêtre Agents et afficher les conversations externes avec le filtre Created Externally. Affiner au besoin avec les filtres Created In, Harness et Environment.
2. Ouvrir une session existante pour en reprendre le contexte sans créer une nouvelle conversation.
3. Si une discussion Codex indique This chat is open in another app, quitter complètement l'application ChatGPT ou la session Codex CLI qui la détient, puis cliquer sur Retry. Une seule application peut envoyer des messages dans une même conversation à la fois.
4. Glisser les conversations dans la grille de sessions pour les disposer côte à côte et comparer un refactoring, des tests et une analyse de sécurité.

Les politiques ne sont pas universelles : Copilot CLI dispose de sa propre commande /sandbox, l'application Copilot possède des réglages par projet et VS Code Agent Host utilise ses paramètres d'hôte. Changer les droits dans une application ne configure pas automatiquement les autres. Reprendre un chat Codex dans VS Code ne garantit pas non plus que ses commandes respectent la sandbox du moteur Copilot.

Ce que cette sandbox ne garantit pas

Microsoft rappelle que la sandbox ajoute une couche de protection mais ne constitue pas, à elle seule, une frontière de sécurité complète. Les processus s'exécutent toujours sur l'hôte, sous le compte de l'utilisateur. Certaines restrictions reposent sur des contrôles intégrés à l'agent plutôt que sur une isolation purement système. Cela ne remplace ni les mises à jour, ni une gestion stricte des identifiants, ni la revue des commandes et des modifications.

La GA annoncée par GitHub le 7 octobre 2026 représente une étape importante, mais ne gomme pas les prérequis systèmes, les limites expérimentales sous Windows et les particularités des politiques d'entreprise. Pour exécuter des dépendances très peu fiables, une VM ou un Dev Container peut rester nécessaire en complément de la sandbox locale.