Un sandbox pour Claude Code : des environnements d’agent isolés sur un ordinateur portable

Lorsqu’un redémarrage efface votre mémoire de travail

Imaginez six ou sept sessions de Claude Code ouvertes en même temps. Certaines se trouvent dans des terminaux, d’autres fonctionnent à l’intérieur de VS Code, et une autre tourne sous IntelliJ, car l’équipe travaille avec plusieurs langages et chacun a son éditeur préféré. Elles concernent des dépôts différents, des tâches différentes ainsi que des idées inachevées variées. Puis l’ordinateur portable redémarre.

Rien n’est anormal dans le code lui-même. Ce qui est perdu, c’est la localisation de tout : quelle session était en cours de refactage, laquelle attendait une compilation, laquelle avait posé une question dont la réponse n’a jamais été lue. Vingt minutes sont nécessaires pour reconstituer la mémoire de travail à partir de l’historique du shell et des branches git non mises à jour. À ce stade, une mauvaise journée commence à ressembler à un problème de conception.

Le redémarrage n’était que le symptôme le plus évident. Trois sources de friction distinctes usuraient progressivement les ressources.

Mélange des agents. Il est peu coûteux de lancer des agents, mais leur suivi est onéreux. Chacun d’eux nécessite une nouvelle fenêtre de terminal, une nouvelle fenêtre d’édition, ainsi qu’une place supplémentaire dans votre esprit. L’ordinateur portable se transforme en un amas de fenêtres, avec l’être humain en tant que seule couche d’intégration. Les outils existants partent du principe qu’il y a un agent, une tâche et une seule personne pour surveiller, ce qui n’est pas la réalité du travail.

Le dilemme des permissions. Aucune configuration par défaut ne résout ce problème. Claude Code exige l’approbation pour les appels aux outils, mais il peut vous interroger au sujet de détails mineurs tout en restant silencieux face à des appels susceptibles de causer des dommages réels. Le comportement s’est amélioré, mais le problème fondamental reste inchangé, car l’agent agit en votre nom et détient vos privilèges. Un administrateur d’organe GitHub ne peut pas valablement approuver chaque appel API, et il ne peut pas non plus prétendre qu’une seule approbation est inoffensive.

Deux options restent. Vous pouvez continuer à affiner une liste d’autorisation jusqu’à ce qu’elle devienne un document privé que aucun collègue ne pourrait déchiffrer, ou vous pouvez activer --dangerously-skip-permissions et compter sur la chance. Les histoires effrayantes proviennent de cette deuxième option, comme celle de l’agent qui a éliminé sans hésiter une base de données en production. Les deux approches échouent pour une raison : l’agent porte votre identité, et approuver les commandes une par une ne résout ce problème que partiellement.

Fatigue d’installation. Plusieurs mises à jour sur différentes plateformes entraînent l’absence d’un JDK, le mauvais Node, tel SDK ou telle CLI, ainsi qu’une version définie il y a six mois que plus personne ne parvient à expliquer. Chaque changement de contexte coûte des minutes passées à utiliser un gestionnaire de paquets. Le problème s’aggrave en cas de perte ou de remplacement d’un ordinateur portable, car chaque environnement doit être reconstruit outil par outil. Après des mois d’ajustements sur une CLI de codage préférée, on se demande si la configuration peut être reproduite ou s’il vaut mieux tout recommencer en espérant se souvenir des éléments importants.

Une machine dédiée à l’agent

Cela n’a pas commencé en tant que projet de plateforme. Capsule était un outil personnel, conçu pour rendre la semaine d’un ingénieur moins pénible. La logique était simple : donner à l’agent une machine qui lui appartienne, et non la vôtre, où il ne peut ni voir votre système de fichiers ni utiliser vos identifiants, et où dire « allez-y, sans poser de questions » n’est pas imprudent. Il devait également être suffisamment peu coûteux pour que plusieurs d’entre eux puissent fonctionner en parallèle sans problème.

