Configuration du bac à sable Claude Code 2026

Un bac à sable Claude Code correctement configuré a réduit de 84 % les demandes de permission dans les données d’utilisation internes publiées par Anthropic, mais cette réduction ne signifie pas que les confirmations suffisent à protéger un poste de travail. (anthropic.com)

Conclusion opérationnelle : un dépôt connu peut être exécuté sur le Mac local après activation du bac à sable, restriction des fichiers, limitation du réseau et maintien des permissions minimales. En revanche, un dépôt inconnu qui installe des dépendances, utilise des outils MCP ou nécessite un accès réseau ne devrait pas rencontrer les clés SSH et les identifiants cloud du Mac principal. Dans ce cas, il faut basculer vers une machine virtuelle ou un Mac distant dédié.

Pour qui ce guide est utile

Ce parcours s’adresse aux développeurs qui analysent un projet open source ou une demande de fusion provenant d’une source inconnue, aux responsables qui autorisent Claude Code à lancer des tests et des outils MCP, ainsi qu’aux administrateurs qui préparent un nœud d’exécution isolé pour des agents de programmation.

Dernière mise à jour : 15 août 2026. Les informations techniques ont été vérifiées dans la documentation officielle de sécurité de Claude Code, la documentation du bac à sable, les avis de sécurité du dépôt officiel et la publication technique sur le confinement des agents. La recherche GhostApproval est présentée comme une analyse tierce, avec la réponse d’Anthropic conservée.

Avant le lancement : traiter le dépôt comme une entrée non fiable

Le scénario à éviter est simple : un développeur clone un dépôt externe, se place dans son répertoire, lance Claude Code, accepte rapidement la demande de confiance, puis laisse l’agent exécuter npm install, un script de préparation ou un hook Git. Le danger ne provient pas uniquement d’une commande générée par le modèle.

Un projet peut influencer l’exécution par plusieurs chemins :

• un fichier de configuration local qui modifie l’adresse de l’API ou le comportement de l’outil ;
• un hook Git ou un script prepare, postinstall ou équivalent ;
• un fichier CLAUDE.md qui contient des instructions présentées comme des règles de travail ;
• une déclaration de serveur MCP non vérifiée ;
• un lien symbolique dont le nom semble local alors que sa cible se trouve dans le dossier personnel ;
• une dépendance qui télécharge ou compile du code pendant l’installation ;
• une réponse réseau qui contient elle-même une instruction destinée à l’agent.

Un avis de sécurité officiel a documenté un cas où un dépôt malveillant pouvait modifier ANTHROPIC_BASE_URL et provoquer des requêtes avant l’affichage de la demande de confiance. La vulnérabilité concernait les versions antérieures à 2.0.65, avec une correction publiée dans cette version. (github.com)

La recherche GhostApproval publiée par Wiz a également décrit une situation où l’interface pouvait afficher le nom apparent d’un fichier alors que la cible réelle était un lien symbolique vers un fichier sensible. Anthropic a contesté le classement de ce scénario en le considérant comme extérieur à son modèle de menace, tandis que Wiz a indiqué qu’un avertissement sur les liens symboliques existait dans les versions récentes. Ce désaccord ne permet pas de conclure que toutes les versions sont exploitables ; il montre surtout qu’une fenêtre d’autorisation ne remplace pas une séparation technique. (wiz.io)

Avant de lancer Claude Code, il convient donc de :

• [ ] cloner le dépôt dans un répertoire temporaire qui ne contient aucun projet personnel ;
• [ ] inspecter les fichiers de configuration, les hooks, les scripts d’installation et les fichiers MCP ;
• [ ] rechercher les liens symboliques et vérifier leur cible réelle avec les outils du système ;
• [ ] lire les fichiers de dépendances sans lancer l’installation ;
• [ ] supprimer du périmètre les clés SSH, les certificats de signature et les variables de production ;
• [ ] vérifier que le dépôt est bien à jour avec la version corrigée de Claude Code ;
• [ ] commencer en lecture seule, sans compilation ni accès réseau.

