VS Code 1.141 met ses agents IA en cage : le sandbox arrive sur Windows, macOS et Linux

VS Code n’est plus seulement un éditeur, c’est devenu une salle de contrôle pour robots développeurs

La transformation est désormais difficile à manquer. Dans les notes de version officielles de Visual Studio Code 1.141, Microsoft parle autant de sessions d’agents, de shells lancés en arrière-plan, de worktrees autonomes ou de connexions entre différentes applications que de fonctions d’édition traditionnelles. VS Code sait maintenant afficher plusieurs agents côte à côte dans une grille, suivre les terminaux qu’ils laissent tourner, nettoyer automatiquement les worktrees accumulés par d’anciennes sessions et reprendre des conversations commencées dans d’autres outils. Une discussion lancée avec Codex dans l’application ChatGPT ou le CLI peut par exemple apparaître dans la fenêtre Agents de VS Code sur la même machine et continuer avec son historique intact.

Cette évolution repose largement sur l’Agent Host, un processus séparé de l’éditeur introduit cet été. L’architecture publiée par l’équipe VS Code explique que cet Agent Host devient propriétaire des sessions tandis que les fenêtres VS Code ne sont plus que des clients pouvant se connecter ou se déconnecter. Une tâche peut donc continuer alors que la fenêtre qui l’a lancée est fermée, être observée depuis plusieurs interfaces ou fonctionner sur une machine distante. Le protocole AHP, pour Agent Host Protocol, est lui-même conçu pour rester indépendant du moteur : Copilot possède son harness, Claude peut utiliser le sien, tandis que le protocole standardise surtout la manière dont les interfaces voient sessions, terminaux et changements. On est assez loin du petit assistant qui terminait simplement une ligne Python grisée dans l’éditeur.

Forcément, laisser un agent lancer un shell complet pose quelques questions

Un agent capable de lire votre dépôt puis d’exécuter pytest est pratique. Un agent capable de lancer n’importe quelle commande sous votre compte utilisateur l’est également… jusqu’à ce qu’une instruction imprévue lui demande de regarder ailleurs. Le risque ne vient d’ailleurs pas uniquement d’une « hallucination » classique du modèle. Microsoft cite explicitement les prompt injections, dépendances non fiables et serveurs d’outils locaux parmi les menaces que le sandbox doit contribuer à contenir. La documentation de sécurité de VS Code recommande en parallèle d’utiliser Workspace Trust pour les projets non fiables, de vérifier les modifications avant intégration et de traiter les serveurs MCP comme de véritables composants exécutables plutôt que comme de simples extensions de chat.

La distinction entre approbation et sandbox est particulièrement importante. Une approbation répond à la question « faut-il demander à l’humain avant de lancer cette commande ? ». Le sandbox répond à « même si cette commande est lancée, jusqu’où peut-elle aller ? ». Vous pouvez donc autoriser un agent à travailler assez librement tout en lui interdisant de sortir du dossier du projet ou de contacter n’importe quel domaine. À l’inverse, cliquer religieusement sur « Autoriser » à chaque commande ne protège pas beaucoup si la commande autorisée possède ensuite accès à tout votre $HOME, à vos clés et au réseau. Microsoft recommande d’ailleurs le sandbox comme couche de protection complémentaire plutôt que de compter uniquement sur l’analyse des commandes et les fenêtres de confirmation.

macOS utilise Seatbelt, Linux bubblewrap, Windows sort ses conteneurs

Le plus intéressant est que Microsoft n’a pas simplement ajouté une fonction abstraite appelée « sandbox » dans l’interface. La documentation technique du sandbox Agent Host détaille des implémentations différentes selon l’OS. Sur macOS, VS Code s’appuie sur le framework de sandboxing intégré d’Apple, souvent appelé Seatbelt. Sous Linux et WSL2, l’isolation du système de fichiers passe par bubblewrap tandis que socat participe au contrôle réseau. Sur Windows, Microsoft utilise ses conteneurs de processus MXC pour appliquer les restrictions aux commandes et à leurs processus enfants.

Linux demande donc actuellement d’installer bubblewrap et socat — deux paquets présents dans les dépôts des grandes distributions — tandis que Windows exige certaines mises à jour de sécurité publiées le 8 septembre 2026. Windows 11 24H2 et 25H2 doivent notamment disposer de KB5124008, et Windows 11 26H1 de KB5124012. WSL1 reste exclu parce qu’il ne fournit pas les fonctions du noyau nécessaires à bubblewrap ; WSL2 est pris en charge. Il faut également garder en tête que la disponibilité générale de VS Code 1.141 ne signifie pas que tous ces mécanismes sont considérés comme définitifs : la documentation classe encore le sandbox en Preview sur macOS, Linux et WSL2, et Experimental sur Windows.

Le détail à ne surtout pas rater : le sandbox est désactivé par défaut

Voilà probablement la petite astérisque que beaucoup de titres oublieront. VS Code 1.141 apporte le sandbox multiplateforme dans sa version stable, mais la configuration chat.agent.sandbox.enabled reste sur off par défaut. Il faut donc l’activer explicitement, soit dans les réglages, soit depuis le menu de permissions d’une session. Une entreprise peut également l’imposer via les paramètres administrés et interdire à l’utilisateur de le contourner.