Les collègues l’ont remarqué et en ont demandé un pour eux, puis d’autres ont fait de même. Il a dépassé son origine en tant qu’outil réservé à une seule personne et s’ouvre désormais tous les matins sur l’écran d’un nombre croissant d’ingénieurs, passant de quelques premiers utilisateurs à plusieurs dizaines, avec la majeure partie du groupe d’ingénierie susceptible de le rejoindre bientôt. Personne n’est contraint d’y recourir ; les gens l’adoptent parce que cela facilite leur travail, ce qui constitue le seul signe d’adoption fiable. Un nouvel employé installe Capsule sur un ordinateur portable et peut travailler de manière entièrement autonome dès le premier jour.

En une phrase, Capsule offre à Claude Code un environnement isolé et prêt à l’emploi où il peut travailler seul sur vos dépôts, sans donc disposer de tous vos privilèges.

L’image montre la Station Capsule. Les capsules sont listées le long du bord gauche, le terminal de l’agent sélectionné occupe le centre, et les demandes de fusion que vous possédez ou auxquelles on vous a demandé de donner un avis se trouvent en bas à gauche, offrant ainsi une seule fenêtre pour l’ensemble de la flotte.

Son champ d’application est délibérément restreint. Ce n’est pas un cadre d’orchestration d’agents ni un produit multi-agents, du moins pour l’instant, bien qu’une certaine orchestration puisse apparaître bientôt. Ce n’est pas non plus un IDE, une intégration de plugins ou d’éditeurs, et il ne crée pas de fork ni ne remplace Claude Code, car ce qui s’exécute à l’intérieur est simplement Claude Code configuré d’une certaine manière. Il ne remplace pas les outils CI/CD, et ce n’est pas un service SaaS hébergé, car tout se déroule sur votre ordinateur portable.

Cet aspect final s’est avéré plus important que prévu. Aucun frais par siège et l’absence de processus en cours signifient qu’une dixième capsule coûte autant que la première, ce qui transforme le travail en parallèle d’un luxe en une routine. La machine est déjà payée, et les répertoires restent sur le matériel où ils ont été initialisés.

Dans une capsule, Claude fonctionne avec l’option --dangerously-skip-permissions et ne demande jamais s’il est autorisé à exécuter une commande. Ses seules questions portent sur l’intention, c’est-à-dire ce qu’il faut faire, et jamais sur les permissions. Ce comportement par défaut est sensé uniquement grâce à deux facteurs sous-jacents.

Le sandbox

Chaque capsule fonctionne comme un pod au sein du cluster Kubernetes que OrbStack met déjà à disposition sur Mac. Cela permet de garder tout le système local, sans infrastructure supplémentaire ni facture cloud. Le système de fichiers hôte est inaccessible, et deux volumes déclarés stockent des données persistantes : un espace de travail et un cache d’images Docker. Trois couches restreignent le trafic sortant :

• Les règles iptables du noyau bloquent les ports sortants 80 et 443 pour l’ID d’utilisateur de l’agent.
• Une NetworkPolicy Kubernetes limite ce qui reste aux adresses DNS, 80 et 443.
• Tout ce qui reste passe par un proxy Squid qui applique une liste blanche explicite des domaines autorisés.

La liste blanche couvre GitHub, npm, Maven, ECR et l’API Anthropic ; tous les autres destins sont refusés par défaut. Un agent ne dispose d’aucun moyen simple pour atteindre un point de terminaison arbitraire et télécharger votre code source, et y parvenir nécessiterait une véritable ingéniosité.

Trois niveaux bloquent tout avant qu quoi que ce soit ne quitte le système : les règles du noyau, puis la politique réseau, enfin le proxy de liste d’autorisation.

Credenciaux à privilèges réduits

C’est là que réside la véritable valeur. L’authentification a lieu sur l’hôte sous votre propre nom, avec tous les rôles que vous utilisez habituellement. Ces rôles restent dans le trousseau de clés de macOS et n’atteignent jamais la capsule. L’hôte crée plutôt un jeton à portée restreinte et à durée de vie courte qu’il injecte :

• une crédence AWS STS temporaire limitée à un rôle de lecture seule en environnement de production
• un jeton GitHub, dont les scopes sont vérifiés avant son insertion
• un compte de service BigQuery à lecture seule que l’agent impersonne, afin que vos propres credenciaux ne soient pas impliqués

