Exécuter Claude Code dangereusement (en toute sécurité)

• Comment utiliser en toute sécurité le flag --dangerously-skip-permissions de Claude Code
• Après avoir évalué plusieurs environnements d’exécution isolés comme Docker, les VM et Firejail, l’auteur conclut qu’une machine virtuelle (VM) basée sur Vagrant est la solution la plus adaptée
• Avec Vagrant, il est possible de conserver une isolation complète par VM, une configuration reproductible et le partage de dossiers locaux, tout en évitant les problèmes de Docker-in-Docker
• Claude Code est configuré pour manipuler librement le système avec les privilèges sudo dans la VM, et sert concrètement à lancer des web apps, configurer des bases de données et automatiser des tests
• Cette méthode est efficace pour éviter les dommages accidentels au système de fichiers et permet, si nécessaire, de réinitialiser proprement l’environnement en supprimant puis recréant la VM

---

Contexte

• Lors de l’utilisation de Claude Code, l’auteur a voulu éliminer l’inconvénient de devoir confirmer chaque demande d’autorisation en essayant le flag --dangerously-skip-permissions
  • Ce flag exécute automatiquement sans approbation préalable toutes les opérations, y compris l’installation de paquets, les changements de configuration ou la suppression de fichiers
  • C’est efficace car cela évite d’interrompre le flux de travail, mais cela comporte un risque de corruption du système de fichiers
• Pour l’éviter, il devient nécessaire d’exécuter Claude dans un environnement séparé du compte utilisateur de l’OS hôte

Méthodes envisagées

• L’isolation via Docker a d’abord été étudiée, mais comme Claude doit construire des images Docker et lancer des conteneurs, une configuration Docker-in-Docker est nécessaire
  • Dans ce cas, le mode --privileged est requis, ce qui annule l’intérêt du sandboxing
  • L’empilement réseau et les problèmes de permissions sur les montages de volumes augmentent aussi la complexité et l’instabilité
• Les autres alternatives examinées sont les suivantes
  • Exécution sur bare metal : des cas rapportés sur Reddit montrent des dommages graves, comme la suppression d’une base de données ou du répertoire personnel
  • sandbox-runtime : contrôle d’accès basé sur les ACL, empêchant Claude d’accéder à autre chose qu’au code, mais avec un manque de liberté totale
  • Firejail : présente des limitations similaires à Docker
  • Configuration manuelle d’une VM : manque de reproductibilité
  • VM dans le cloud : problèmes de coût, latence et nécessité d’uploader le code

Approche basée sur Vagrant

• Vagrant permet d’obtenir à la fois une isolation complète par VM et une configuration reproductible
  • Les dossiers partagés permettent un accès proche d’un usage local
  • Il n’y a pas de problème de Docker-in-Docker, et la VM peut être supprimée puis recréée facilement si besoin
• En utilisant VirtualBox 7.2.4, l’auteur a constaté un bug faisant monter le CPU à 100 %, puis en a confirmé la cause via une issue GitHub
• La configuration finale du Vagrantfile présente les caractéristiques suivantes
  • image de base bento/ubuntu-24.04
  • 4 Go de mémoire et 2 CPU alloués
  • installation de Docker, Node.js, npm, git et unzip
  • installation globale de @anthropic-ai/claude-code
  • ajout de l’utilisateur vagrant au groupe Docker

Utilisation concrète

• Depuis le répertoire du projet, exécuter vagrant up → vagrant ssh → claude --dangerously-skip-permissions
• Au premier démarrage, le provisioning prend quelques minutes et il faut se connecter à Claude une seule fois par projet
• En fin de travail, la VM peut être mise en veille avec vagrant suspend
• Dans la VM, Claude reçoit les privilèges sudo et peut effectuer les tâches suivantes
  • lancer l’API d’une web app et la vérifier avec curl
  • installer un navigateur, inspecter manuellement l’application et générer des tests E2E
  • configurer une base PostgreSQL et tester les migrations
  • construire et exécuter des images Docker
• Grâce à cet environnement, Claude peut exécuter des commandes, vérifier les sorties et gérer lui-même les itérations

Performances et sécurité

• Sur Linux + VirtualBox, les ressources sont largement suffisantes et il n’y a pas de latence de synchronisation des fichiers
• Ce qui peut être protégé
  • les dommages accidentels au système de fichiers
  • les installations de paquets incontrôlées et les modifications de configuration
• Ce qui ne peut pas être protégé
  • la suppression du dossier du projet (synchronisation bidirectionnelle)
  • les attaques exploitant une faille d’évasion de VM
  • les problèmes au niveau réseau
  • l’exfiltration de données (la VM a accès à Internet)
