Claude Code peut limiter l’accès réseau à une seule commande

Avec Claude Code, l’installation d’une dépendance n’a désormais plus besoin d’élargir le périmètre réseau pour tout le reste d’une tâche. Depuis le 14 septembre 2026, Claude Code 2.1.271 permet, en mode auto sandboxé, d’accorder l’accès réseau à l’échelle d’une commande : l’hôte du registre autorisé pour l’installation redevient inaccessible dès que cette commande se termine.

Claude Code : ce qui change vraiment

Deux couches de sécurité distinctes entrent en jeu. Il faut les dissocier pour comprendre cette évolution.

Le mode auto décide si un appel d’outil peut être exécuté. Un classifieur séparé évalue l’action au regard de votre demande. Le précédent guide du mode auto de Claude Code détaille ce modèle général d’autorisations.

Le sandbox détermine ce qu’une commande shell en cours d’exécution peut atteindre. Il limite les écritures de fichiers et fait transiter le trafic réseau par un proxy qui vérifie l’hôte de destination.

La version 2.1.271 resserre le lien entre ces deux couches. En mode auto sandboxé, un appel Bash, PowerShell ou Monitor peut désormais embarquer une liste allowed_domains. Claude Code examine à la fois la commande et les hôtes dont elle a besoin. Ces hôtes ne s’ouvrent que pour cette commande, tandis que le sandbox refuse les autres. La note de version est explicite sur ce périmètre.

Ce champ en snake_case ne correspond pas à sandbox.network.allowedDomains dans settings.json.

Avant cette version, autoriser un nouvel hôte dans le sandbox pouvait produire une permission plus étendue. Une autorisation manuelle reste valable jusqu’à la fin de la session en cours ; si elle est enregistrée, elle peut persister dans les sessions suivantes. Le mode auto peut également mettre en cache sa décision sur un hôte et un port. Le nouveau champ modifie la portée à l’exécution, même lorsque le verdict du classifieur est réutilisé : l’ouverture réseau reste attachée à la commande en cours.

Cette évolution ne concerne que la combinaison citée dans la note de version : mode auto, sandbox et appel Bash, PowerShell ou Monitor. Les sessions manuelles, les commandes non sandboxées, les outils de fichiers intégrés et les tâches qui n’accèdent jamais au réseau ne bénéficient pas de cette limite.

Le vrai calcul porte sur les autorisations, pas sur le prix

Le prix d’une licence Claude Code n’a pas changé. Anthropic n’a annoncé ni frais distincts, ni nouveau SKU, ni résultat de performance pour les domaines limités à une commande.

L’équation utile mesure l’étendue de l’autorisation qu’il faut pouvoir défendre :

standing grant = approved host × every later command that can reuse it

command-scoped grant = approved host × the reviewed command

Prenons l’installation d’une dépendance qui doit joindre registry.npmjs.org. Jusqu’ici, le choix opérationnel était souvent inconfortable : interrompre une tâche sans surveillance pour prendre une décision réseau, ou préautoriser le registre en acceptant que toutes les commandes sandboxées suivantes puissent l’atteindre. Le mode auto peut maintenant approuver cet hôte en même temps que l’installation, puis le refermer avant la suite du build, des tests, du packaging et de la revue.

Même sans modifier la facture d’abonnement, ce changement agit sur deux postes budgétaires. Les équipes plateforme ont moins d’exceptions permanentes à concevoir puis à nettoyer. Les équipes sécurité peuvent évaluer une paire commande-hôte, au lieu de devoir considérer l’hôte comme accessible pendant tout le reste de la tâche.

Le parcours d’examen conserve néanmoins un coût de calcul. Sur les comptes Enterprise et les comptes fournisseur facturés à l’usage cités dans la documentation d’Anthropic sur les modes d’autorisation, les vérifications du classifieur consomment des tokens et ajoutent un aller-retour. La note de version ne fournit aucun benchmark de latence et aucun test chronométré n’a été réalisé pour cet article : impossible, donc, d’avancer honnêtement un nombre de secondes gagnées.