Si l’on fournit quelque chose de plus large, comme un rôle d’administration de production SSO ou un jeton doté de droits excessifs, l’hôte refuse catégoriquement de l’injecter. La défense est la norme, et depuis l’intérieur, l’agent ne peut ni se réauthentifier ni accéder à des droits plus étendus. L’identité est préservée, de sorte que le journal d’audit attribue toujours la requête à l’utilisateur, mais ce qui peut être endommagé se limite au rôle concerné et ne concerne pas l’utilisateur lui-même.

L’utilisateur se connecte sur l’hôte en tant que lui-même, et l’agent ne reçoit jamais qu’un jeton restreint et à durée de vie courte, généré à partir de ce compte. Ce compromis permet au reste du système de fonctionner correctement. Laisser un agent s’exécuter sans surveillance ne repose pas sur une plus grande confiance en lui, mais plutôt sur le fait de rendre le pire scénario moins problématique.

Éliminer les obstacles

La sécurité permet d’avoir une certaine autonomie, mais elle ne garantit pas une expérience agréable. La majeure partie des efforts a été consacrée à éliminer les obstacles.

L’image de base à partir de laquelle démarrent les capsules contient déjà des versions intégrées des outils nécessaires : Go, Rust, Node, le JDK, Maven, sbt et Scala. Un sidecar Docker-in-Docker fonctionne en parallèle, ce qui permet à chaque capsule d’avoir son propre environnement Docker fonctionnel, afin que les tests d’intégration et les suites Testcontainers s’exécutent sans interférer avec les autres capsules. Les outils en ligne de commande connectés sont également disponibles, à savoir GitHub CLI, AWS CLI, gcloud et bq. Des serveurs de langage prêts à l’emploi sont inclus (Metals, jdtls, gopls, rust-analyzer, vtsls), ce qui permet à l’agent de naviguer dans le code via des fonctionnalités comme « aller à la définition », « trouver les références » et les hiérarchies d’appels, plutôt que de chercher de manière aléatoire.

Les caches des dépendances sont partagés entre les capsules via un volume hôte. Cela peut sembler un détail mineur, mais ce n’est pas le cas. Dans la première version, chaque nouvel environnement devait télécharger tout à nouveau, et un outil qui met vingt minutes à démarrer Maven avant chaque tâche ne serait pas adopté. Aujourd’hui, une capsule prête à l’emploi est mise en place en environ vingt à trente secondes.

Ce qui a le plus changé le comportement de l’agent, c’est un véritable cycle de feedback. Une interface en ligne de commande de plateforme interne s’exécute à l’intérieur de la capsule : le jeton SSO de l’hôte est vérifié, restreint dans son champ d’application et injecté, ce qui permet à l’agent de créer un environnement sandbox, de déployer la branche qu’il vient de construire et d’y exécuter des tests de base. L’outil de test d’intégration s’exécute également à l’intérieur, téléchargeant des images réelles et lançant des instances réelles de MySQL, Kafka et Cassandra dans le sidecar. Au début, les opérations sont lentes en raison du passage des images par le proxy, mais elles deviennent rapides par la suite. C’est ce qui distingue un agent capable de produire du code plausible d’un agent capable de déterminer si ce code fonctionne réellement.

La capacité de recherche est également intégrée. Chaque capsule débute avec une passerelle MCP interne qui ne fait que lire, offrant quelques dizaines d’outils. Cela inclut l’accès aux journaux des services et des pods, aux métriques via PromQL et Thanos, aux tableaux de bord Grafana, aux événements Kubernetes, à l’état des builds CI, à l’identification des personnes de garde et aux alertes déclenchées, à la responsabilité des services, ainsi qu’à une recherche dans Confluence et Slack. Comme rien ne peut être écrit, son activation partout n’entraînait aucun risque. Un marché de plugins ajoute des compétences pour les builds Maven, le squelette des services, la gestion des environnements de test et l’examen des PR, afin que les conventions internes soient connues de l’agent dès la première minute.