Cette séquence est particulièrement importante pour les projets audio, vidéo ou de design qui téléchargent fréquemment des outils, des greffons, des bibliothèques natives ou des ressources volumineuses : la chaîne de dépendances peut être plus large qu’un simple fichier de code.

Première session : installer une frontière de permissions

Les permissions Claude Code et le bac à sable n’agissent pas au même niveau. Les permissions décident si un outil doit être accepté ; le bac à sable limite ce que le processus peut atteindre lorsqu’il s’exécute. La documentation française sur les permissions Claude Code décrit notamment les modes plan, default, acceptEdits et bypassPermissions, ainsi que les règles allow, ask et deny. (docs.anthropic.com)

Pour une première analyse, l’ordre recommandé est le suivant :

1. Mode plan pour lire l’architecture, repérer les dépendances et demander une liste d’actions sans modifier le dépôt.
2. Mode par défaut pour autoriser ponctuellement une lecture ou une commande dont l’effet est compris.
3. Mode d’acceptation des modifications uniquement après inspection du dépôt, et seulement pour une tâche limitée.
4. Mode de contournement des permissions à exclure pour un dépôt inconnu ; ce mode suppose un environnement déjà considéré comme sûr.

Les règles doivent être traitées comme une politique, non comme une liste de raccourcis destinée à éviter les confirmations. Une règle deny doit primer sur une règle allow lorsqu’un chemin ou un outil sensible est concerné. Les commandes Shell, les modifications hors répertoire de travail, les nouveaux serveurs MCP et les appels réseau doivent rester soumis à une validation explicite.

Exemple de politique de départ à adapter au projet :

