Yolobox – exécuter des agents de codage IA avec des privilèges complets tout en protégeant le répertoire personnel

• Outil permettant d’exécuter des agents de codage IA avec les privilèges complets du système tout en bloquant le risque d’endommager le répertoire personnel
• Les principaux CLI IA comme Claude Code, Codex, Gemini CLI, OpenCode sont préconfigurés et peuvent être lancés en mode « YOLO »
• Monte uniquement le répertoire du projet dans un conteneur Docker ou Podman, en excluant par défaut le répertoire personnel
• Fournit des privilèges sudo et des volumes persistants dans le conteneur afin de conserver les outils et les réglages entre les sessions
• Offre un environnement sandbox isolé pour permettre aux développeurs d’expérimenter en toute sécurité les fonctions d’automatisation par IA

---

Vue d’ensemble

• Yolobox est un outil qui exécute des agents de codage IA à l’intérieur d’un conteneur afin de protéger le système tout en leur accordant des privilèges d’exécution complets
  • Même si l’IA exécute par erreur une commande destructive comme rm -rf ~, le répertoire personnel n’est pas affecté
  • Le répertoire du projet est monté sur /workspace, tandis que le répertoire personnel n’est pas monté par défaut
  • Les outils et réglages sont conservés entre les sessions grâce à des volumes persistants

Configuration et fonctionnalités principales

• À l’intérieur du conteneur, l’agent IA dispose des privilèges sudo et peut exécuter librement des commandes
• L’image de base inclut les éléments suivants
  • CLI IA : Claude Code, Gemini CLI, OpenAI Codex, OpenCode (tous configurés en mode d’exécution automatique)
  • Environnement de développement : Node.js 22, Python 3, make, cmake, gcc, Git, GitHub CLI
  • Utilitaires : ripgrep, fd, fzf, jq, vim
• Si nécessaire, l’utilisateur peut installer lui-même des paquets supplémentaires avec sudo

Exécution et commandes

• Entrée dans le shell sandbox avec la commande yolobox
• Exécution possible d’une commande unique avec yolobox run
• Commandes de gestion disponibles : yolobox upgrade, yolobox config, yolobox reset --force, yolobox version
• Principaux drapeaux
  • --runtime : choisir docker ou podman
  • --no-network : désactiver le réseau
  • --readonly-project : monter le projet en lecture seule
  • --claude-config : copier la configuration Claude de l’hôte dans le conteneur

Modèle de sécurité

• Utilise l’isolation du conteneur comme frontière de sécurité
  • Le conteneur isole le système de fichiers, les processus et le réseau via les espaces de noms Linux
  • L’IA dispose des privilèges root dans le conteneur, mais ne peut pas accéder au système extérieur
• Éléments protégés
  • Répertoire personnel, clés SSH, identifiants, dotfiles, autres projets, fichiers système de l’hôte
• Éléments non protégés
  • Répertoire du projet (accessible en lecture/écriture par défaut)
  • Accès réseau (peut être bloqué en option)
  • Vulnérabilités du noyau ou attaques d’évasion de conteneur

Étapes de renforcement de la sécurité

• Mode par défaut : isolation standard par conteneur
• Étape 2 : réduction de la surface d’attaque avec les options --no-network --readonly-project
• Étape 3 : utilisation de Rootless Podman pour supprimer les privilèges root sur l’hôte
  • Le root du conteneur est mappé à un utilisateur normal de l’hôte, ce qui minimise les dégâts en cas d’évasion
• Étape 4 : exécution dans une VM pour supprimer le partage du noyau
  • Sur macOS : UTM, Parallels, Lima ; sur Linux : Podman machine ou une VM dédiée

Isolation réseau

• Rootless Podman utilise par défaut le réseau slirp4netns, isolé du réseau de l’hôte
• Le paramètre allow_host_loopback=false permet de bloquer l’accès au réseau local

Licence et autres informations