Voici une habitude qui vaut la peine d’être adoptée. Conservez un répertoire privé contenant des commandes personnelles et des modèles de plans, et Capsule le clonera dans chaque environnement créé. Votre propre flux de travail vous suivra ainsi partout. Les plans et les souvenirs se transmettent également entre les capsules via ce répertoire, et une fonction de transfert peut noter où s’est terminée une session et enregistrer le résumé, afin que la prochaine capsule démarre avec le contexte nécessaire et non à zéro. Il s’agit d’un répertoire git ordinaire, ce qui permet à l’agent de gérer ses propres outils également ; une seule instruction comme « ajouter une commande de construction et de test, la commiter, la pousser » suffit.

Préserver plutôt que recommencer

Un effet inattendu en a résulté. Une fois que la création d’un agent isolé devient peu coûteuse et que chacun d’eux persiste que l’on s’en occupe ou non, le travail cesse d’être traité une tâche à la fois.

Dans une après-midi typique, quatre ou cinq capsules sont actives. L’une travaille en arrière-plan sur la correction d’un bug, une autre permet une session SSH pour un véritable programmation en pair, une troisième relance un test d’intégration instable et ouvre une demande de fusion lorsque celui-ci réussit, tandis qu’une quatrième s’occupe d’une mise à jour de dépendance que personne ne souhaite suivre. Environ dix autres restent arrêtées : une idée à reprendre, une expérience qui a échoué de manière intéressante, un concept partiellement envisagé. Arrêter ces capsules permet de conserver les dépôts, les sessions et les caches, et reprendre le travail ne prend que quelques secondes ; ainsi, une idée n’est pas abandonnée simplement parce qu’elle n’est pas la priorité du jour.

La partie coûteuse n’a jamais été de commencer à travailler, mais plutôt de mettre le travail en attente. Et une fois quelque chose terminé, on supprime la capsule, sans aucun désordre dans l’arborescence git ni tâches de nettoyage, et tous les produits secondaires disparaissent en même temps.

L’autonomie totale élimine les derniers obstacles. Il n’y a plus de demande d’approbation pour une commande git, pas besoin de fouiller dans une fenêtre du navigateur à la recherche d’un numéro sur une page CI, ni de parcourir un journal de compilation pour trouver la seule ligne importante. L’agent s’en charge, et avec le sandbox ainsi que les tokens ciblés en place, cela ne revient pas à simplement parier.

Quatre capsules, quatre états, aucun ne dépend de l’être humain.

Un même moteur dispose de deux modes : vous pouvez travailler à côté de l’agent dans une session tmux interactive, ou lui donner une instruction et le laisser agir seul.

C’est pour cette raison que l’interface a été conçue. La ligne de commande est puissante, mais exécuter sans cesse des commandes comme list, ssh et status dans un terminal n’est certainement pas une méthode fiable pour gérer une flotte. Capsule Station comble ce manque grâce à une seule fenêtre : les capsules affichées dans une barre latérale, un terminal intégré pour chacune d’elles, ainsi que vos demandes de pull request et de revue à côté. Changer d’agent ressemble à changer de onglet dans un navigateur. L’application utilise Tauri, pèse environ dix mégaoctets et s’appuie sur le webview du système, car afficher une liste ne devrait pas nécessiter un Chromium intégré ni un gigaoctet d’espace disque. Elle a tendance à rester ouverte toute la journée, contrairement aux IDE qui le font rarement.

Il est tout aussi juste de mentionner ce qu’elle laisse intact. La qualité du code généré ne s’améliore pas. Ce qui disparaît, en revanche, c’est tout le travail associé : trier, approuver, installer, se réauthentifier et perdre sa place dans les différentes étapes, ce qui s’est avéré être la majeure partie des difficultés.

Pourquoi construire plutôt que d’acheter