À qui cette fonction peut-elle servir dès demain ?

Un fondateur solo qui lance un long job de build

Un fondateur peut laisser Claude Code restaurer les paquets verrouillés d’un dépôt SaaS, puis enchaîner les tests et la revue de code sans maintenir le registre public ouvert pour ces étapes ultérieures. La tâche continue d’avancer sans qu’un téléchargement nécessaire ne se transforme en sortie réseau permanente pour toute la session.

Un lead technique d’agence qui passe d’un dépôt client à l’autre

Une agence peut rattacher l’hôte de paquets d’un client à la seule installation qui en a besoin, plutôt que d’enregistrer une exception supplémentaire au niveau du projet. Les autorisations sont plus simples à nettoyer et une commande exécutée à l’étape suivante risque moins d’envoyer du code client vers un hôte ouvert uniquement pour les dépendances.

Un responsable plateforme ou sécurité qui encadre des agents autonomes

Une équipe plateforme peut conserver ses règles de refus à l’échelle de l’organisation et ses restrictions de domaines gérées, tout en laissant les commandes courantes demander un accès plus étroit à l’intérieur de cette politique. Le journal d’examen devient plus facile à expliquer : cette commande avait besoin de cet hôte pour cette action. Il ne prouve pas que l’hôte était sûr pour tout ce que l’agent a fait ensuite.

Un ingénieur build qui sépare installation et tests

Un ingénieur build peut faire de la restauration des paquets une phase connectée, puis exécuter la suite de tests hors ligne. Si un test compromis ou un script inattendu tente de joindre le registre après l’installation, il n’hérite pas de l’ouverture accordée à la commande précédente, sauf si une autre règle permanente autorise déjà cet hôte.

Configurer un sandbox Claude Code pour une installation cloisonnée

Le changement se comprend particulièrement bien avec un dépôt qui contient un package-lock.json versionné et des dépendances résolues depuis un seul registre connu. Pour les installations automatisées propres, npm documente npm ci : la commande exige un lockfile, échoue si celui-ci et le manifeste divergent, supprime un éventuel node_modules, puis laisse le manifeste et le lockfile inchangés. L’option --ignore-scripts bloque les scripts de cycle de vie des paquets pendant cette installation. Ces comportements sont documentés par npm.

1. 1

   Vérifier la version de Claude Code

   Exécutez la commande de vérification indiquée dans le changelog :

   claude --version

   Utilisez la version 2.1.271, ou une version ultérieure qui intègre cette fonctionnalité.

2. 2

   Lancer le mode auto dans un sandbox fermé par défaut

   Pour une session, associez le mode auto à un sandbox qui doit démarrer correctement et ne peut pas relancer hors de ce périmètre une commande bloquée :

   claude --permission-mode auto --settings '{"sandbox":{"enabled":true,"failIfUnavailable":true,"allowUnsandboxedCommands":false}}'

   Cette configuration utilise les contrôles documentés --permission-mode, --settings, failIfUnavailable et allowUnsandboxedCommands. Sur macOS, le sandbox est intégré. Linux et WSL2 nécessitent bubblewrap et socat ; Windows natif n’est pas pris en charge par le sandbox intégré. La procédure et les limites par plateforme figurent dans le guide du sandbox.

3. 3

   Décrire précisément la tâche d’installation

   Envoyez la consigne suivante, en remplaçant l’hôte du registre si votre lockfile utilise un registre privé :

   Installe exactement les dépendances de package-lock.json avec npm ci --ignore-scripts. Cette commande ne peut joindre que registry.npmjs.org. N’enregistre pas cet hôte dans les réglages du projet ou de l’utilisateur. Une fois l’installation terminée, exécute la suite de tests dans une commande distincte, sans accès réseau. Arrête-toi si l’installation exige un autre hôte.

   Vous ne saisissez pas vous-même le champ allowed_domains. Claude Code construit l’appel de l’outil shell, puis le mode auto examine avec cet appel l’hôte demandé.