• Cette configuration sert à prévenir les accidents, et non à se défendre contre des attaques avancées
• Comme le projet repose sur Git, la récupération reste facile en cas de dommages ; si nécessaire, une synchronisation unidirectionnelle via rsync permet une isolation plus stricte

Conclusion

• Après résolution du bug CPU de VirtualBox, l’auteur obtient un environnement d’exécution sans friction
• Claude Code peut être exécuté librement dans un sandbox VM complet
• En cas de problème, il suffit de supprimer puis recréer la VM, avec une reproductibilité garantie par un simple Vagrantfile
• Si vous utilisez le flag --dangerously-skip-permissions, la mise en place d’un environnement isolé de ce type est fortement recommandée

[GN⁺]

Commentaires Hacker News

• Quand on utilise Claude, à terme on finit par simplement appuyer sur Entrée au bout de quelques mois à cause de la fatigue décisionnelle
  Du coup, j’ai l’impression qu’il est bien plus sûr de le faire tourner en mode YOLO tout en préparant un environnement sandboxé
  Sur Ubuntu 22.04, j’ai construit une sandbox en couches en combinant bubblewrap et Landlock LSM
  Landlock restreint l’accès au système de fichiers sur la base d’une liste blanche et contrôle aussi l’accès aux ports TCP
  bubblewrap isole les espaces de noms de montage pour créer un /tmp par projet et masquer les clés secrètes
  dnsmasq permet de définir une liste blanche DNS pour que seuls les domaines nécessaires puissent être résolus
  Grâce à cette architecture, le stress de devoir surveiller l’agent en permanence a diminué

  • Moi aussi, je faisais tourner plusieurs instances de Claude en mode YOLO dans un environnement similaire, et ça a été vraiment fatigant quand il a fallu compiler directement le plugin Emacs TRAMP sur un NUC local
    Devoir approuver un à un les morceaux d’elisp proposés par Claude a été une expérience vraiment épuisante
    Même en faisant seulement attention à ce que des commandes Bash n’installent pas n’importe quoi, c’était pénible
  • Je suis sur Windows donc je ne l’ai pas utilisé moi-même, mais il me semble que sous Linux, Claude Code intègre une fonction de sandboxing via la commande /sandbox

• C’est Srini de Docker
  Beaucoup de développeurs utilisent Docker pour résoudre ce problème, et nous avons aussi reçu beaucoup de retours sur les limitations de Docker-in-Docker
  Nous avons donc publié à titre expérimental Docker Sandboxes en version preview
  C’est encore très tôt, mais nous développons la prochaine version sur une base MicroVM afin d’éviter les problèmes de Docker-in-Docker

  • Je me demande comment Docker Sandbox résout le problème de Docker-in-Docker
    J’aimerais savoir si Claude peut lancer d’autres conteneurs sans privilèges à l’intérieur de Docker Sandbox

• La plupart des gens semblent vouloir éviter d’exécuter eux-mêmes une VM locale, mais je ne comprends pas pourquoi
  En réalité, une VM locale est ce qu’il y a de plus simple et ça résout tous les problèmes
  Si vous utilisez Docker sur Mac, vous tournez déjà au-dessus d’une VM Linux, donc il n’y a qu’une couche d’écart avec l’environnement réel
  On peut aussi se connecter directement en SSH depuis l’IDE pour inspecter le code
  J’active l’option --dangerously-skip-permissions et je traite tous les changements via des PR
  J’utilise ça avec workmux depuis plusieurs mois, et c’est très efficace parce que ça permet de gérer plusieurs PR en parallèle
  C’est préférable à une VM cloud, car faire tourner plusieurs conteneurs en même temps consomme beaucoup de mémoire
  Faire tourner une VM cloud haut de gamme 24/7 coûte beaucoup trop cher

• Même sans exploiter une faille d’évasion de VM, une IA malveillante peut obtenir un accès à l’hôte en ajoutant du code arbitraire dans un Vagrantfile
  Même si on ne s’inquiète que des erreurs banales, si Claude modifie les hooks de commit, cela peut poser problème au moment où ils s’exécutent
  J’ai l’impression qu’il est vraiment difficile de conserver une isolation complète tout en gardant un développement pratique

  • Il suffit d’enfermer Claude dans un sous-répertoire précis
    Par exemple, avec un montage de volume Docker on peut autoriser la modification du seul dossier sandbox/ et rendre .git inaccessible
  • Mais cela suppose de partager le répertoire dans les deux sens entre la VM et l’hôte
    Moi, je prends un snapshot, je lance une petite VM pour exécuter l’agent, puis je compare à nouveau les snapshots
    Je ne fais jamais de synchronisation automatique, car cela ruinerait l’objectif d’isolation
  • Un autre risque, c’est qu’un code malveillant soit ajouté au dépôt puis infecte la machine plus tard lorsqu’il est exécuté hors de la VM
  • « nœud ec2 ? »

