Qu'est-ce que le bac à sable de Claude Code ? Isolement fichiers et réseau pour une automatisation sûre (2026)

Utilisez Claude Code suffisamment longtemps et vous tombez sur ce dilemme. Il demande « puis-je exécuter ceci ? » à chaque commande, et votre rythme cale sans cesse. Mais désactiver toutes les demandes avec --dangerously-skip-permissions (contournement des permissions) signifie qu'une injection de prompt ou une fausse manœuvre pourrait toucher des fichiers partout sur votre machine. Sécurité contre automatisation — longtemps considéré comme un compromis inévitable.

Ce qui casse ce binaire, c'est le bac à sable. Si vous délimitez « ce qui peut être touché » au niveau de l'OS en amont, les commandes peuvent s'exécuter librement à l'intérieur de la clôture sans demandes, sans que rien ne puisse atteindre l'extérieur. Cet article expose, du point de vue d'un praticien, ce que le bac à sable de Claude Code isole et comment, comment démarrer avec /sandbox, comment le configurer dans settings.json, en quoi il diffère des modes de permission, et les limites auxquelles il ne faut pas trop se fier.

1. Pourquoi vous avez besoin d'un bac à sable

Claude Code est un agent IA qui agit réellement — exécuter des tests, réécrire des fichiers. C'est précisément pour cela qu'il s'arrête pour demander « puis-je exécuter ceci ? » avant les commandes risquées. Pour la sécurité, c'est correct. Mais quand des dizaines de demandes tombent dans une journée, le travail se fragmente, et au bout d'un moment vous appuyez sur Entrée sans lire. C'est la « fatigue des permissions ».

Un développeur fatigué se tourne vers --dangerously-skip-permissions (surnommé le mode YOLO), qui désactive toutes les demandes. C'est confortable et — comme son nom l'indique — dangereux. Trois menaces montrent les crocs d'un coup.

L'idée du bac à sable est simple : cesser de demander « que dois-je confirmer ? » à chaque fois, et délimiter en amont « jusqu'où cela peut-il atteindre ? ». La clôture n'est pas imposée par le jugement propre de Claude mais par l'OS (le noyau), de sorte que même s'il est détourné, et même si une commande autorisée fait plus que ce que son nom suggère, rien ne s'échappe de la limite. C'est pourquoi les commandes à l'intérieur de la clôture peuvent s'exécuter sans danger sans demandes — le binaire fatigue-contre-contournement-total disparaît. Dans son article d'ingénierie officiel, « Making Claude Code more secure and autonomous with sandboxing », Anthropic rapporte qu'en usage interne il a réduit en toute sécurité les demandes de permission de 84 % (publié en octobre 2025).

2. Ce qu'est le bac à sable — deux isolements

Le bac à sable de Claude Code trace deux limites autour des commandes Bash (et de chaque processus enfant qu'elles engendrent). Les deux doivent fonctionner ensemble — l'une seule laisse une faille (voir §7).

Le point crucial, c'est qu'il ne repose pas sur le bon comportement de Claude. La limite est imposée par les propres mécanismes de sécurité de l'OS — macOS utilise Seatbelt intégré, Linux/WSL2 utilise bubblewrap. Ainsi la même limite s'étend aux scripts qu'une commande invoque et aux processus petits-enfants. Voyez-le non comme une requête polie adressée au modèle, à l'image des garde-fous de l'IA, mais comme un mur physique qui tient mécaniquement.

3. Pour commencer — /sandbox et les OS pris en charge

Le bac à sable est intégré à Claude Code. Aucun compte ni outil supplémentaire n'est requis. Dans une session, lancez :

/sandbox

Un panneau s'ouvre avec trois onglets. Mode (comment les commandes en bac à sable sont approuvées — section suivante), Overrides (si une commande qui échoue sous le bac à sable peut se rabattre sur une exécution hors bac à sable) et Config (afficher les réglages résolus). Sous Linux/WSL2, si un paquet requis manque, un onglet Dependencies apparaît à la place et vous indique ce qu'il faut installer.

Prérequis par OS

Sous Linux/WSL2, installez bubblewrap (l'outil de mise en bac à sable sans privilèges qui impose l'isolement du système de fichiers) et socat (le relais qui route le trafic vers le proxy).

# Ubuntu / Debian
sudo apt-get install bubblewrap socat

# Fedora
sudo dnf install bubblewrap socat

Une chose pratique à activer est le filtre seccomp (qui ajoute le blocage des sockets de domaine Unix). C'est optionnel ; installez-le avec npm install -g @anthropic-ai/sandbox-runtime. L'onglet Dependencies de /sandbox affiche l'état de ripgrep, bubblewrap, socat et du filtre seccomp. Après avoir installé les paquets, redémarrez Claude Code et rouvrez /sandbox (la vérification s'exécute au démarrage).

4. Les deux modes (auto-autorisation / normal)

L'onglet Mode choisit comment les commandes à l'intérieur du bac à sable sont approuvées.

Dans les deux modes, les limites du système de fichiers et du réseau sont identiques ; la seule différence est « auto-autorisation contre demande ». Notez que même en mode auto-autorisation, ces soupapes de sécurité restent actives :

• Les règles de refus explicites priment toujours
• rm / rmdir visant /, votre répertoire personnel ou d'autres chemins système critiques déclenchent toujours une demande
• Les règles ask ciblées sur le contenu comme Bash(git push *) forcent toujours une demande, même à l'intérieur du bac à sable

5. Le configurer dans settings.json