• Distribué sous licence MIT
• Répartition des langages du dépôt : Go 75.9 %, Dockerfile 13.6 %, Shell 8.7 %, Makefile 1.8 %
• Le nom « Yolobox » vient de l’esprit « YOLO (You Only Live Once) » et désigne un environnement où l’on peut exécuter l’IA librement tout en restant isolé en toute sécurité

[GN⁺]

Commentaires Hacker News

• J’ai récemment créé un projet similaire appelé Litterbox (site de démo)
  C’est uniquement pour Linux, car il dépend de Podman. En contrepartie, il a des avantages adaptés à mon usage

  • Il expose le socket Wayland, ce qui permet d’exécuter tout l’environnement de développement, y compris l’éditeur, dans le conteneur. Cela protège contre les vulnérabilités des extensions d’éditeur
  • Il fournit un agent SSH spécial qui demande une confirmation à l’utilisateur à chaque signature. Ainsi, un code malveillant ne peut pas utiliser discrètement l’accès à GitHub
  • Il dispose aussi d’une fonction pour activer facilement des permissions nécessaires uniquement dans certains cas précis, comme la création de périphériques TUN/TAP
  • Ce n’est pas encore disponible, mais une intégration SELinux est en préparation

• J’expérimentais moi aussi quelque chose de similaire.
  Ce serait bien que le README explique clairement le fonctionnement et les frontières de confiance (basées sur les conteneurs Docker). Le risque d’évasion du conteneur existe toujours, car des vulnérabilités du noyau peuvent être exploitées
  J’utilise Rootless Podman et slirp4netns pour réduire au minimum l’accès réseau.
  L’étape suivante serait d’utiliser Podman machine pour isoler complètement le noyau, mais les montages de volumes fonctionnent mal

  • Merci pour le retour. J’ai étoffé le README → lien du commit

• Quelqu’un propose d’ajouter les trois lois de la robotique d’Asimov dans agents.md ou claude.md

  1. Ne pas casser le programme ni le laisser se détériorer par inaction
  2. Obéir aux instructions tant que cela ne contredit pas la 1re loi
  3. Préserver la sécurité tant que cela ne contredit pas les 1re et 2e lois
  • Dans l’œuvre originale, ces lois sont immédiatement mises en échec ; l’intention était de montrer la complexité de la société humaine
  • On dirait que vous n’avez pas vu I, Robot. Mettre ce genre de règles dans claude.md revient à injecter mentalement ce concept au modèle. Les anciens modèles, par exemple, si on leur disait de ne pas utiliser le mot « éléphant », produisaient au contraire des résultats étranges en essayant de l’éviter
  • L’interprétation ambiguë de chaque loi laisse de nombreuses failles. Par exemple, une « dégradation des performances » compte-t-elle comme une casse ? Quel est le seuil d’un « problème de sécurité » ? Au final, il peut toujours s’en sortir avec quelque chose comme « les tests passent, donc ça va »
  • Coquille : Tenet

• Je recommande de jeter un œil à Shai. Ça s’exécute en local et permet de contrôler les permissions d’accès aux répertoires ainsi que le trafic réseau

  • Je suis le créateur de Shai. Le contrôle d’accès des agents devient de plus en plus important. Les agents ont facilement tendance à franchir les limites pour satisfaire l’utilisateur. Par exemple, ils peuvent mal gérer les identifiants de l’environnement local
    shai -rw . autorise la lecture/écriture dans le répertoire courant, et shai -u root permet de l’exécuter sous un autre utilisateur
    Shai suit une philosophie de refus par défaut, autorisation explicite (opt-in). Je recommande de partager .shai/config.yaml dans le dépôt afin que toute l’équipe utilise la même configuration
  • J’ai moi aussi créé un outil similaire, ctenv. Il n’est pas dédié à un agent spécifique, mais offre une configuration très flexible. La prise en charge d’images arbitraires et de scripts d’entrypoint personnalisés est plus pratique que devcontainer
  • Beau projet, mais l’approche est différente de la mienne. Par défaut, Yolobox autorise les droits sudo et l’accès complet au réseau. Si besoin, on peut les bloquer avec --no-network

