Tu as sûrement déjà tapé claude --dangerously-skip-permissions un soir pour laisser tourner un agent de refactoring sur une branche. Ça marche, jusqu'au jour où un fichier README lu par l'agent contient une instruction cachée qui pousse un curl vers un domaine que tu n'as jamais vu. Claude Code répond à ce scénario avec le sandboxing réseau, et la version 2.1.273 (15 septembre 2026) vient d'y ajouter une brique par commande. Si tu débutes sur l'outil, commence plutôt par le guide complet pour apprendre Claude avant d'activer des modes autonomes.
Le sandboxing réseau, la base qui existait déjà
Avant de parler de la nouveauté de septembre, il faut connaître la brique de base. Claude Code sait déjà isoler le réseau des commandes Bash, PowerShell et Monitor via le sandbox intégré : tu définis une liste de domaines autorisés, et le système d'exploitation fait respecter cette limite pour chaque commande sandboxée et ses processus enfants.
Ça se configure avec la clé sandbox.network.allowedDomains, dans ~/.claude/settings.json (niveau utilisateur), .claude/settings.json (niveau projet), ou via les settings gérés par ton organisation. Exemple minimal documenté officiellement :
{
"sandbox": {
"network": {
"allowedDomains": ["github.com", "*.npmjs.org"]
}
}
}
Deux réglages complémentaires existent pour verrouiller cette liste : strictAllowlist refuse automatiquement tout domaine hors liste au lieu de te demander confirmation, et allowManagedDomainsOnly permet à une organisation de figer l'allowlist via ses settings gérés, sans que les développeurs puissent l'élargir de leur côté.
La nouveauté du 15 septembre : Claude déclare ses besoins réseau, commande par commande
C'est là que beaucoup de monde se trompe sur ce que fait la version 2.1.273. Ce n'est pas un nouveau fichier de configuration où tu écrirais à l'avance la whitelist réseau de chaque commande. C'est l'inverse : en mode auto avec sandboxing actif, c'est Claude lui-même qui indique, sur la commande qu'il génère, la liste des hôtes dont cette commande précise a besoin en plus de ton allowlist déjà configurée. Le classifieur de permissions revoit cette liste en même temps que la commande, avant exécution.
Concrètement : Claude s'apprête à lancer pip install requests-oauthlib, un paquet qui va chercher une dépendance sur un miroir PyPI que ton allowedDomains ne couvre pas. Au lieu de bloquer la commande ou de te redemander confirmation, Claude Code peut déclarer ce domaine précis pour cette commande précise, le classifieur juge que c'est cohérent avec l'intention de la commande, et l'exécution continue sans interruption.
Deux garde-fous encadrent ce mécanisme, et ils sont stricts : une liste par commande ne peut jamais outrepasser un domaine explicitement bloqué dans deniedDomains, et si ton organisation a verrouillé l'allowlist avec strictAllowlist ou allowManagedDomainsOnly, Claude Code refuse purement et simplement toute liste par commande. Ce mécanisme élargit ponctuellement ce qui serait autrement refusé par défaut, il ne contourne aucun blocage explicite.
Ce que ça change, et ce que ça ne change pas
Ce que ça résout : la friction du sandboxing statique. Avant cette version, une allowlist figée à l'avance oubliait forcément quelque chose (un CDN, un miroir, une redirection), ce qui cassait des commandes légitimes ou forçait à élargir l'allowlist plus que nécessaire pour ne plus être bloqué. Avec la déclaration par commande, l'ouverture réseau reste ciblée sur ce dont la commande a réellement besoin, au moment où elle en a besoin.
Ce que ça ne change pas :
- Le sandboxing réseau ne couvre que Bash, PowerShell et Monitor. Les appels via un serveur MCP passent par leur propre canal, géré par le processus Claude Code, pas par une commande shell. Si tu utilises un MCP HubSpot ou Notion, ce trafic n'est pas concerné par ce mécanisme. Pour comprendre ce canal séparé, la page dédiée aux serveurs MCP détaille son fonctionnement.
- Ça ne remplace pas les permissions de fichiers. Un agent qui a le droit d'écrire dans
~/.ssh/garde ce droit, quelle que soit la configuration réseau. - Ça ne s'applique qu'en mode auto avec sandboxing actif. En mode interactif standard avec confirmation manuelle à chaque commande, ce mécanisme de déclaration par commande ne s'active pas.
- Ce n'est pas activé par défaut et ça ne remplace pas les prompts de permission existants : c'est un contrôle d'accès réseau supplémentaire pour le mode auto avec sandboxing, pas un changement du modèle de permission général de Claude Code.
Où ça s'insère dans le reste de la sécurité Claude Code
Ce mécanisme complète d'autres briques de sécurité livrées ces dernières semaines, chacune avec son propre rôle :
- Serveurs MCP gérés par l'équipe. Sur Team et Enterprise, le réglage
managedMcpServers(version 2.1.259, 2 septembre 2026) permet à un admin de figer les serveurs MCP autorisés pour toute l'équipe, indépendamment du sandboxing réseau des commandes shell. - Isolation plus stricte pour l'audit de code non fiable. Le mode
--restricted(version 2.1.248, 27 août 2026) retire des outils intégrés pour les tâches sur du code auquel tu ne fais pas confiance ; combiné à un container jetable, il reste la couche la plus solide pour ce cas d'usage précis. - Relecture humaine des diffs avant push. Le panneau
/diff(version 2.1.260, 3 septembre 2026) affiche les modifications non commitées au fil de l'exécution. Un agent qui ne peut joindre quegithub.compeut quand même y pousser un commit qui casse ta prod : le sandboxing réseau protège l'exfiltration, pas la qualité du code produit.
Si tu construis un agent qui touche à ta stack marketing ou opérationnelle, la page pilier automatiser sa stack avec Claude et MCP croise cette approche réseau avec la gestion des connecteurs MCP.
Mettre en place une allowlist de base sans y passer une heure
La déclaration par commande réduit la friction, mais elle ne dispense pas d'avoir une allowlist statique de base cohérente avec les outils que ton agent utilise réellement. Trois familles de cas fréquents, à adapter :
| Cas d'usage | Domaines de base à lister | Piège fréquent |
|---|---|---|
| Agent qui gère un repo GitHub | github.com, *.githubusercontent.com, registry.npmjs.org, *.npmjs.org | Oublier les CDN de npm, qui redirigent vers des sous-domaines distincts |
| Agent Python avec dépendances | pypi.org, files.pythonhosted.org | Oublier files.pythonhosted.org, séparé de pypi.org pour l'hébergement des paquets |
| Agent qui orchestre des API tierces | Domaines exacts des API appelées, *.amazonaws.com si stockage S3 | Oublier le domaine d'authentification OAuth, souvent différent du domaine API |
Pour ajuster ces réglages proprement avant d'activer un mode auto plus permissif, commence par configurer Claude Code correctement.
Passer à la pratique
Si tu utilises Claude Code au quotidien en mode auto, vérifie ta configuration sandbox.network.allowedDomains actuelle, complète-la avec les domaines de base de tes outils habituels, et laisse le mécanisme de déclaration par commande gérer les cas ponctuels plutôt que d'essayer de tout anticiper à la main. Et si tu veux passer du bricolage individuel à un vrai produit IA en production, avec une architecture agent, un backend Supabase et un déploiement Vercel, la formation Construire votre produit IA en 5 semaines couvre justement ce chemin, sécurité des agents incluse.