Best apps for sandboxing AI coding agents

Le bon instinct après avoir vu Claude Code, Cursor ou Aider fonctionner est de donner à l’agent plus de permissions. Le mauvais résultat est un dotfile réécrit et une branche non commitée sur le mauvais dépôt. Les meilleures applications pour sandboxer les agents de codage IA sur le bureau sortent l’agent du système de fichiers hôte et le mettent dans un conteneur ou une VM où une action erronée ne touche pas l’ordinateur portable. L’astuce est de choisir une dont le temps de démarrage est quelques secondes, pas quelques minutes, pour qu’un bac à sable devienne la norme et non l’exception. Nous en avons examiné sept.

Ce qu’il faut chercher dans un bac à sable d’agent IA

Six choses comptent:

Comparaison rapide

Application Meilleur pour Isolation Démarrage Forfait gratuit Point fort
Docker Desktop Écosystème le plus large Conteneurs ~5s Personnel + petites entreprises Ce que les agents supposent
Podman Desktop Conteneurs sans root Conteneurs ~4s Gratuit, toujours Pas de daemon; pods de première classe
Colima Terminal uniquement sur macOS Conteneurs ~4s Gratuit, toujours CLI Docker, pas de Docker Desktop
OrbStack Plus rapide sur macOS Conteneurs + VM légers ~2s Personnel gratuit Démarrage en 2 secondes
Multipass VM Ubuntu réelles VM matériel ~15s Gratuit, toujours VM complète, maintenue par Canonical
UTM N’importe quel OS dans une VM sur macOS VM matériel ~20s Gratuit, payant sur App Store Exécute ARM Linux, Windows, plus
Firecracker MicroVM au niveau du noyau MicroVM <1s Gratuit, toujours Chaque tâche dans sa propre VM

Les applications

1. Docker Desktop, meilleur par défaut

Docker Desktop est le bac à sable que la plupart des agents supposent pouvoir atteindre. Il regroupe le daemon, la CLI, une petite VM Linux (LinuxKit), Compose et Kubernetes. Pointez Claude Code, Aider ou Cursor vers docker.sock et l’agent peut générer ses propres conteneurs pour exécuter des tests, installer des deps et itérer. Le moteur de partage de fichiers par défaut (VirtioFS dans les versions modernes) est suffisamment rapide pour une vraie journée de travail.

Où il échoue: La licence a changé il y a quelques années. L’utilisation personnelle et les petites entreprises sont gratuites; les grandes organisations ont besoin d’un forfait payant. Sur les machines à faible RAM, l’empreinte VM est notable.

Prix:

Plates-formes: Windows, macOS, Linux.

Télécharger: Docker Desktop

Résumé: Commencez ici sauf si une exigence spécifique l’exclut. Chaque outil d’agent sait comment parler avec lui.

2. Podman Desktop, meilleure voie de conteneur sans root

Podman Desktop est l’alternative sans daemon et sans root de Docker. Les conteneurs s’exécutent en tant qu’utilisateur actuel, ce qui réduit considérablement le rayon d’explosion par rapport aux conteneurs Docker détenus par root sur Linux. Les pods (plusieurs conteneurs partageant un namespace réseau) sont de première classe, ce qui convient aux agents qui lancent un service et un client ensemble.

Où il échoue: Certains fichiers Compose supposent toujours la sémantique Docker; occasionnellement, il y a des cas extrêmes en réseau qui nécessitent des ajustements de configuration podman-compose.

Prix: Gratuit, Apache-2.0.

Plates-formes: Windows, macOS, Linux.

Télécharger: Podman Desktop

Résumé: Le choix sur Linux où sans root importe, et sur tout hôte qui veut une pile entièrement open-source.

3. Colima, meilleure voie terminal uniquement sur macOS

Colima exécute une VM Linux légère sur macOS avec Docker ou le runtime containerd à l’intérieur. Pas de GUI: la CLI suffit. Le démarrage est rapide, l’utilisation des ressources est faible et la CLI docker standard fonctionne avec elle sans changement.

Où il échoue: Pas de GUI, pas d’interface utilisateur compose, pas de raccourci preset Kubernetes. Les utilisateurs qui veulent un tableau de bord devraient regarder ailleurs.

Prix: Gratuit, licence MIT.

Plates-formes: macOS, Linux.

Télécharger: GitHub

Résumé: Le choix pour un développeur Mac qui vit dans le terminal et ne veut pas Docker Desktop.

4. OrbStack, meilleure vitesse brute sur macOS

OrbStack amorce un conteneur compatible avec Docker en environ deux secondes sur un Mac Apple Silicon moderne et amorce une VM Linux complète en cinq. Il utilise moins de RAM au repos que Docker Desktop et s’intègre assez bien au système de fichiers macOS pour que les volumes montés se sentent natifs. Les agents dans des boucles serrées (test, refactorisation, retest) bénéficient de la différence de démarrage.

Où il échoue: macOS uniquement. Gratuit pour un usage personnel; l’usage commercial nécessite une licence.

Prix:

Plates-formes: macOS.

Télécharger: OrbStack