• Je développe yolo-cage. Là où Yolobox se concentre sur la protection de la machine locale, yolo-cage met l’accent sur la prévention des fuites de secrets et la collaboration multi-agents
  Il s’exécute sur Kubernetes et analyse tout le trafic sortant pour empêcher la fuite de clés API ou de tokens.
  Il impose l’isolation des branches Git afin qu’un agent ne puisse pas fusionner sa propre PR — « l’agent propose, l’humain approuve »
  Il intègre aussi un framework de test d’évasion qui pousse Claude à tenter de s’échapper lui-même. Le prompt correspondant se trouve dans le dépôt, afin de vérifier que l’agent est authentique

  • Pour les tests d’évasion, je recommande Gemini. Claude s’est limité à des tentatives superficielles, alors que Gemini a été bien plus créatif. Je me demande même s’il faut vraiment l’en empêcher

• Je me demandais pourquoi il fallait marquer les commits avec « claude ». On n’indique pas l’OS ni la version de vim comme ça. Un LLM n’est au fond qu’un outil qui compile de l’anglais en code

  • L’OS ou le compilateur exécutent exactement ce que demande l’utilisateur, mais un LLM peut produire un résultat subtilement erroné tout en ayant l’apparence d’un code correct. Il peut même être malveillant. C’est pourquoi il faut signaler qu’un commit a été rédigé par un LLM afin de renforcer la revue
  • Je confie directement les commits à Claude Code. L’agent exécute les commandes et modifie le code, puis je fais la revue et les tests
  • J’utilise un hook pour faire un commit automatique à chaque itération, ce qui permet de revoir facilement « ce que Claude vient de faire »

• J’ai moi aussi tenté quelque chose de similaire. J’ai créé Toadbox, avec un peu plus de fonctions de confort

• On parle beaucoup de sandbox pour l’IA, mais en réalité Claude Code, Codex et Gemini CLI ont déjà une sandbox intégrée

  • Sur macOS, c’est seatbelt ; sur Linux, bubblewrap (Claude), seccomp+landlock (Codex) ; et sur Windows, AppContainer est en cours d’expérimentation
  • C’est intéressant, mais on ne sait pas clairement si cette sandbox se contente de restreindre l’accès à certains fichiers, ni si elle s’applique aussi lors de l’exécution de commandes système. Si elle n’isole que le processus de l’agent, son efficacité pourrait être limitée

• J’implémente quelque chose de similaire avec Apple Container Framework. Je me demandais si vous y aviez déjà jeté un œil

  • Apple Container est plus proche d’un remplaçant de Docker ou de Colima, et chaque conteneur fonctionne comme une VM distincte, à la manière de Kata Containers. C’est une bonne chose de voir des efforts pour améliorer les conteneurs sur macOS
    En revanche, il manque de compatibilité avec l’API Docker et de composabilité. J’ai résumé une discussion à ce sujet ici
    À l’origine, je voulais faire tourner Shai au-dessus d’Apple Container, mais j’ai abandonné à cause de problèmes de packaging
  • Je ne l’ai pas encore utilisé, mais ça m’intéresse. Yolobox propose une image avec les principaux CLI d’agents de codage préinstallés. J’aimerais créer « l’image ultime pour le vibe coding ». Je me demande si vous appliquez une configuration particulière à vos images

• Je construis moi aussi quelque chose de similaire → sandbox-codex
  C’est encore en cours, et la lisibilité des logs tmux n’est pas très bonne. Comme Docker n’est pas une sandbox complète, je l’exécute dans VirtualBox

  • J’ai également créé simple-npm-sandbox, mais uniquement pour Node.js. C’est simple, mais ça a été une bonne expérience d’apprentissage