Docker sbx : arrêtez de lancer Claude Code sans sandbox

Claude Code est l’un des agents IA les plus populaires. Il est capable d’écrire, tester et exécuter du code de façon autonome. C’est précisément ce qui en fait un outil puissant, et c’est exactement ce qui pose un problème de sécurité non négligeable : sans isolation, il tourne avec les mêmes privilèges que vous sur votre système. Vos clés SSH, vos tokens AWS, vos fichiers .env, votre daemon Docker : tout est à portée de l’agent. Docker sbx, l’outil de sandbox de Docker, vous permet facilement d’enfermer l’agent dans une microVM dédiée. Cet article explique pourquoi cette précaution est importante et comment la mettre en place en quelques minutes.

Ce que Claude Code peut atteindre sans isolation

Lorsque vous lancez Claude Code sur votre poste sans sandbox, le processus agent hérite intégralement de votre session shell. Cela signifie qu’il dispose d’un accès complet à votre répertoire personnel, à vos variables d’environnement exportées (dont AWS_SECRET_ACCESS_KEY, DATABASE_URL, ou tout token stocké dans votre shell), à vos clés SSH dans ~/.ssh, aux fichiers .env dispersés dans vos projets, et au daemon Docker de la machine hôte, ce qui peut permettre une élévation vers des environnements de production.

L’agent n’a pas besoin d’être malveillant pour que quelque chose tourne mal. Il suffit d’un paquet npm compromis dans une dépendance, d’une injection de prompt dans un fichier que l’agent lit, ou d’un serveur MCP mal configuré pour que le comportement de l’outil soit détourné à votre insu.

Des incidents documentés, pas des scénarios théoriques

Plusieurs incidents illustrent ce risque. La supply chain attack s1ngularity a utilisé Claude Code comme outil d’exfiltration de données. L’extension Cline (plus de cinq millions d’utilisateurs) a été victime d’une injection de prompt qui a abouti à l’exfiltration de tokens npm. La technique Comment and Control, présentée à BSides San Francisco 2026, a montré comment des agents IA liés à des outils de revue de code sur GitHub Actions, y compris Claude Code Security Review, pouvaient être détournés via des commentaires de pull request soigneusement forgés.

La sandbox réseau native de Claude Code elle-même a connu deux contournements sérieux depuis son lancement en disponibilité générale en octobre 2025. CVE-2025x-66479 : une liste blanche vide allowedDomains: [], censée bloquer tout le trafic sortant, était interprétée comme « tout autoriser ». Le second problème, une injection null-byte dans le proxy SOCKS5, permettait de contourner n’importe quelle liste blanche avec un simple caractère \x00. Les deux failles ont été corrigées silencieusement, sans advisory de sécurité publié ni notification aux utilisateurs. Ces correctifs ont été disponibles respectivement en novembre 2025 (v2.0.55) et en avril 2026 (v2.1.90).

Ces incidents soulignent un point structurel : l’isolation au niveau du système d’exploitation, aussi bien configurée soit-elle, reste vulnérable à des contournements logiciels. Une isolation au niveau du noyau répond différemment à cette menace.

Docker sbx : une microVM, pas un simple conteneur

Docker sbx est un outil CLI autonome (il ne nécessite pas Docker Desktop) qui exécute les agents IA dans des microVMs légères. La différence avec un conteneur Docker classique est importante sur le plan de la sécurité : un conteneur partage le noyau de la machine hôte. Un container escape donne accès au noyau hôte. Une microVM dispose de son propre noyau Linux isolé, si bien qu’un contournement éventuel ne débouche sur rien d’exploitable côté hôte (voir * pour les puristes).

*Une microVM dispose de son propre noyau Linux isolé. Un contournement éventuel ciblerait l’hyperviseur (KVM sur Linux, Apple Virtualization Framework sur macOS), une surface d’attaque bien plus réduite et distincte du système hôte

Concrètement, avec sbx, Claude Code tourne entièrement à l’intérieur de la VM. Seul le répertoire de travail que vous montez explicitement est partagé entre le VM et votre système. Le trafic réseau sortant passe obligatoirement par un proxy hôte avec une politique configurable. Vos credentials (clé Anthropic API, tokens cloud) sont gérés côté hôte via le trousseau système et injectés au niveau du proxy, l’agent ne voit jamais les valeurs brutes.

C’est aussi pour cette raison que l’option --dangerously-skip-permissions de Claude Code est le mode par défaut dans sbx : la sandbox est la frontière de sécurité, les confirmations manuelles deviennent redondantes. C’est précisément l’intérêt du produit : vous donnez à l’agent une autonomie totale à l’intérieur d’un périmètre que vous contrôlez.

Installation de Docker sbx

Docker sbx supporte actuellement macOS (Apple Silicon, M1 ou supérieur, macOS Sonoma 14 minimum), Windows, et Linux ARM (architecture aarch64, bare metal avec KVM). La prise en charge de Linux x86_64 n’est pas disponible à ce jour : cette contrainte est abordée dans la section dédiée ci-dessous.

Un compte Docker Hub est requis pour l’authentification. L’usage individuel est gratuit. Les fonctionnalités d’administration centralisée (politiques réseau d’équipe, contrôle du filesystem à l’échelle) nécessitent de contacter Docker directement via leur formulaire dédié.

Installation sur macOS (Apple Silicon)

brew install docker/tap/sbx
sbx login

La commande sbx login ouvre un flux OAuth dans le navigateur. L’authentification est requise une seule fois.

Installation sur Windows

winget install Docker.sbx
sbx login

Installation sur Linux ARM (aarch64, bare metal)

Sur Linux ARM, sbx utilise KVM pour la virtualisation. KVM doit être disponible sur du matériel bare metal (il ne fonctionne pas dans une VM). Vérifiez sa disponibilité avec :

