Docker Sandboxes pour exécuter des agents de codage

Docker Sandboxes exécute un agent de codage comme Claude Code, Codex, Copilot ou Cursor dans une microVM locale. Cette microVM dispose de son propre noyau et de son propre moteur Docker. Elle ne partage que le répertoire de votre projet avec l’hôte, et son exécution en local est gratuite.

Si vous avez déjà validé une centaine de demandes d’autorisation pour ls et npm test en un seul après-midi, vous connaissez l’attrait de l’option « skip permissions ». Vous savez sans doute aussi ce que l’agent pourrait faire à votre ordinateur une fois cette option activée.

Cet article explique ce que la sandbox isole et comment la configurer, de l’installation à la première session. Il montre aussi comment récupérer les modifications de l’agent, comment l’outil se compare aux autres solutions et ce qu’il coûte. L’outil n’a pas encore atteint la version 1.0 et évolue rapidement.

Pourquoi l’autonomie complète sur votre ordinateur est risquée

Un agent de codage en mode d’autonomie complète exécute des commandes shell, installe des paquets et modifie des fichiers sans rien demander. Il fait tout cela avec votre compte utilisateur. Votre répertoire personnel, vos clés SSH, vos identifiants cloud et vos services locaux sont donc à sa portée. Un seul rm -rf ou git reset --hard malencontreux peut effacer du travail non commité.

Les demandes d’approbation sont la protection habituelle, mais elles vont à l’encontre de l’intérêt même d’un agent. Les tâches longues s’interrompent à chaque commande, et après la vingtième demande, la plupart des gens approuvent sans lire. Mieux vaut placer l’agent dans un environnement où il ne peut pas faire grand mal, plutôt que de lui accorder davantage de confiance. Les arguments généraux en faveur de l’isolation des agents sont présentés dans exécuter des agents de codage en mode YOLO en toute sécurité. Le présent article se concentre sur un outil en particulier.

Pourquoi Docker Sandboxes utilise une microVM plutôt qu’un conteneur

Un conteneur Docker classique partage le noyau de l’hôte. Tout processus ayant accès au socket Docker peut lancer un conteneur privilégié qui monte votre système de fichiers. La documentation de Docker sur la surface d’attaque du daemon rappelle que le daemon s’exécute en tant que root et que seuls des utilisateurs de confiance devraient le contrôler. Les agents ont souvent besoin de Docker. Le raccourci évident, qui consiste à monter /var/run/docker.sock, leur livre donc la machine entière.

Selon la documentation de Docker sur les couches d’isolation, chaque sandbox est une microVM dotée de son propre noyau Linux et de son propre Docker Engine. L’agent peut exécuter docker build et docker run dans la sandbox sans la configuration privilégiée qu’exige Docker-in-Docker. Le daemon de votre hôte n’est jamais sollicité.

Configurer une Docker Sandbox de bout en bout

Installez la CLI sbx, connectez-vous à Docker, fournissez à l’agent les identifiants du modèle, puis exécutez sbx run depuis le répertoire de votre projet. Le tutoriel officiel précise que votre hôte n’a besoin ni de Docker Desktop ni de Docker Engine.

Installez l’outil avec la commande correspondant à votre système d’exploitation :

# macOS
brew trust docker/tap && brew install docker/tap/sbx

# Windows
winget install Docker.sbx

# Ubuntu: add Docker's apt repo, install, then grant KVM access
curl -fsSL https://get.docker.com | sudo REPO_ONLY=1 sh
sudo apt-get install docker-sbx
sudo usermod -aG kvm $USER
newgrp kvm

Sous Linux, KVM est requis et votre utilisateur doit appartenir au groupe kvm. Docker teste et prend en charge sbx sur Ubuntu. Pour les autres distributions, le dépôt sbx-releases propose des fichiers de release, mais Docker ne garantit pas leur bon fonctionnement. Consultez la page d’installation pour connaître les prérequis propres à chaque plateforme.

Démarrez ensuite une session Claude Code :