Encore plus subtil : activer le sandbox ne coupe pas Internet automatiquement. Le réglage chat.agent.sandbox.network.allowNetwork vaut true par défaut. L’accès au réseau local est en revanche désactivé par défaut, et il est possible d’autoriser ou d’interdire des domaines particuliers. Cela signifie qu’un développeur voulant vraiment placer un agent dans une boîte très restrictive devra configurer à la fois le système de fichiers et le réseau. Une commande confinée au dépôt mais autorisée à joindre n’importe quel serveur extérieur n’offre évidemment pas exactement la même isolation qu’une commande sans sortie réseau. Microsoft le dit explicitement : un domaine autorisé peut être utilisé pour effectuer des actions, pas seulement lire des données, et un processus disposant de credentials peut agir avec les droits correspondants.

Le sandbox n’est pas non plus une mini-machine virtuelle magique

Microsoft prend d’ailleurs plusieurs précautions pour éviter ce raccourci. Le sandbox n’est ni une machine virtuelle, ni une séparation entre comptes utilisateurs, ni une frontière de sécurité autonome. Les processus continuent de s’exécuter sur la machine où tourne l’Agent Host, sous votre compte. Les fichiers explicitement autorisés, les caches des outils de développement, les identifiants fournis à l’agent, les chemins supplémentaires ou le réseau peuvent tous réduire l’isolation. Et si une commande est bloquée, la configuration par défaut permet à l’Agent Host de demander la permission de la relancer hors sandbox. Approuver cette demande revient évidemment à retirer les barrières pour cette opération.

Autre nuance importante : le sandbox de processus vise principalement les commandes shell et leurs descendants. Les outils intégrés de lecture, écriture ou modification de fichiers ne passent pas nécessairement dans cette même bulle ; ils utilisent les contrôles de permissions propres à VS Code. Voilà pourquoi Microsoft continue à recommander de protéger explicitement les fichiers sensibles, par exemple .env, et de revoir les diffs avant de fusionner le travail d’un agent. Le sandbox réduit le rayon d’explosion d’un mauvais curl | sh, il ne transforme pas un agent en stagiaire incapable de toucher au moindre fichier sans remplir trois formulaires.

MCP et les language servers entrent eux aussi dans la cage

Le sujet devient encore plus intéressant avec MCP. Un agent moderne ne se contente plus d’un terminal : il peut lancer des serveurs MCP, des language servers et quantité de petits outils locaux possédant eux-mêmes des accès réseau ou système. Avec VS Code 1.141, lorsque le sandbox Agent Host est activé, les serveurs MCP et LSP lancés ou gérés par l’Agent Host sont eux aussi sandboxés par défaut. Les réglages correspondants peuvent toutefois être désactivés séparément, et un serveur démarré indépendamment de l’Agent Host reste évidemment hors de son contrôle.

C’est probablement l’un des aspects les plus utiles à long terme. L’écosystème MCP transforme progressivement le chatbot en interface vers GitHub, bases de données, navigateurs, tickets, documents ou infrastructures internes. Plus ces chaînes comportent de composants, plus la question « quel processus a réellement accès à quoi ? » devient importante. VS Code ajoute même la commande /sandbox policy, capable de produire un rapport décrivant la politique réellement appliquée à la session : système d’exploitation, chemins lisibles ou modifiables et règles réseau. Ce n’est pas particulièrement spectaculaire pour une keynote, mais c’est exactement le genre de fonction que l’on apprécie au moment d’expliquer à une équipe sécurité pourquoi l’agent avait besoin de parler à api.github.com mais certainement pas au NAS du bureau.

Plusieurs agents côte à côte, parce qu’un seul robot ne suffisait évidemment plus

VS Code 1.141 continue parallèlement à transformer la gestion des agents en véritable interface de supervision. La fenêtre Agents permet désormais de placer plusieurs sessions dans une grille, pratique pour surveiller un agent qui corrige les tests pendant qu’un autre prépare une refactorisation. Les sessions peuvent être filtrées selon leur environnement, leur harness ou l’application depuis laquelle elles ont été créées. Les agents peuvent également s’envoyer des tâches entre conversations, modifier une instruction déjà en cours ou mettre en file d’attente des demandes supplémentaires.

La gestion du ménage devient même une fonctionnalité à part entière. Les agents travaillant dans des Git worktrees séparés évitent qu’ils se marchent sur les fichiers, mais ces répertoires finissent par consommer du stockage. La commande Open Worktree Cleanup affiche désormais les anciennes sessions et la taille de leurs worktrees, avec possibilité de les nettoyer manuellement ou automatiquement lorsque les pull requests ont été fusionnées. Les sessions actives, épinglées ou en attente d’une intervention humaine sont protégées. Nous voilà donc officiellement arrivés à une époque où l’IDE doit gérer les déchets laissés derrière lui par les développeurs artificiels.

Même les conversations Codex peuvent maintenant traverser les applications

