Sandbox Claude Code : la couche de sécurité que presque personne ne configure

TL;DR — le sandbox en une minute

• Le constat : entre le 18 juillet et le 7 août 2026, le changelog officiel de Claude Code recense cinq correctifs de contournement des permissions Bash (tabulations et Unicode invisibles, conditionnels zsh, PowerShell 5.1, chemins PowerShell entre guillemets, commandes de plus de 10 000 caractères).
• Ce que ça prouve : les permissions reposent sur l'analyse d'une ligne de commande. Un analyseur, ça se contourne. Le sandbox, lui, agit au niveau du système d'exploitation : il ne cherche pas à comprendre la commande.
• La conclusion : les permissions sont une couche d'ergonomie, le sandbox est la couche de sécurité. La plupart des utilisateurs configurent la première et ignorent la seconde.
• La nouveauté qui change tout : le masquage de credentials (juillet-août 2026) fait lire à la commande une valeur factice, la vraie n'étant réinjectée qu'au moment de la sortie réseau. Votre clé ne passe plus jamais par le contexte du modèle.
• Notre verdict : trois réglages à poser aujourd'hui, un quart d'heure de travail.

Tout le monde a compris qu'il fallait faire attention aux permissions. Presque personne ne configure le sandbox. C'est dommage, parce que c'est exactement l'inverse qu'il faudrait faire : les permissions vous protègent d'une erreur, le sandbox vous protège d'un contournement.

Permissions et sandbox : deux couches, deux métiers

La confusion est fréquente, et elle a une cause simple : les deux mécanismes affichent des refus qui se ressemblent. Ils ne travaillent pourtant pas du tout au même endroit.

La ligne à retenir est la deuxième colonne. Une règle de permission travaille sur une chaîne de caractères ; le sandbox travaille sur un appel système. Vous pouvez réécrire une commande de mille façons ; vous ne pouvez pas réécrire l'ouverture d'un fichier.

La preuve par le changelog : cinq contournements en trois semaines

Ce n'est pas une opinion, c'est une série de correctifs datés. Voici ce que le changelog officiel a corrigé sur les permissions Bash entre la mi-juillet et le 7 août 2026.

Aucun de ces correctifs ne révèle une faiblesse du produit : ils montrent au contraire une équipe qui traque activement les cas limites. Ce qu'ils révèlent, c'est la nature du mécanisme. Un filtre qui doit interpréter du shell affronte la totalité de l'inventivité de la syntaxe shell — et le shell a été conçu pour être expressif, pas pour être analysable.

D'où la règle que nous appliquons : ne faites jamais reposer la protection d'un secret sur une règle de permission seule.

Les trois réglages à poser aujourd'hui

1. Refuser la lecture des répertoires de secrets

C'est la base, et elle contient un piège corrigé tout récemment. Les entrées de refus de lecture terminées par une barre oblique — par exemple un répertoire de credentials cloud écrit avec un slash final — étaient contournables sur Linux et macOS avant la version 2.1.224 du 7 août 2026. Si vous aviez posé cette règle avant, elle ne faisait pas ce que vous croyiez.

Deux conséquences pratiques. D'abord, mettez à jour : une règle de sécurité écrite correctement mais appliquée par une version ancienne ne vaut rien. Ensuite, vérifiez vos règles plutôt que de les supposer : posez la règle, puis demandez à l'agent de lire le fichier et regardez ce qui se passe. Une règle non testée est une hypothèse.

2. Fermer le réseau par défaut

Le réglage sandbox.network.strictAllowlist, apparu en version 2.1.219 le 24 juillet 2026, bloque les hôtes non listés sans demander confirmation. La différence avec le comportement par défaut est plus grande qu'il n'y paraît : une invite de confirmation, dans une session longue, finit par être acceptée machinalement. Un blocage silencieux, non.

C'est le réglage qui a le meilleur rapport protection sur effort de toute la liste. Le pire scénario d'un agent de code n'est pas qu'il casse votre dépôt — un dépôt se restaure. C'est qu'il envoie quelque chose quelque part. Un contrôle strict de la sortie réseau supprime cette classe entière de risques.

3. Ne plus jamais exposer une clé au modèle

C'est la nouveauté la plus intéressante de l'été, et elle règle un dilemme qui n'avait jusqu'ici que de mauvaises réponses. Quand une commande a besoin d'un jeton d'accès, on avait deux options : le laisser lisible, et il finissait dans le contexte du modèle puis dans le journal de session ; ou le retirer, et la commande échouait.