• J’essaie une autre approche — intercepter ce que Claude veut exécuter
  Shannot capture l’intention avant l’exécution et intercepte les appels système dans une sandbox PyPy
  Les commandes et écritures de fichiers ne sont consignées que dans des logs et ne sont pas réellement exécutées
  Ce n’est qu’après examen et approbation dans une TUI par l’utilisateur qu’elles sont exécutées
  La différence avec une VM, c’est qu’une VM laisse tout s’exécuter librement dans un environnement totalement isolé, tandis que Shannot applique sur le système réel des changements basés sur une approbation humaine
  C’est adapté à des tâches comme la modification de serveurs
  Il y a aussi une intégration Claude MCP, l’exécution distante via SSH, et des fonctions de checkpoint/rollback

  • Cette approche ne résout pas directement le problème, mais j’ai l’impression qu’elle va dans une direction similaire aux mécanismes de contrôle intégrés de Claude Code
    Au final, la structure s’arrête dès la première demande d’approbation, donc l’agent ne peut pas explorer librement
    Ce que je veux, c’est que l’agent puisse aller jusqu’au bout sans s’arrêter en cours de route, puis qu’on évalue le résultat
    C’est là que le gain de temps est important
  • On dirait une philosophie similaire à Leash
    C’est proche du mode d’extension système natif Mac de Leash, mais il n’y a pas encore de vrai mode d’approbation interactif
    Projet intéressant
  • La partie « les commandes et écritures de fichiers ne sont consignées que dans des logs et ne sont pas réellement exécutées » est en fait une fonctionnalité déjà fournie par défaut par Claude
  • Le nom est vraiment bien trouvé

• Quand la fatigue liée aux validations s’accumule, on finit par avoir envie d’utiliser --dangerously-skip-permissions
  Du coup, j’exécute Claude Code dans un devcontainer
  L’accès aux fichiers est limité au dépôt et le réseau n’autorise qu’une liste blanche
  Ensuite, j’ai généralisé ça avec docker compose, et la prochaine étape est d’ajouter la prise en charge d’autres agents comme Codex ou OpenCode
  Je veux forcer le routage réseau via le proxy de l’hôte pour renforcer la journalisation et le contrôle
  Pour l’instant, je gère ça provisoirement avec iptables
  C’est encore tôt, mais ça fonctionne plutôt bien
  Code : agent-sandbox

  • J’expérimente aussi une configuration similaire
    J’utilise mitmproxy comme proxy réseau ; ce n’est pas encore parfait, mais on y est presque
  • Avec des amis, on a créé une appli en une soirée en vibe coding, en donnant à Claude les droits root sur un cluster de serveurs
    Claude a configuré seul le système pendant plusieurs heures et a terminé l’application
    Nous n’avons pas écrit une seule ligne de code et le résultat était étonnamment bon
    La vitesse du développement par IA est vraiment impressionnante

• Ma solution est simple

  sandbox-run npx @anthropic-ai/claude-code
  

  De cette façon, la commande npx s’exécute de manière transparente dans une sandbox Bubblewrap, et seul le répertoire courant est exposé
  Cela peut se faire avec quelques lignes de shell POSIX pur
  sandbox-run

  • J’aime bien l’approche Bubblewrap, mais c’est dommage que ce soit réservé à Linux
    Un autre inconvénient est qu’une fois les privilèges abandonnés, on ne peut pas les récupérer

• Moi, je le mets simplement dans un conteneur LXC non privilégié et c’est réglé
  Mon modèle de menace porte moins sur les attaques complexes que sur le cas où « il supprime par erreur mon répertoire personnel »

• Je place des scripts utilitaires dans le répertoire run/ du projet et je lance les conteneurs sur une base compose
  Le devcontainer est mappé avec le répertoire hôte et des volumes
  Claude gère bien la configuration des services, la mise à jour des scripts et le diagnostic des problèmes d’exécution
  Il n’y a pas d’intégration navigateur, mais avec Playwright ou Puppeteer, ça devrait largement être faisable

• J’aimerais avoir des avis sur le sandboxing intégré de Claude Code
  Lien vers la documentation officielle
  Claude Code dispose d’une porte de sortie permettant de désactiver la sandbox si nécessaire
  Si une commande échoue à cause des restrictions de la sandbox, Claude peut analyser la cause et réessayer avec dangerouslyDisableSandbox
  Le fait que l’agent puisse désactiver lui-même la sandbox ressemble à une faille potentielle ; je me demande s’il y a dans ce cas une procédure d’approbation par l’utilisateur

  • Malheureusement, il arrive parfois qu’il contourne les demandes de confirmation de l’utilisateur
    Issues liées : #14268, #13583, #10089