{
  "permissions": {
    "deny": [
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Read(~/.config/**)",
      "Bash(curl *)",
      "Bash(wget *)",
      "mcp__inconnu__*"
    ],
    "ask": [
      "Bash(npm install *)",
      "Bash(pnpm install *)",
      "Bash(docker *)",
      "Bash(git push *)"
    ]
  }
}

Cette structure ne doit pas être copiée sans vérification de la syntaxe et de la version utilisée. Elle illustre la logique : refuser les chemins d’identifiants, demander une validation avant installation ou publication, et ne jamais déclarer automatiquement fiable un serveur MCP simplement parce qu’il est référencé par le projet.

Les administrateurs peuvent aussi contrôler les paramètres gérés au niveau de l’organisation. Pour une équipe, la configuration approuvée doit être versionnée séparément du dépôt analysé, afin qu’un projet externe ne puisse pas redéfinir silencieusement la politique de sécurité de l’environnement.

Première exécution : activer macOS Seatbelt et réduire les sorties

Le bac à sable de Claude Code s’appuie sur des mécanismes du système d’exploitation, dont macOS Seatbelt. Il couvre les commandes Bash ainsi que les scripts, programmes et sous-processus lancés par ces commandes. La séparation porte sur deux axes : le système de fichiers et le réseau. (anthropic.com)

La commande /sandbox permet d’ouvrir la configuration du bac à sable. La base de travail doit être limitée au répertoire temporaire du dépôt. Les chemins de sortie doivent être ajoutés uniquement lorsqu’un besoin est démontré, par exemple un dossier de rendu vidéo ou un cache de compilation qui ne contient aucune donnée personnelle.

Il faut distinguer trois cas :

• Lecture hors projet : certains outils de lecture peuvent encore demander ou obtenir un accès à des chemins extérieurs selon les règles définies ;
• Écriture hors projet : elle doit rester bloquée, sauf exception ponctuelle et documentée ;
• Réseau sortant : il doit être refusé par défaut, puis ouvert vers les domaines strictement nécessaires.

Anthropic précise que l’isolation des fichiers seule ne suffit pas : sans restriction réseau, un agent compromis pourrait lire une donnée accessible puis l’exfiltrer ; sans isolation des fichiers, il pourrait atteindre un secret avant de l’envoyer. (anthropic.com)

Une configuration de départ peut suivre cette checklist :

• [ ] activer /sandbox avant la première installation ;
• [ ] autoriser la lecture et l’écriture uniquement dans le répertoire de travail ;
• [ ] refuser les chemins contenant les clés, certificats, fichiers de configuration cloud et historiques de Shell ;
• [ ] n’autoriser que les domaines nécessaires à l’API, au registre de dépendances et au dépôt ;
• [ ] demander une validation à chaque nouveau domaine ;
• [ ] désactiver toute règle créée uniquement pour faire disparaître une erreur de connexion ;
• [ ] arrêter la session si le bac à sable devient indisponible au lieu de poursuivre en mode dégradé.

La liste des domaines doit rester précise. La documentation de configuration réseau indique que Claude Code a besoin de points de terminaison pour l’API, les métriques et les rapports d’erreur ; dans un environnement d’entreprise, ces sorties peuvent être placées derrière un proxy contrôlé. (docs.anthropic.com)

Dépendances et tâches longues : choisir le bon niveau d’isolation

Un Dev Container est utile pour reproduire une chaîne de compilation, figer des dépendances et éviter de polluer le système principal. Il ne constitue toutefois pas une VM par défaut. Un volume monté, un socket de conteneurs, un accès réseau large ou un privilège supplémentaire peuvent réintroduire une voie vers l’hôte.

Le bac à sable local, le Dev Container, la machine virtuelle et le Mac distant répondent donc à des besoins différents :

Le choix peut être fait avec les conditions suivantes :

• Si le dépôt est interne, déjà revu, sans dépendance inconnue et sans secret monté, alors le Mac local avec bac à sable actif est acceptable.
• Si le dépôt est public mais que l’analyse reste en lecture seule, alors commencer par le mode plan et un répertoire temporaire ; ne pas installer de dépendances au premier passage.
• Si l’installation nécessite un script, un compilateur natif ou un outil téléchargé, alors utiliser un Dev Container sans secrets ou une VM dédiée.
• Si l’agent doit travailler plusieurs heures, appeler des MCP ou accéder à des services externes, alors privilégier une VM ou un Mac distant isolé.
• Si le workflow exige Xcode, des simulateurs iOS, un outil audio macOS ou un logiciel de design indisponible dans un conteneur Linux, alors retenir un environnement Mac séparé.
• Si le dépôt requiert des clés de signature, un accès de production ou des droits d’écriture permanents, alors interrompre l’automatisation et mettre en place une chaîne d’identifiants temporaires et révocables.

La documentation de sécurité recommande elle-même d’envisager les Dev Containers et les machines virtuelles pour le contenu non fiable. Elle rappelle également qu’aucun serveur MCP tiers n’est audité par défaut : chaque serveur doit donc être traité comme un logiciel ajouté à la surface d’attaque. (docs.anthropic.com)

Pour préparer une station séparée, les équipes peuvent consulter la présentation des environnements Mac disponibles avec RUVCLOUD puis examiner l’accès à une station Mac dédiée. L’objectif n’est pas de présenter un Mac distant comme automatiquement sûr, mais de déplacer l’exécution vers un périmètre où les clés du poste principal ne sont pas présentes et où la reconstruction de l’environnement est possible.

Après l’exécution : vérifier, révoquer et reconstruire

La fin d’une session ne se résume pas à fermer le terminal. Le code peut être restauré avec Git, mais un appel réseau, une clé ajoutée, un paquet installé ou une modification du compte utilisateur constitue un effet externe qui ne disparaît pas avec un simple git reset.

Avant de conserver l’environnement, il faut examiner :

• [ ] git diff et les fichiers non suivis ;
• [ ] les nouveaux hooks, scripts et fichiers de configuration ;
• [ ] les changements dans .zshrc, .bashrc et les profils de Shell ;
• [ ] ~/.ssh/authorized_keys et les fichiers de configuration SSH ;
• [ ] les journaux d’installation et les commandes exécutées ;
• [ ] les connexions vers des domaines inattendus ;
• [ ] les serveurs MCP ajoutés pendant la session ;
• [ ] les processus persistants et les tâches planifiées ;
• [ ] les jetons utilisés, révoqués ou remplacés.

Pour une tâche ponctuelle, la destruction puis la reconstruction de l’environnement sont généralement plus fiables qu’un nettoyage manuel d’une instance qui a déjà exécuté du code inconnu. Les fichiers utiles doivent être exportés sous forme de diff ou d’archive vérifiée, puis l’instance doit être supprimée.

Trois décisions finales sont possibles :

• Conserver : le dépôt est identifié, aucune sortie anormale n’est observée et la politique peut être documentée ;
• Renforcer : le travail est utile, mais un chemin, un domaine ou un MCP doit être restreint avant la prochaine session ;
• Détruire : le dépôt a exécuté des scripts inattendus, l’origine des fichiers reste incertaine ou la traçabilité des identifiants n’est pas complète.

Questions fréquentes

Un dépôt inconnu peut-il être ouvert directement avec Claude Code ?

Il est préférable de l’ouvrir d’abord en lecture seule, dans un répertoire temporaire dépourvu de secrets. Les fichiers de configuration, les hooks et les liens symboliques doivent être examinés avant toute installation ou commande réseau. La demande de confiance confirme une intention de travailler dans le dossier ; elle ne certifie ni le contenu du dépôt ni l’innocuité de ses scripts.

Le bac à sable protège-t-il toujours les clés SSH ?

Non. Il limite l’accès lorsque les clés restent hors des chemins autorisés et que le réseau sortant est contrôlé. Une clé montée dans le projet, une exception approuvée hors bac à sable ou un serveur MCP déjà privilégié peut annuler cette protection. La règle opérationnelle est donc de ne pas placer de clé durable dans l’environnement d’un dépôt non vérifié.

Quand le Dev Container ne suffit-il plus ?

Le Dev Container devient insuffisant lorsque le projet exige des privilèges élevés, expose le socket du démon de conteneurs, monte le dossier personnel, utilise des volumes trop larges ou doit exécuter des binaires dont l’origine est inconnue. Dans ces situations, une VM dédiée ou un Mac distant sans accès au poste principal réduit davantage le rayon d’impact.

Faut-il autoriser automatiquement les commandes d’installation ?

Non pour la première exécution. Une installation peut lancer des scripts indirects, télécharger des binaires ou modifier le profil utilisateur. Il est préférable de lire la commande, de contrôler sa provenance, de vérifier le domaine contacté et de l’exécuter dans un environnement sans identifiants persistants. Une autorisation permanente ne doit être créée qu’après validation du dépôt et du besoin.

Comment savoir si l’environnement peut être réutilisé ?

Il faut comparer le diff, les fichiers non suivis, les processus, les profils Shell, les clés autorisées, les serveurs MCP et les journaux réseau avec l’état de référence. Si une modification ne peut pas être expliquée ou si un accès externe n’a pas été tracé, l’instance ne doit pas être réutilisée. La reconstruction est alors plus sûre qu’une simple restauration Git.

Du Mac principal au Mac dédié

Le Mac principal reste confortable, mais il concentre les clés SSH, les profils de Shell, les certificats de signature, les projets personnels et parfois des accès de production. Un Dev Container peut être mal monté, une permission peut être approuvée par fatigue et une tâche longue peut laisser une exception active plus longtemps que prévu. Pour des dépôts inconnus, ces défauts rendent le nettoyage manuel difficile à prouver.

Un Mac dédié dans RUVCLOUD ne rend pas un dépôt malveillant inoffensif par magie ; il offre toutefois un périmètre distinct pour les outils macOS, le développement iOS, le rendu audio ou vidéo et les tâches longues. La bonne décision consiste à confirmer d’abord les limites de fichiers, de réseau et de credentials, puis à créer un nœud temporaire lorsque la destruction et la reconstruction apportent une garantie plus claire que la poursuite sur le poste principal.