sbx login
sbx secret set anthropic        # skip if you use a Claude subscription
cd ~/my-project
sbx run --name my-project claude

• Clé d’API : sbx secret set anthropic enregistre la clé sur votre hôte. Le proxy de la sandbox l’ajoute aux requêtes d’API de l’agent, qui ne manipule donc jamais la clé en clair. Pour Codex, utilisez sbx secret set openai. Si vous avez déjà exporté la clé dans votre shell, sbx secret import --dry-run liste les clés que sbx peut détecter, et sbx secret import les enregistre après confirmation de chacune.
• Abonnement : aucun secret n’est nécessaire. Avec Claude, tapez /login une fois Claude Code démarré dans la sandbox. Avec Codex, sbx lance d’abord l’authentification OpenAI sur votre hôte, puis crée la sandbox.

Lors de la première exécution, sbx vous demande de choisir une politique réseau par défaut. L’agent démarre ensuite en mode d’autonomie complète : Claude Code ne demande aucune autorisation et vous n’avez aucune option à passer. Pour utiliser un autre agent, remplacez claude par codex, copilot, cursor ou gemini.

Le dossier de votre projet est la seule partie de votre machine où l’agent peut écrire, et il peut y supprimer n’importe quoi. Faites un commit ou un push avant de commencer.

Comment récupérer le travail de l’agent ?

En mode par défaut, les modifications d’un agent Docker Sandbox apparaissent immédiatement dans votre arbre de travail sur l’hôte. Examinez-les comme vous le feriez habituellement :

git diff

Des guides plus anciens, dont le dépôt d’exemple du quickstart de Docker, mentionnent une option --branch. Celle-ci plaçait l’agent sur un worktree côté hôte, sous .sbx/. Cette option a été supprimée dans sbx v0.31.0 au profit du mode clone. L’utiliser aujourd’hui renvoie une erreur qui vous invite à employer --clone.

Le mode clone tient l’agent à l’écart de votre arbre de travail. Comme l’explique la documentation sur le workflow Git, sbx crée un clone Git privé dans la sandbox, et l’agent travaille sur cette copie. Rien ne change sur votre hôte tant que vous ne récupérez pas la branche de l’agent ou que l’agent ne pousse pas vers un dépôt distant. Le mode clone ne peut être choisi qu’à la création d’une sandbox. Passez donc --clone dès la première exécution : il est impossible de basculer ultérieurement une sandbox existante.

Questions pratiques

Quelle politique réseau choisir ?

Docker Sandboxes propose trois politiques réseau locales :

• Open autorise tout le trafic.
• Balanced bloque le trafic par défaut, mais autorise les services de développement courants.
• Locked Down bloque tout ce que vous n’autorisez pas explicitement.

Choisissez Balanced pour la plupart des travaux frontend. Cette politique couvre les registres de paquets, les plateformes d’hébergement de code et les API des fournisseurs d’IA. Si votre agent a besoin d’un site absent de la liste, comme un site de documentation, exécutez sbx policy check network <domain> pour vérifier s’il est bloqué. Autorisez-le ensuite avec sbx policy allow network <domain>. Exécutez sbx policy ls pour afficher vos règles et supprimez-en une avec sbx policy rm. Les kits d’agents intégrés peuvent aussi ajouter leurs propres règles d’autorisation pour chaque sandbox, même en mode Locked Down.

L’état est-il persistant ?

Oui. Les outils installés par l’agent et les modifications qu’il apporte au système d’exploitation restent dans la sandbox jusqu’à sa suppression. La commande sbx rm my-project efface l’environnement ainsi que les secrets propres à cette sandbox. Vos secrets globaux et le dossier de votre projet restent intacts.

Comment se reconnecter ?

Pour vous reconnecter à une Docker Sandbox existante, exécutez sbx run --name my-project. Inutile de répéter le nom de l’agent, qui est lu depuis la sandbox existante. Exécuter sbx sans argument ouvre un tableau de bord interactif.

Docker Sandboxes face aux conteneurs, devcontainers et VM distantes