Parmi les nouveautés les plus surprenantes, VS Code 1.141 sait aussi récupérer une conversation Codex commencée dans l’application ChatGPT ou dans Codex CLI, à condition qu’elle se trouve sur la même machine. La session apparaît alors dans la fenêtre Agents, historique compris, et peut ensuite repartir dans l’autre sens. Une seule application peut envoyer des messages à la fois afin d’éviter que deux clients pilotent simultanément la même conversation.

Ce détail pourrait sembler secondaire, mais il illustre assez bien le futur que Microsoft construit avec Agent Host : le modèle n’est plus forcément attaché à l’éditeur. La session devient l’objet persistant, tandis que VS Code, un terminal ou une autre application constituent simplement différentes fenêtres permettant de la reprendre. C’est exactement ce que décrit l’Agent Host Protocol de Microsoft : séparer l’endroit où l’agent travaille de l’interface utilisée pour le surveiller. Pour les utilisateurs qui jonglent déjà entre un terminal, un chat et un IDE, c’est beaucoup plus intéressant qu’une énième barre latérale « AI ».

Les entreprises peuvent maintenant imposer la laisse

La partie entreprise de la 1.141 est moins amusante à montrer en capture d’écran, mais probablement encore plus importante pour l’adoption des agents. Les administrateurs peuvent exiger le sandbox au niveau de l’organisation et définir allowBypass: false, empêchant ainsi un développeur de le désactiver simplement parce que npm install vient de râler. VS Code ajoute également des options permettant d’associer les sessions Agent Host à des noms d’utilisateurs et de machines dans la télémétrie d’entreprise. Cette collecte d’identité est désactivée par défaut, mais un administrateur peut l’imposer via les paramètres gérés.

Cela montre surtout que les agents sortent progressivement de la phase « jouet de développeur individuel ». Dès qu’une entreprise autorise un modèle à ouvrir des branches, lancer des commandes, utiliser des credentials et travailler en arrière-plan, elle a besoin des mêmes concepts que pour n’importe quel autre système automatisé : politiques, identité, audit, limitations réseau et séparation des privilèges. Le mot « chatbot » commence à devenir franchement insuffisant.

Le bon réflexe : activer le sandbox, puis lui retirer encore quelques clés

Pour un utilisateur individuel, la configuration raisonnable est assez simple dans son principe : activer le sandbox Agent Host, limiter les dossiers accessibles, vérifier si l’agent a réellement besoin d’Internet, ne pas lui ouvrir le réseau local sans raison et éviter de lui fournir des credentials permanents lorsqu’une tâche n’en a pas besoin. Sur Linux, il faudra auparavant installer bubblewrap et socat. Microsoft recommande également Workspace Trust pour tout dépôt inconnu, la revue des diffs et des règles empêchant l’auto-approbation des modifications sur des fichiers sensibles.

Pour les tâches réellement risquées, un Dev Container ou une machine distante reste une couche supplémentaire très pertinente. Microsoft rappelle d’ailleurs qu’un worktree sépare les modifications de code mais n’est pas une frontière de sécurité, tandis qu’un container possède lui aussi des limites dépendant de ses volumes montés et de son réseau. Bref, il n’existe pas encore de case magique « agent parfaitement inoffensif ». Il existe simplement plusieurs barrières que l’on peut empiler jusqu’à ce que la phrase « donne-lui accès au terminal et va déjeuner » cesse d’être une expérience sociale.

Le vrai changement de VS Code n’est peut-être plus dans l’éditeur de texte

Visual Studio Code 1.141 contient évidemment d’autres nouveautés : meilleure gestion de GitHub Enterprise, collage de blocs, nouvelles options d’interface, suivi des shells et diverses améliorations du chat. Mais le sandbox multiplateforme raconte quelque chose de beaucoup plus important sur l’évolution du développement logiciel.

Lorsque l’IA ne faisait que proposer du code, l’erreur principale était une mauvaise fonction qu’un humain pouvait lire avant de l’accepter. Lorsque l’IA devient un agent capable d’exécuter la fonction, installer sa dépendance, démarrer le serveur, modifier cinq fichiers et continuer pendant que vous dormez, la sécurité ne peut plus reposer uniquement sur le fait que « le modèle est généralement raisonnable ».

Les agents ont besoin de limites techniques indépendantes de leur bonne volonté.

C’est précisément ce que VS Code commence à construire avec Agent Host, les permissions, Workspace Trust et désormais le sandbox sur les trois grands systèmes de bureau. La fonction est encore jeune, désactivée par défaut et suffisamment imparfaite pour que Microsoft explique sur plusieurs pages tout ce qu’elle ne protège pas. Mais c’est probablement plutôt bon signe : un sandbox qui promet de tout sécuriser est généralement beaucoup plus inquiétant qu’un sandbox qui vous montre exactement où sont ses trous.

VS Code était autrefois un éditeur léger auquel on installait quelques extensions.

En 2026, il devient progressivement le centre de contrôle d’une petite équipe de développeurs artificiels.

Et comme toute équipe de développeurs, la première chose raisonnable à leur apprendre est peut-être finalement très simple : ne touchez pas au dossier .ssh .