Les solutions hébergées existent bel et bien et deviennent de plus en plus performantes, comme les sandbox d’agents cloud proposés par plusieurs fournisseurs ou des agents qui s’exécutent à distance pour vous. Elles ne représentent aucun fardeau opérationnel et offrent une véritable échelle. Cependant, le code et les identifiants quittent votre périmètre de sécurité, les outils utilisés sont génériques, ce qui ralentit le démarrage des applications dans de grandes bases de code, et il est impossible d’implémenter un modèle d’identité interne. Il existe également des projets open source, tels que des sandbox natifs de Kubernetes, des outils de type dev-container ainsi que des primitives de sandboxing locales fournies par certains fabricants. Ceux-ci sont neutres vis-à-vis des fournisseurs et reposent sur des principes solides, bien que de bas niveau, vous laissant donc responsable de l’image, de l’authentification et de toute l’expérience utilisateur. Pour n’importe quelle solution, une préoccupation légitime est de savoir si elle sera encore maintenue dans six mois, car tout le monde lance des initiatives et peu d’entre elles perdurent.

Le bâtiment se situait entre les deux. La capsule est principalement composée de différents éléments : DevPod gère le conteneur de développement ainsi que le cycle de vie des pods, Squid s’occupe du trafic sortant, le cluster Kubernetes déjà fourni par OrbStack, ainsi qu’une image d’espace de travail personnalisée, une authentification gérée par l’hôte et Station en tant que couche supérieure. L’interdépendance reste faible et les composants peuvent être remplacés. Cela convient au code source et au modèle d’authentification, et le code reste sur l’ordinateur portable, à l’exception de ce que l’agent envoie à l’API du modèle, comme pour toutes les autres options ici.

Les identifiants sont générés sur l’hôte, tandis que tout ce que touche l’agent s’exécute dans un pod derrière un proxy disposant d’une liste d’autorisation.

Il existe également un argument de flexibilité qui s’est avéré plus important que prévu. Si quelqu’un souhaite une fonctionnalité, il ouvre une demande de fusion et en discute, puis elle est intégrée. Personne ne passe trois semaines avec un chef de produit pour expliquer que cela pourrait figurer dans le plan stratégique de l’année suivante.

Le risque est réel et il convient de le mentionner : l’équipe en assume la responsabilité, et il s’agit essentiellement d’un projet individuel soutenu par l’entreprise. Le développement n’a jamais été aussi peu coûteux, mais le coût de maintenance reste un véritable inconnu. Personne n’a encore de réponse à cette question.

Que vient-il ensuite ?

À l’avenir, on prévoit un déploiement progressif allant de dizaines d’utilisateurs à toute l’organisation, l’intégration de davantage de compétences et d’outils dans l’image, ainsi que plus d’intégrations. Ce dernier point est plus difficile qu’il n’y paraît, car chaque intégration nécessite de définir ce que peut faire un agent en mode sans question. L’accès en lecture seule est simple, mais tout ce qui implique des écritures exige une discussion approfondie et un moyen de marquer les opérations destructrices. L’opération à distance est de loin la fonction la plus demandée ; les capsules pourraient donc continuer à fonctionner même avec l’ordinateur portable fermé.

Avertissement concernant les failles de sécurité

Le système est délibérément défensif, et sa mise en place enseigne une leçon désagréable : un outil qui accorde de l’autonomie aux agents repose fortement sur les points faibles d’un modèle de sécurité. Un bon contrôle d’accès facilite l’intégration, tandis que son absence cause des problèmes immédiatement et montre précisément pourquoi.

Néanmoins, un environnement isolé a ses limites. Exécuter un agent avec des privilèges complets, qu’il soit utilisé ou non, revient à transporter des armes chargées. Capsule élimine ce problème. Cependant, si l’on colle un jeton d’administrateur dans la conversation et que l’on demande à l’agent de l’utiliser, ces privilèges lui sont restitués.

Allez créer

Ce sont des temps remarquables, et il est difficile d’overstimer ce qu’un ingénieur peut créer. Tout a commencé par l’agacement d’une seule personne un après-midi ordinaire, pour devenir quelque chose que de plus en plus de collègues ouvrent chaque matin. Deux conditions restent à remplir : il faut savoir quel problème on souhaite résoudre, et il faut un soutien financier, car les jetons coûtent de l’argent et quelqu’un doit reconnaître qu’ils en valent la peine. Avec ces deux éléments, le travail a changé définitivement ; il faut donc identifier les problèmes et les résoudre.