Chaque solution alternative sacrifie au moins l’un de ces trois éléments : l’isolation du noyau, un accès sûr à Docker ou une politique intégrée de contrôle du trafic sortant.

Si votre véritable besoin est de contrôler les outils qu’un agent peut appeler, plutôt que d’isoler son environnement, consultez Docker MCP pour les agents d’IA.

Limites et coût de Docker Sandboxes

Les sandboxes locales sont gratuites. D’après les notes de version v0.45.0, les sandboxes cloud sont expérimentales et nécessitent un abonnement actif à Docker Agentic Platform. L’inférence des modèles est à votre charge, via votre propre clé ou votre abonnement. Un compte Docker est nécessaire pour exécuter sbx login. Le produit est récent : la tarification et les options peuvent évoluer.

• Le répertoire du projet est entièrement accessible en écriture : le travail non commité n’est pas protégé.
• Tout ce que l’agent pousse, ou envoie vers un domaine autorisé, sort de la sandbox.
• Définissez les ressources avec --memory et --cpus. En local, la mémoire est par défaut fixée à la moitié de la RAM de l’hôte, dans la limite de 32 Gio. Les valeurs par défaut documentées de 2 CPU et 4 Gio s’appliquent aux sandboxes cloud.
• La signature des commits via SSH fonctionne grâce au transfert de l’agent SSH, activé par défaut lorsque SSH_AUTH_SOCK est défini sur votre hôte. Vous devez toutefois configurer Git dans la sandbox pour qu’il signe avec la clé transférée.
• Andrew Lock a signalé en avril 2026 que l’exécution dans une sandbox ralentissait fortement même des projets simples.

Conclusion

Docker Sandboxes fournit à un agent de codage son propre noyau, son propre moteur Docker et un réseau contrôlé par des politiques. La seule partie de votre machine à laquelle il a accès est le dossier de votre projet. Pour commencer, commitez votre travail, installez sbx, choisissez Balanced et exécutez sbx run --name my-project claude sur un dépôt que vous pouvez vous permettre de perdre. Passez au mode clone lorsque vous souhaitez que les modifications de l’agent restent hors de votre arbre de travail jusqu’à ce que vous les ayez examinées.

FAQ

Comment accéder à un serveur de développement lancé par l'agent dans une Docker Sandbox ?

Publiez son port avec sbx ports. La commande sbx ports my-project --publish 3000:8080 associe le port 3000 de l'hôte au port 8080 de la sandbox, tandis que --publish 8080 seul choisit un port éphémère sur l'hôte. Votre navigateur ne peut pas atteindre les services de la sandbox tant que vous n'avez pas effectué cette opération. Le serveur de développement doit également écouter sur 0.0.0.0 plutôt que sur 127.0.0.1 : de nombreux frameworks nécessitent donc l'option --host 0.0.0.0.

L'agent peut-il lire d'autres répertoires sans pouvoir les modifier ?

Oui. Ajoutez des chemins supplémentaires après l'espace de travail principal et terminez chacun d'eux par :ro pour le passer en lecture seule, par exemple sbx run claude ~/project-a ~/shared-libs:ro ~/docs:ro. L'agent démarre dans le premier chemin. Chaque espace de travail apparaît dans la sandbox sous le même chemin absolu que sur votre hôte. Les espaces de travail supplémentaires sont montés directement depuis l'hôte, même lorsque l'espace de travail principal utilise le mode clone.

Comment récupérer les commits d'une sandbox en mode clone ?

Récupérez-les depuis le dépôt Git distant que sbx ajoute à votre dépôt hôte, nommé sandbox- suivi du nom de la sandbox. Faites ensuite un diff ou un merge comme avec n'importe quel dépôt distant. Le serveur Git du clone se trouve dans la sandbox : git fetch échoue donc lorsque la sandbox est arrêtée. La commande sbx rm supprime également ce dépôt distant. Récupérez ou poussez donc tout ce que vous souhaitez conserver avant de supprimer la sandbox.