4. 4

   Vérifier que l’étape suivante démarre sans accès

   Ouvrez /sandbox, consultez l’onglet Config après résolution et vérifiez que registry.npmjs.org ne figure pas déjà dans un allowedDomains permanent ni dans une règle WebFetch enregistrée. Lancez ensuite la commande de test séparée. Toute tentative d’accès réseau depuis cette commande ultérieure doit disposer de son propre jeu de domaines examiné, faute de quoi la politique en place doit la refuser.

Le piège concerne le lockfile. Un verrou de paquets peut pointer vers un registre privé, un hôte Git ou l’URL directe d’une archive. Indiquer uniquement registry.npmjs.org ne déplace pas ces dépendances vers ce registre. Vérifiez les hôtes réellement résolus, conservez une liste exacte et laissez la commande s’arrêter si le verrou réclame une destination inattendue.

Ce que cette fonction ne résout pas

Limiter l’accès réseau à une commande réduit la période pendant laquelle un hôte est joignable. Cela ne prouve pas que l’hôte est digne de confiance, n’inspecte pas chaque requête chiffrée et ne rend pas sûr le code téléchargé.

Par défaut, le proxy intégré d’Anthropic filtre par nom d’hôte sans inspecter le contenu TLS. Pendant la commande autorisée, un processus peut atteindre n’importe quel chemin permis sur cet hôte. Les processus enfants lancés par la commande partagent le même périmètre de sandbox. C’est pourquoi npm ci --ignore-scripts constitue un bon exemple pédagogique : l’option écarte les scripts de cycle de vie des paquets pendant l’installation, mais n’audite pas les paquets téléchargés.

La politique gérée reste prioritaire. strictAllowlist peut refuser tout ce qui se trouve hors de la liste configurée, tandis que allowManagedDomainsOnly peut limiter les hôtes autorisés à ceux des réglages gérés. Les règles de refus explicites continuent de bloquer les connexions. Les domaines accordés à une commande ne contournent pas ces contrôles.

La relance hors sandbox constitue une autre limite concrète. Claude Code dispose normalement d’une échappatoire pour les commandes que le sandbox ne peut pas exécuter. Régler allowUnsandboxedCommands sur false est important : une installation en échec ne peut alors plus transformer discrètement la question « quel hôte cette commande peut-elle joindre ? » en « cette commande peut-elle s’exécuter hors du sandbox ? ».

La marche à suivre lundi

Agissez cette semaine si vous utilisez Claude Code en mode auto pour les mises à jour de dépendances, la maintenance nocturne ou des jobs de build sans surveillance, et si vos registres de paquets figurent actuellement dans une allowlist générale du sandbox. Cette fonction mérite de tester si ces entrées permanentes peuvent être supprimées.

Attendez si votre organisation applique une politique réseau gérée qui préautorise volontairement le registre pour chaque commande, ou si un conteneur externe ou un runner CI impose déjà une règle de sortie plus stricte par processus. Le nouveau champ peut renforcer la défense en profondeur, mais il ne remplace pas la frontière que vous exploitez déjà.

Vous n’êtes pas concerné si vous n’associez pas le mode auto au sandbox, ou si votre tâche n’appelle jamais Bash, PowerShell ou Monitor sur le réseau.

Le geste à tester lundi reste simple : confirmez que vous utilisez Claude Code 2.1.271 ou une version plus récente, choisissez une installation aux dépendances verrouillées, lancez-la en mode auto dans un sandbox fermé par défaut, indiquez uniquement l’hôte de registre attendu, puis prouvez que la commande de test suivante ne peut pas réutiliser ce chemin réseau. Ne supprimez une exception permanente pour le registre qu’après avoir réussi cette vérification dans votre propre environnement.

Pour recevoir la prochaine évolution de plateforme, accompagnée du workflow qu’elle transforme, inscrivez-vous à la newsletter.