Restreindre le réseau d’un agent Claude Code, commande par commande

Ce que change réellement la fonctionnalité

Claude Code 2.1.271, publié le 14 septembre 2026, a ajouté les domaines autorisés par commande dans Bash, PowerShell et Monitor lorsque le mode auto et la sandbox sont actifs. La documentation actuelle décrit le même mécanisme comme une liste d’hôtes portée par la commande : le classifieur examine ensemble l’action et les hôtes demandés.

Ce détail est important. Un domaine approuvé pour une commande n’est pas ajouté à la liste de la session, ni à un fichier de réglages. La commande suivante doit présenter ses propres hôtes. Il s’agit donc d’une ouverture temporaire, liée à un appel précis, pas d’une promesse que « l’agent n’accède qu’à Internet » ou qu’un autre outil sera automatiquement borné de la même façon.

La version courante affichée dans le changelog au 23 septembre est déjà postérieure à 2.1.271. Notez la version réellement installée avant de comparer un comportement : une règle observée sur une préversion ou une version plus ancienne n’est pas une preuve pour la vôtre.

Vérifier la matrice outil, mode et sandbox

Avant un essai, consignez ces quatre éléments :

• Outil : Bash, PowerShell ou Monitor. Le changelog ne généralise pas la fonctionnalité à tous les outils Claude Code.
• Mode : le mécanisme par commande vise le mode auto, pas le mode Plan, acceptEdits ou une session sans classifieur.
• Sandbox : l’isolation réseau doit être effectivement active. La sandbox et le mode de permission ne sont pas la même couche.
• Hôte : le nom demandé, son éventuel port et le résultat observé.

Ouvrez /sandbox et consultez l’onglet de configuration résolue. Vérifiez ensuite /permissions pour voir les règles et le fichier de réglages dont elles proviennent. Le fichier réellement chargé peut venir du projet, de l’utilisateur ou d’un réglage géré par l’organisation ; le chemin affiché est donc une preuve plus utile qu’une hypothèse fondée sur le répertoire courant.

Distinguer la liste statique de l’autorisation par commande

La configuration réseau de la sandbox expose une liste allowedDomains et, si nécessaire, une liste deniedDomains. La première évite de redemander certains hôtes ; la seconde conserve la priorité du refus, même lorsqu’une règle plus large les couvrirait. Un réglage strict peut aussi refuser les hôtes hors liste au lieu de demander une approbation.

Les permissions WebFetch(domain:...) alimentent un autre parcours et ne transforment pas WebFetch en contrôle universel de Bash. Inversement, la sandbox réseau s’applique aux commandes sandboxées et à leurs sous-processus. Gardez donc deux lignes dans votre registre : « domaine autorisé par la sandbox » et « règle d’outil qui autorise l’appel ».

Protocole d’essai sans données sensibles

Utilisez un dépôt de test, une sortie publique et un hôte dont la disponibilité ne pose pas d’enjeu. Ne fournissez aucun token, fichier de configuration personnel, identifiant cloud ou jeu de données confidentiel.

1. Relevez la version, le système et le mode de permission.
2. Demandez une opération de lecture sans écriture vers un seul domaine explicitement nécessaire.
3. Dans le résultat de la commande, vérifiez l’hôte présenté, l’outil utilisé et l’indication de sandbox.
4. Répétez avec un domaine non déclaré. Le refus ou la demande obtenue doit être noté, pas interprété comme un test de toutes les routes réseau.
5. Essayez ensuite la même intention avec un autre outil, sans modifier la configuration. Cette comparaison montre si vous êtes sorti du périmètre Bash, PowerShell ou Monitor.
6. Conservez un relevé minimal : version, mode, sandbox, domaine, outil, résultat, réglage chargé et date.

Si une commande ne peut pas s’exécuter dans la sandbox, Claude Code peut proposer une reprise hors sandbox. Cette reprise change le modèle de risque : elle repasse par les permissions ordinaires et ne doit pas être acceptée machinalement. Pour un essai contrôlé, refusez cette élévation ou activez un réglage strict qui empêche la reprise non sandboxée, puis documentez l’échec.

Limites à inscrire dans la revue

Une allowlist de domaines ne contrôle pas à elle seule les fichiers accessibles, les secrets injectés, les outils en processus, les réglages gérés ou les actions effectuées hors sandbox. Les couches réseau et système de fichiers sont indépendantes. Désactiver l’isolation de fichiers tout en conservant une liste réseau peut être utile pour un cas précis, mais élargit fortement ce que la commande peut modifier ; ce n’est pas un mode de sécurité par défaut.

De même, la restriction ne prouve ni l’absence de contournement, ni la confidentialité d’un fournisseur distant, ni la sûreté d’un script Python, Node ou shell. Un programme lancé par une commande peut avoir son propre comportement, et un autre mode de permission peut changer la décision. La conclusion correcte est toujours locale : « cette commande, dans cette version, ce mode et cette sandbox, a produit ce résultat ».

Pour replacer ce test dans une revue plus large des permissions et des outils, consultez la checklist de sécurisation d’un serveur MCP et de ses skills et le cadrage des outils d’un agent. Ces contenus ne remplacent pas la lecture de votre configuration résolue.

Sources et limites

Sources officielles consultées le 23 septembre 2026 : changelog Claude Code, notamment l’entrée 2.1.271 du 14 septembre 2026 ; configuration de la sandbox, notamment la section sur les domaines par commande ; configuration des permissions ; répertoire .claude et priorité des réglages. La syntaxe et les modes peuvent évoluer après cette date. Ce guide décrit une méthode de vérification, pas une garantie générale de sécurité, de confidentialité ou de couverture de tous les outils.