Résumé: Le choix sur macOS quand la vitesse de démarrage fait ou casse la boucle de l’agent.

5. Multipass, meilleure voie VM Ubuntu réelle

Multipass est l’outil de Canonical pour faire tourner des VM Ubuntu configurées avec cloud-init à partir d’une commande. Une VM n’est pas un conteneur: le noyau, cgroups et tout le reste sont isolés. Cela importe quand un agent doit installer des modules kernel, exécuter des règles udev ou tester le comportement réseau qu’un conteneur ne peut pas reproduire.

Où il échoue: Les VM démarrent en dizaines de secondes, pas une. L’empreinte RAM est plus élevée par environnement.

Prix: Gratuit, GPL-3.0.

Plates-formes: Windows, macOS, Linux.

Télécharger: Multipass

Résumé: Le choix quand la tâche a besoin d’un système Linux complet, pas un conteneur.

6. UTM, meilleur “n’importe quel OS dans une VM” sur macOS

UTM enveloppe QEMU sur macOS avec une interface propre. Il exécute ARM Linux, x86 Linux (via émulation), Windows sur ARM et des systèmes d’exploitation invités moins courants. Les agents qui ont besoin de tester sur une cible qui n’est pas l’architecture native du développeur vivent ici.

Où il échoue: L’émulation x86 sur Apple Silicon est nettement plus lente que les invités ARM. Pas un premier choix pour une itération rapide.

Prix:

Plates-formes: macOS (également iOS/iPadOS via TestFlight).

Télécharger: UTM

Résumé: Le choix quand la cible de l’agent est Windows-on-ARM, ARM Linux ou une image distro spécifique que l’hôte ne peut pas exécuter nativement.

7. Firecracker, meilleure microVM

Firecracker est la technologie microVM qu’AWS utilise pour Lambda et Fargate. Il amorce une tiny hardware VM en moins de 125 ms. Envelopper chaque action de l’agent dans une microVM fraîche est l’isolation la plus forte de cette liste: le bac à sable n’a pas de persistence entre les exécutions par défaut.

Où il échoue: Ce n’est pas une application de bureau en soi. Il est livré en tant que binaire qui attend un orchestrateur (Ignite, Weaveworks ou un wrapper fait maison). S’exécute sur Linux uniquement.

Prix: Gratuit, Apache-2.0.

Plates-formes: Linux.

Télécharger: GitHub

Résumé: Le choix pour une équipe de recherche qui veut chaque tâche d’agent dans sa propre VM jetable et qui a les compétences ops pour la connecter.

Comment choisir le bon bac à sable

Si l’objectif est “faire fonctionner un agent aujourd’hui avec le moins de friction possible”: Docker Desktop. Tout le suppose.

Si open-source et sans root importent: Podman Desktop.

Si macOS et la vitesse importent: OrbStack pour les conteneurs, Colima pour un flux de travail terminal uniquement.

Si la tâche a besoin d’une vraie VM Linux (modules kernel, réseau, comportement systemd): Multipass.

Si le système d’exploitation cible n’est pas le système d’exploitation hôte: UTM sur macOS.

Si l’objectif est l’isolation par tâche, jetable avec microVM: Firecracker avec une petite couche d’orchestration.

FAQ

Un agent IA a-t-il vraiment besoin d’un bac à sable? Oui. Les agents sont pilotés par des invites; les invites contiennent des cas extrêmes. Un bac à sable est la police d’assurance bon marché: au pire, un conteneur est supprimé, pas un répertoire personnel.

Comment laisser l’agent voir mon dépôt sans lui donner tout mon répertoire personnel? Bind-montez uniquement le répertoire du projet dans le conteneur, en lecture-écriture; laissez le reste du système de fichiers hôte en dehors du montage. VS Code Dev Containers, docker run -v $(pwd):/work et devcontainer.json le font tous.

Le bac à sable peut-il accéder à Internet? Par défaut, oui. Pour restreindre la sortie, utilisez --network none de Docker pour une isolation complète ou un réseau personnalisé avec des règles iptables. Firecracker supporte les network taps qui peuvent être fortement configurés.

Combien de RAM le bac à sable devrait-il obtenir? Donnez à un conteneur 4 GB de mémoire comme minimum pour tout ce qui exécute une installation de package et une build. Les VM (Multipass, UTM) commencent par 2 GB mais 8 GB est plus sûr pour Linux avec une chaîne d’outils moderne.

Quel est le moyen le plus rapide de réinitialiser le bac à sable entre les exécutions? docker compose down && docker compose up -d pour les conteneurs; multipass restart ou multipass purge pour les VM. La réponse de Firecracker est “amorcer une nouvelle microVM”; c’est tout l’intérêt.

Une VM est-elle plus sûre qu’un conteneur? Oui, et de loin pour les charges de travail adversariales. Une VM a son propre noyau; un conteneur partage le noyau hôte. Pour les agents que vous avez écrits et en qui vous faites confiance, un conteneur suffit généralement. Pour le code non fiable d’un modèle qui vient de télécharger un package, une VM est le choix plus sûr par défaut.