Les choix faits dans le panneau /sandbox sont écrits dans le .claude/settings.local.json du projet (non versionné dans git). Pour le garder toujours actif sur tous les projets, placez sandbox.enabled: true dans vos réglages utilisateur à ~/.claude/settings.json. Il appartient à la même famille settings.json que les règles de permission (allow/ask/deny).

Ajouter des cibles d'écriture, refuser des lectures

Par défaut, vous ne pouvez écrire que dans le répertoire de travail et le dossier temporaire. Si kubectl ou terraform a besoin d'écrire ailleurs, ajoutez des chemins avec allowWrite. Inversement, vous pouvez bloquer les lectures de dossiers sensibles.

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "allowWrite": ["~/.kube", "/tmp/build"],
      "denyRead": ["~/"],
      "allowRead": ["."]
    }
  }
}

L'exemple ci-dessus refuse les lectures de tout le répertoire personnel tout en autorisant le projet en cours (. se résout à la racine du projet lorsque la configuration réside dans les réglages du projet). Les chemins sont imposés au niveau de l'OS, donc ils s'appliquent également aux processus enfants comme npm et terraform.

Protéger les identifiants

Un piège important : la valeur par défaut pour les lectures est « largement autorisée », donc ~/.aws/credentials et ~/.ssh/ sont lisibles tels quels. Le réglage dédié sandbox.credentials (une fonctionnalité relativement récente) déclare les fichiers dont la lecture est à refuser et les variables d'environnement à supprimer.

{
  "sandbox": {
    "enabled": true,
    "credentials": {
      "files": [
        { "path": "~/.aws/credentials", "mode": "deny" },
        { "path": "~/.ssh", "mode": "deny" }
      ],
      "envVars": [
        { "name": "GITHUB_TOKEN", "mode": "deny" }
      ]
    }
  }
}

Autoriser des destinations

Le réseau démarre avec zéro destination. Un nouveau domaine déclenche une demande la première fois qu'il est atteint (dans les versions récentes au moment de la rédaction, approuver une fois signifie ne plus être re-sollicité pour le reste de la session). Pré-enregistrez les hôtes pour lesquels vous ne voulez pas être sollicité dans allowedDomains. Avec des réglages gérés distribués par l'organisation, vous pouvez aussi bloquer automatiquement tout ce qui est hors de la liste d'autorisation au lieu de déclencher une demande.

{
  "sandbox": {
    "enabled": true,
    "network": {
      "allowedDomains": ["*.github.com", "registry.npmjs.org"]
    }
  }
}

6. Relation avec les modes et règles de permission

Ils sont faciles à confondre, mais les mécanismes de sécurité de Claude Code comportent trois couches aux rôles distincts. Le bac à sable est l'une d'elles — il ne remplace pas les deux autres ; il les complète.

La différence décisive tient au « quand et par qui » chacune prend effet. Les règles et modes de permission sont décidés avant l'exécution, par Claude Code, à partir de la chaîne de commande. Le bac à sable lie le processus pendant l'exécution, par l'OS — de sorte que quel que soit le choix du modèle, et même si une commande autorisée fait plus que ce que son nom implique, la limite ne bouge pas.

C'est aussi l'écart décisif avec --dangerously-skip-permissions (contournement). Le contournement ne fait que supprimer les demandes ; l'environnement reste grand ouvert. L'auto-autorisation du bac à sable, en revanche, peut sauter les demandes parce que le mur de l'OS est là. L'ancienne règle d'or — si vous utilisez le mode contournement, uniquement à l'intérieur d'un conteneur ou d'une VM isolés — est quelque chose que le bac à sable vous permet de déplacer du côté sûr même sur votre machine de tous les jours.

7. Limites et mises en garde — ne lui faites pas trop confiance

Le bac à sable est puissant, mais ce n'est pas un isolement complet. Avant de vous appuyer dessus comme sur une limite de sécurité stricte, connaissez les limites que la documentation détaille.

Une chose de plus à intérioriser : la portée se limite à Bash — les Read/Edit/Write intégrés, les serveurs MCP et les hooks sont à part. Pour isoler le processus entier, y compris les Skills et le MCP, enveloppez le processus Claude Code lui-même avec l'outil open source officiel @anthropic-ai/sandbox-runtime (publié sur GitHub et npm, un aperçu de recherche sorti en octobre 2025). Son rôle pratique n'est pas un « mur » contre un attaquant déterminé, mais un « harnais de sécurité » qui réduit les accidents et les emballements de plusieurs ordres de grandeur.

8. Quand recourir aux dev containers ou aux VM

Le bac à sable n'est pas la seule option d'isolement de Claude Code. La commodité et la force de l'isolement s'opposent, alors choisissez selon l'objectif.

La règle empirique : gardez le bac à sable intégré toujours actif pour réduire les demandes quotidiennes, et ne montez d'un cran vers sandbox-runtime, les conteneurs ou les VM que lorsque vous exécutez sans surveillance ou manipulez des dépendances non fiables. Pour un travail qui touche à la production — comme laisser l'IA piloter le cloud — associer des identifiants à moindre privilège à un palier d'isolement plus fort apporte de la tranquillité d'esprit.

Résumé

Le bac à sable brise le postulat même selon lequel sécurité et automatisation devraient s'opposer. Ouvrez simplement /sandbox une fois — cela seul change la façon dont vous tenez les rênes de Claude Code. Pour la référence de configuration exacte et à jour, considérez la documentation officielle des réglages du bac à sable comme votre source première.

FAQ