lsmod | grep kvm

Si la sortie est vide, lancez kvm-ok pour un diagnostic. Si KVM est disponible, ajoutez votre utilisateur au groupe concerné, puis installez sbx :

sudo usermod -aG kvm $USER
# Reconnectez-vous pour que le changement de groupe prenne effet
 
curl -fsSL https://get.docker.com | sudo REPO_ONLY=1 sh
sudo apt-get install docker-sbx
sbx login

Lancer Claude Code dans le sandbox

La commande de base est simple : placez-vous dans le répertoire de votre projet et lancez :

cd ~/mon-projet
sbx run claude .

Le point final indique le répertoire de travail à monter dans la VM. Lors du premier lancement, l’image agent est téléchargée (une à deux minutes). Les exécutions suivantes réutilisent l’image en cache et démarrent en quelques secondes.

Si vous utilisez Claude Code avec une clé API Anthropic, exportez-la avant le lancement et enregistrez-la dans le trousseau sbx :

echo "$ANTHROPIC_API_KEY" | sbx secret set -g anthropic

Avec un abonnement Claude (Max, Team ou Enterprise), aucune clé n’est nécessaire : utilisez la commande /login à l’intérieur de la session sandbox pour vous authentifier via OAuth. Le proxy gère le flux, vos credentials ne transitent pas en clair dans la VM.

Pour nommer un sandbox et le réutiliser entre sessions (les configurations persistent) :

sbx run --name mon-projet claude .

Lancez sbx sans argument pour ouvrir le tableau de bord interactif : vous y voyez l’état de chaque sandbox, l’usage CPU et mémoire en direct, et le panneau réseau (touche Tab) qui liste en temps réel chaque connexion sortante tentée par l’agent, autorisée ou bloquée.

Configurer la politique réseau

Au premier lancement, sbx vous demande de choisir une politique réseau par défaut. Trois options sont disponibles :

• Open : tout le trafic sortant est autorisé, aucune restriction.
• Balanced : refus par défaut, avec les services de développement courants préautorisés (dépôts de paquets, CDN courants). C’est le bon point de départ pour la plupart des projets.
• Locked Down : tout le trafic est bloqué, y compris l’API Anthropic, sauf ajout explicite à la liste blanche.

La politique Balanced est recommandée pour un usage quotidien. Si l’agent a besoin d’accéder à un service non couvert par la politique par défaut (une API externe, un registre privé), vous pouvez l’autoriser explicitement avec sbx policy :

sbx policy allow network api.monservice.com

Pour un projet avec des besoins réseau précis et reproductibles, définissez ces règles dans un fichier kit YAML versionnable avec votre code. Le sandbox se configure alors automatiquement à la création, y compris l’installation des dépendances système nécessaires.

Et sur Linux x86_64 ?

Docker sbx ne supporte pas Linux x86_64 à ce jour. Pour les développeurs sur cette architecture, Claude Code propose une sandbox native activable via la commande /sandbox à l’intérieur d’une session, construite sur bubblewrap (Linux) ou macOS Seatbelt.

Cette approche comprend : une restriction des écritures au répertoire courant, filtrage réseau via proxy. Mais elle présente une différence structurelle importante par rapport à sbx : Claude Code continue de tourner comme un processus de votre utilisateur hôte, sur le noyau de votre machine. Les restrictions sont appliquées par le système d’exploitation, et peuvent être contournées par une vulnérabilité noyau ou une faille dans l’implémentation (deux contournements ont d’ailleurs été documentés dans la sandbox réseau native de Claude Code, décrits plus haut). Avec sbx, le noyau de la VM est la frontière d’isolation, et une attaque qui sortirait de ce périmètre ne débouche sur aucun accès hôte.

Sur Linux x86_64, la sandbox native reste une couche de défense valable si sbx n’est pas une option. Installez au préalable bubblewrap et socat, puis activez le sandbox avec /sandbox dans Claude Code et, si vous gérez la configuration programmatiquement, vérifiez que allowUnsandboxedCommands: false est bien défini pour éviter qu’un agent suffisamment motivé ne se désactive lui-même.

La référence externe sur ce sujet reste le billet d’ingénierie d’Anthropic : Making Claude Code more secure and autonomous with sandboxing.

Docker sbx cheatsheet

Démarrage

Commande	Description
sbx run claude .	Lancer Claude Code dans le répertoire courant
sbx run --name mon-projet claude .	Lancer avec un nom persistant (configuration conservée entre sessions)
sbx run claude -- --continue	Reprendre la session Claude Code précédente
sbx run --clone --name mon-projet claude .	Clone isolé du dépôt, hôte monté en lecture seule

Gestion des sandboxes

Commande	Description
sbx ls	Lister les sandboxes existants
sbx rm mon-projet	Supprimer un sandbox
sbx exec -it mon-projet bash	Ouvrir un shell interactif dans le sandbox
sbx	Ouvrir le dashboard TUI (état, CPU, mémoire, réseau en direct)

Credentials

Commande	Description
echo "$ANTHROPIC_API_KEY" | sbx secret set -g anthropic	Enregistrer la clé API depuis une variable d’environnement (rien dans l’historique shell)
sbx secret set -g anthropic < ~/.secrets/key	Enregistrer la clé depuis un fichier
sbx secret list	Lister les secrets enregistrés dans le trousseau

Réseau

Commande	Description
sbx policy allow network api.monservice.com	Autoriser un domaine dans la politique réseau
sbx policy reset	Réinitialiser la politique réseau (redemande Open / Balanced / Locked Down)
sbx ports mon-projet --publish 3000:3000/tcp	Exposer un port du sandbox vers l’hôte

Questions fréquentes Claude Code sandbox et Docker SBX