L’isolation de Claude Code limite ce qu’une session peut lire, écrire et atteindre sur le réseau. Cela importe surtout lorsque vous laissez Claude travailler avec moins d’invites de permission, l’exécutez sans surveillance ou le pointez vers du code en lequel vous n’avez pas entièrement confiance. Claude Code peut s’exécuter dans plusieurs types d’environnements isolés, allant d’un sandbox léger par commande à une machine virtuelle entièrement séparée. Cette page couvre comment :Documentation Index
Fetch the complete documentation index at: https://code.claude.com/docs/llms.txt
Use this file to discover all available pages before exploring further.
- Comparer les approches d’isolation disponibles par ce qu’elles isolent, ce qu’elles nécessitent et combien de configuration est impliquée
- Choisir l’approche qui correspond à votre objectif et votre modèle de menace
- Commencer avec l’approche que vous avez choisie, du sandbox Bash intégré à une machine virtuelle dédiée
- Appliquer l’isolation pour chaque développeur de votre organisation
Pour le modèle de sécurité plus large, voir Sécurité. Pour les déploiements Agent SDK, voir Déploiement sécurisé.
Comparer les approches de sandboxing
Les deux premières approches du tableau ci-dessous s’exécutent sur le système d’exploitation hôte sans conteneurs. Les autres placent Claude Code à l’intérieur d’un conteneur ou d’une machine virtuelle.| Approche | Ce qui est isolé | Nécessite Docker | Effort de configuration |
|---|---|---|---|
| Outil Bash sandboxé | Commandes Bash et leurs processus enfants | Non | Minimal sur macOS ; faible sur Linux et WSL2 |
| Runtime sandbox | L’ensemble du processus Claude Code, y compris les outils de fichiers, les serveurs MCP et les hooks | Non | Faible |
| Dev container | Environnement de développement complet | Oui | Moyen |
| Conteneur personnalisé | Environnement de développement complet | Oui | Moyen à élevé |
| Machine virtuelle | Système d’exploitation complet | Non | Élevé |
| Claude Code sur le web | Système d’exploitation complet, hébergé par Anthropic | Non | Aucun ; nécessite un abonnement Claude et GitHub |
Choisir une approche
Faites correspondre votre objectif à une ligne ci-dessous, puis lisez la section de détail qui suit.| Vous voulez | Commencez par |
|---|---|
| Réduire les invites de permission pendant le travail quotidien sur votre propre machine | L’outil Bash sandboxé, activé avec /sandbox |
Laisser Claude travailler sans surveillance avec --dangerously-skip-permissions ou en mode auto | Le dev container préconfiguré, n’importe quel conteneur ou VM, ou le runtime sandbox |
| Isoler les serveurs MCP et les hooks ainsi que Bash, sans Docker | Le runtime sandbox |
| Travailler sur un référentiel non fiable | Une machine virtuelle dédiée, ou Claude Code sur le web si vous avez un abonnement Claude et un compte GitHub connecté |
| Standardiser un environnement sandboxé dans une équipe | Le dev container préconfiguré, copié dans votre référentiel |
| Utiliser Claude Code à partir d’un appareil sans configuration locale | Claude Code sur le web, qui nécessite un abonnement Claude et un compte GitHub connecté |
| Exiger l’isolation pour chaque développeur de votre organisation | Appliquer l’isolation dans une organisation |
| Travailler sur un hôte Windows natif | Un conteneur ou une VM, ou exécutez le sandbox Bash à l’intérieur de WSL2 |
Comment l’isolation se rapporte aux modes de permission
Les modes de permission décident si un appel d’outil s’exécute et si vous êtes invité en premier. L’isolation restreint ce qu’une commande peut accéder une fois qu’elle s’exécute. Les deux fonctionnent ensemble : lorsqu’un mode de permission laisse les actions s’exécuter sans vous demander, une limite d’isolation restreint ce que ces actions peuvent atteindre.--dangerously-skip-permissions supprime entièrement l’examen par action, donc une limite d’isolation est la seule chose limitant ce que Claude peut faire. Exécutez-le toujours à l’intérieur d’un conteneur, d’une VM ou du runtime sandbox, afin que les outils de fichiers, les serveurs MCP et les hooks soient également à l’intérieur de la limite.
Le mode auto remplace l’invite par un classificateur qui examine les actions et bloque celles qui escaladent au-delà de la demande, ciblent une infrastructure non reconnue ou semblent motivées par du contenu hostile que Claude a lu. Le classificateur est un contrôle par action, pas une limite d’isolation, donc une limite d’isolation ajoute toujours une défense en profondeur pour les exécutions sans surveillance, et n’est pas requise comme elle l’est pour --dangerously-skip-permissions.
L’outil Bash sandboxé seul contraint uniquement Bash, donc il n’est pas suffisant pour les exécutions entièrement sans surveillance dans l’un ou l’autre mode. Vous pouvez superposer les approches : exécuter l’outil Bash sandboxé à l’intérieur d’un conteneur ou d’une VM vous donne des restrictions de commande au niveau du système d’exploitation en plus de la limite d’environnement externe. Pour savoir comment le sandbox Bash lui-même interagit avec les règles de permission et les modes de permission, voir Comment le sandboxing se rapporte aux permissions et aux modes de permission.
Outil Bash sandboxé
Cette option ne supporte pas Windows natif. Sur les hôtes Windows, utilisez WSL2 ou l’une des approches de conteneur ou VM ci-dessous.
/sandbox. Le guide Sandboxing couvre les modes d’approbation, la limite par défaut et comment l’élargir ou la réduire.
Le sandbox par commande ne couvre pas tout ce qui s’exécute dans une session :
- D’autres outils intégrés tels que Read, Edit et WebFetch s’exécutent à l’intérieur du processus Claude Code et ne génèrent pas de code arbitraire. Les règles de permission pour le chemin ou le domaine les contrôlent à la place.
- Les serveurs MCP et les hooks sont des processus séparés qui s’exécutent sans contrainte sur l’hôte.
Runtime sandbox
Le package@anthropic-ai/sandbox-runtime enveloppe un processus entier dans la même isolation Seatbelt ou bubblewrap que le sandbox Bash intégré utilise. Exécuter Claude Code à travers lui contraint chaque outil, hook et serveur MCP dans la session, pas seulement Bash. Le runtime est un aperçu de recherche bêta, et son format de configuration peut changer à mesure que le package évolue.
Le runtime refuse tout accès en écriture et réseau par défaut, donc configurez-le avant de lancer Claude Code à travers lui. Dans ~/.srt-settings.json, ou un fichier que vous passez avec --settings, autorisez l’accès en écriture à au moins votre répertoire de projet et aux chemins de configuration de Claude Code ~/.claude et ~/.claude.json. Autorisez les domaines réseau dont votre session a besoin, y compris api.anthropic.com ou le point de terminaison de votre fournisseur configuré. Voir le README du package pour le schéma de configuration complet.
Une fois le fichier de paramètres en place, lancez Claude Code avec npx et passez claude comme commande à envelopper :
Dev containers
Un dev container exécute Claude Code à l’intérieur d’un conteneur Docker que VS Code ou un éditeur compatible gère, avec votre projet monté dedans. Vous pouvez en définir un avec un répertoire.devcontainer/ dans votre référentiel.
Le référentiel claude-code publie un exemple de dev container avec un pare-feu iptables par défaut-refus comme point de départ. Copiez-le dans votre référentiel et ajustez la liste blanche du pare-feu, l’image de base et la version épinglée de Claude Code pour correspondre à votre environnement. Parce que le pare-feu bloque l’egress non approuvé, une configuration comme celle-ci supporte l’exécution de Claude Code avec --dangerously-skip-permissions pour le travail sans surveillance.
Conteneur personnalisé
Vous pouvez exécuter Claude Code dans n’importe quelle image de conteneur Docker ou OCI avec vos propres politiques réseau, volumes montés et profils seccomp. C’est le chemin le plus courant pour les organisations avec une infrastructure de conteneur existante ou des exécuteurs CI. Plusieurs services de sandbox gérés et d’exécution à distance peuvent héberger le conteneur pour vous. La même liste de contrôle s’applique que pour n’importe quel conteneur que vous exploitez : examinez ce qui est monté en écriture, quelles credentials et tokens sont accessibles à l’intérieur, et ce que la politique d’egress réseau permet. Vous pouvez superposer le sandbox Bash intégré à l’intérieur du conteneur pour les restrictions par commande. Les conteneurs non privilégiés ont besoin du paramètre nested-sandbox décrit dans Dépannage du sandboxing.Machine virtuelle
Une machine virtuelle dédiée fournit la séparation la plus forte, avec son propre noyau et, dans les déploiements cloud ou microVM, son propre matériel virtualisé. Les options incluent les instances cloud, les hyperviseurs locaux et les microVMs tels que Firecracker. Utilisez cette approche lorsque vous évaluez du code non fiable, lorsque votre politique de sécurité nécessite une séparation au niveau du noyau entre l’agent et l’hôte, ou lorsqu’aucune approche au niveau de l’hôte ne répond à vos exigences de conformité. La fonctionnalité sandboxes de Docker Desktop fournit une microVM avec son propre daemon Docker et synchronisation d’espace de travail, qui peut exécuter Claude Code sur les hôtes qui ont déjà Docker Desktop.Claude Code sur le web
Claude Code sur le web exécute chaque session dans une machine virtuelle isolée gérée par Anthropic. Un proxy réseau applique une liste blanche par défaut, et un proxy séparé détient votre token GitHub en dehors du sandbox tout en émettant des credentials limités pour l’accès au référentiel à l’intérieur. Utilisez cette approche lorsque vous voulez une isolation VM complète sans provisionner l’infrastructure vous-même, ou lorsque vous déléguez des tâches à partir d’un appareil qui n’a pas d’environnement de développement local. Cela nécessite un abonnement Claude et un compte GitHub connecté, et les sessions clonent votre référentiel depuis GitHub. Voir Claude Code sur le web pour la disponibilité du plan et les options d’authentification GitHub.Appliquer l’isolation dans une organisation
Les développeurs individuels peuvent opter pour n’importe quelle approche ci-dessus. Ce qu’une organisation peut appliquer, et avec quels outils, dépend de l’approche :- Sandbox Bash intégré : la seule approche que Claude Code applique lui-même. Livrez les clés de paramètres
sandboxvia les paramètres gérés, soit comme un fichier géré par votre MDM, soit via les paramètres gérés par serveur sur Claude.ai. Voir Appliquer le sandboxing avec les paramètres gérés pour les clés à déployer et comment empêcher les développeurs d’élargir la politique. - Dev containers : validez l’exemple de dev container dans vos référentiels pour standardiser l’environnement dans une équipe. C’est une convention plutôt qu’une limite d’application, car Claude Code ne nécessite pas de conteneur. Si les développeurs ne doivent pas pouvoir exécuter Claude Code en dehors, appliquez cela avec les outils de gestion d’appareils ou de liste blanche de logiciels de votre organisation.
- Conteneurs personnalisés et VMs : distribuez Claude Code via l’image approuvée et utilisez les outils de gestion d’appareils ou de liste blanche de logiciels de votre organisation pour empêcher l’installation en dehors.
Voir aussi
Ces pages couvrent les détails de configuration et de politique pour les approches ci-dessus.- Sandboxing : configurez l’outil Bash sandboxé intégré
- Dev container : le conteneur de développement Docker préconfiguré
- Sécurité : le modèle de sécurité complet de Claude Code
- Déploiement sécurisé : conseils d’isolation pour les applications Agent SDK
- Paramètres : toutes les clés de configuration sandbox, y compris la livraison de paramètres gérés