Le masquage de credentials, introduit en 2.1.221 le 4 août 2026 pour Linux et WSL, propose une troisième voie : la commande lit une valeur sentinelle, factice, et le mandataire du sandbox substitue la vraie valeur au moment de la sortie réseau. Le secret circule là où il est nécessaire — sur le fil — et nulle part ailleurs.

La version 2.1.224 du 7 août l'a étendu de façon notable, avec l'extraction de champs, le décodage de jetons JWT et le masquage de revendications précises, ainsi que la re-signature des requêtes AWS SigV4. Ce dernier point est le plus révélateur : une signature AWS dépend du contenu de la requête, donc une simple substitution de chaîne la casserait. Il a fallu re-signer. C'est le signe d'un mécanisme pensé pour un usage réel, pas d'une case à cocher.

Le cas particulier des sessions parallèles

Si vous faites tourner plusieurs agents en même temps, l'isolation en arbre de travail est passée de confort à garde-fou entre le 4 et le 6 août 2026 : elle s'applique désormais aux modifications de fichiers et aux commandes Bash dans tous les types de session, et une session en arbre de travail ne peut plus exécuter de commande git sur le dépôt principal.

Le scénario évité est concret : un agent lancé sur une branche isolée qui déclenche une opération git sur le dépôt de référence. Le résultat n'est pas une fuite de données, c'est pire à court terme — un dépôt dans un état que personne ne comprend, au milieu d'une série d'agents dont on ne sait plus lequel a fait quoi. Si vous travaillez avec plusieurs agents simultanés, c'est le sujet à traiter avant d'augmenter le parallélisme. Nous détaillons l'organisation d'ensemble dans notre guide sur l'orchestration de plusieurs agents en parallèle.

Le quart d'heure qui change votre posture

Voici l'ordre dans lequel nous procédons, trié par ratio protection sur effort.

1. Mettre à jour. Sans cela, les points suivants sont partiellement inopérants — le correctif du refus de lecture avec barre oblique finale en est la démonstration.
2. Poser les refus de lecture sur les répertoires de secrets : credentials cloud, clés SSH, fichiers d'environnement, trousseau de jetons.
3. Activer la liste blanche réseau stricte, puis y ajouter au fil de l'eau les hôtes réellement nécessaires. Commencez fermé, ouvrez sur constat, jamais l'inverse.
4. Tester chaque règle en demandant explicitement à l'agent de faire ce que vous venez d'interdire. Une règle non testée est une hypothèse, pas une protection.
5. Basculer les secrets nécessaires vers le masquage plutôt que de les rendre lisibles.
6. Vérifier l'isolation si vous lancez plusieurs sessions en parallèle.

Les étapes 1 à 3 prennent une dizaine de minutes et couvrent la grande majorité du risque. L'étape 4 est celle que tout le monde saute et c'est la seule qui transforme une intention en garantie.

Ce que le sandbox ne fera jamais pour vous

Trois angles morts, à connaître pour ne pas se croire couvert.

• Le sandbox ne juge pas la qualité du code. Il empêche l'agent d'aller là où il ne doit pas ; il ne dit rien de la justesse de ce qu'il écrit dans le périmètre autorisé. C'est un sujet distinct, que nous traitons dans notre protocole de vérification du code généré.
• Le sandbox ne remplace pas les permissions. Les deux couches se complètent : les permissions arrêtent l'erreur évidente avant qu'elle ne coûte du temps, le sandbox arrête ce qui aurait glissé au travers. Notre guide des permissions reste la première étape.
• Le sandbox ne compense pas un secret déjà exposé. Si une clé est passée dans un contexte de conversation avant que vous ne posiez ces règles, la seule réponse correcte est la rotation de cette clé. Aucun réglage rétroactif n'existe.

Points de vigilance

• Les règles se vérifient, elles ne se supposent pas : le correctif du 7 août 2026 sur les refus de lecture terminés par une barre oblique montre qu'une règle bien écrite peut ne rien faire.
• Une invite de confirmation acceptée machinalement ne protège de rien : préférez le blocage silencieux au message d'alerte, sur le réseau en particulier.
• Le masquage de credentials est encore limité à Linux et WSL dans les versions d'août 2026 : sur les autres systèmes, restez sur le principe de ne pas rendre le secret lisible.
• Les permissions restent utiles : elles ne sont simplement pas une frontière de sécurité. Traitez-les comme un filet de confort, pas comme un mur.