Plus Claude Code devient autonome, plus il faut savoir cadrer ce qu'il fait. Deux mécanismes jouent ce rôle : la sandbox, qui limite ce que les commandes peuvent atteindre sur ta machine, et les limites sur les sous-agents, qui évitent qu'une tâche parte en délégation incontrôlée.
Les versions de juin et juillet ont apporté plusieurs réglages importants sur ces deux fronts, dont les 2.1.216 et 2.1.217, publiées les 20 et 21 juillet. Tour d'horizon.
La sandbox de Claude Code isole les commandes qu'il exécute au niveau du système d'exploitation, pour les fichiers comme pour le réseau (Anthropic en détaillait le fonctionnement dans son article de mai sur le confinement des agents). L'intérêt est double : moins de demandes de permission à valider, et une limite dure en cas d'erreur ou d'injection de prompt.
Pour l'activer, le réglage de base dans settings.json :
{
"sandbox": {
"enabled": true
}
}
Jusqu'ici, la sandbox était un bloc : isolation des fichiers et contrôle du réseau. Or certains outils s'accommodent mal de l'isolation des fichiers (outils de build, caches, environnements particuliers), alors que le contrôle des sorties réseau reste la protection la plus précieuse contre l'exfiltration de données.
La 2.1.216 ajoute le réglage sandbox.filesystem.disabled, qui désactive l'isolation du système de fichiers tout en gardant le contrôle des connexions réseau :
{
"sandbox": {
"enabled": true,
"filesystem": { "disabled": true }
}
}
C'est un compromis utile quand la sandbox complète bloque ton workflow : plutôt que de tout désactiver, tu gardes la barrière qui compte le plus.
Plusieurs ajouts des dernières semaines vont dans le même sens :
- 2.1.181 (17 juin) :
sandbox.allowAppleEvents, pour autoriser explicitement les commandes sandboxées à envoyer des Apple Events sur macOS ;
- 2.1.187 (23 juin) :
sandbox.credentials, pour empêcher les commandes sandboxées de lire les fichiers d'identifiants et les variables d'environnement secrètes ;
- 2.1.191 (24 juin) : les hôtes réseau que tu autorises sont mémorisés pour le reste de la session, au lieu de redemander à chaque connexion.
Le réglage sandbox.credentials mérite une attention particulière. Les incidents décrits par Anthropic en mai dans son article sur le confinement montraient que la fuite d'identifiants (clés cloud, jetons d'API) est l'un des risques majeurs. Garder ces fichiers hors de portée est une protection simple et efficace.
Les sous-agents sont l'un des outils les plus puissants de Claude Code : ils permettent de paralléliser le travail et d'isoler du contexte. Mais une délégation mal cadrée peut s'emballer : un agent qui lance des agents, qui lancent des agents… Les versions de juillet posent des garde-fous.
La 2.1.212 (17 juillet) introduit un plafond de sous-agents lancés par session : 200 par défaut, modifiable avec la variable CLAUDE_CODE_MAX_SUBAGENTS_PER_SESSION. Objectif : arrêter les boucles de délégation incontrôlées. La commande /clear remet le compteur à zéro.
La 2.1.217 (21 juillet) ajoute une limite au nombre de sous-agents qui tournent en même temps : 20 par défaut, modifiable avec CLAUDE_CODE_MAX_CONCURRENT_SUBAGENTS. Un seul message ne peut plus déclencher une nuée illimitée d'agents en arrière-plan.
Toujours en 2.1.217 : les sous-agents ne lancent plus de sous-agents imbriqués par défaut. Pour autoriser une imbrication plus profonde, il faut définir la variable CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH (voir la documentation pour les valeurs attendues).
Dernière correction importante de la 2.1.217 : l'option --max-budget-usd n'arrêtait pas les sous-agents en arrière-plan. Désormais, une fois le plafond atteint, les nouveaux lancements sont refusés et les agents en cours sont arrêtés.
Deux corrections concernent les sous-agents isolés dans un worktree Git :
- 2.1.210 : ils pouvaient lancer des commandes Git modifiant le dépôt principal au lieu de leur propre worktree ;
- 2.1.216 : ils pouvaient rediriger Git vers le dépôt partagé via
git -C, --git-dir ou les variables GIT_DIR et GIT_WORK_TREE.
Ces deux trous sont bouchés : un sous-agent isolé reste désormais dans son worktree.
En 2.1.212, le paramètre mode de l'outil de délégation est déprécié : les sous-agents héritent par défaut du mode de permission de la session parente. Par défaut, un sous-agent n'a donc plus un mode de permission différent de celui de la session qui l'a lancé.
- Active la sandbox, et si elle gêne ton workflow, essaie
sandbox.filesystem.disabled avant de tout couper.
- Protège tes identifiants avec
sandbox.credentials.
- Garde les plafonds par défaut de sous-agents, sauf besoin précis : 200 par session et 20 simultanés, c'est déjà beaucoup.
- Utilise
--max-budget-usd pour les tâches longues en mode non interactif.
- Mets à jour Claude Code : plusieurs de ces changements sont des corrections de sécurité.
- 2.1.216 :
sandbox.filesystem.disabled garde le contrôle réseau sans isoler les fichiers.
- 2.1.187 :
sandbox.credentials protège fichiers d'identifiants et secrets.
- 2.1.212 : plafond de 200 sous-agents par session ; 2.1.217 : 20 simultanés, pas d'imbrication par défaut.
- 2.1.217 :
--max-budget-usd arrête aussi les sous-agents en arrière-plan.
- Les sous-agents isolés restent enfin dans leur worktree.
