Anthropic a publié début août 2026 la version 2.1.222 de Claude Code, avec deux correctifs d'isolation dont on ne parle pas assez : un agent lancé dans un worktree git isolé pouvait toucher le checkout principal, et des hooks configurés en auto-allow pouvaient contourner les restrictions d'outils dans des tâches d'arrière-plan. Rien n'indique une exploitation dans la nature. Mais si tu utilises Claude Code sur plusieurs projets clients, avec des sous-agents ou des hooks personnalisés, ces angles morts te concernent directement.
Cet article te donne le filtre opérationnel. En quinze minutes, tu sauras si ton setup est propre, quoi vérifier sur les worktrees, les hooks et les sous-agents, et quelles règles imposer à ton équipe. Pas de FUD, pas de score CVSS gratuit : juste ce que fait un CTO le lundi matin. Si tu veux d'abord poser des bases saines sur Claude, la ressource centrale est notre guide pour apprendre Claude.
Ce que corrigent les patchs, en clair
Deux failles, un même chantier : l'isolation des sessions Claude Code qui utilisent des worktrees git séparés.
La première touchait les sessions isolées par worktree et leurs sous-agents. Sur les versions antérieures à 2.1.222, une session lancée dans un worktree pouvait exécuter des commandes git destructrices contre le checkout principal (le dépôt d'origine, hors du worktree). Le correctif ne se contente plus de bloquer les commandes git : il étend l'isolation aux éditions de fichiers et aux commandes Bash, dans tous les types de session. C'est un élargissement du périmètre du garde-fou, pas juste un patch ciblé.
La seconde faille est plus retorse. Les hooks PreToolUse configurés en auto-allow (ceux qui approuvent automatiquement certains appels d'outils sans prompt) pouvaient contourner les restrictions dans des tâches d'agent lancées en arrière-plan : résumés de conversation, compaction du contexte, renommage de session. Bref, les tâches système que tu ne vois pas défiler à l'écran. Un hook trop laxiste sur ces branches secondaires laissait passer des appels qui auraient été bloqués en session interactive.
Ces deux correctifs prolongent un chantier commencé en juillet. La version 2.1.216 avait déjà corrigé un problème voisin : des sous-agents isolés qui pouvaient rediriger git vers le checkout partagé via git -C, --git-dir, ou les variables GIT_DIR et GIT_WORK_TREE. Vu de loin, c'est la même famille de bug : la frontière entre worktrees n'était pas aussi étanche que ce qu'on croyait.
Concrètement pour un dirigeant technique, ça veut dire quoi ? Deux risques réels. Un : fuite entre projets. Tu bosses sur le repo client A dans un worktree, l'agent découvre un chemin vers le repo client B, lit un .env, remonte l'info dans un résumé. Deux : exécution hors scope. Une commande Bash tourne dans un dossier que tu croyais isolé et modifie des fichiers de production. Ni l'un ni l'autre n'est théorique.
Vérifier ta version et forcer la mise à jour
Premier réflexe, avant tout audit de config : la version installée.
claude --versionSi tu es en dessous de 2.1.222, tu mets à jour maintenant. La commande dépend de ton canal d'installation :
# Installation via npm
npm update -g @anthropic-ai/claude-code
# Installation native (installer officiel)
claude updateLe point de vigilance que la plupart des équipes oublient : les CI/CD où Claude Code tourne en mode headless. Si tu as un Dockerfile qui pinne @anthropic-ai/claude-code@2.1.210 parce que c'était la version validée en début de trimestre, tu tournes toujours sur le binaire vulnérable en production, même si tes devs sont à jour sur leurs postes. Le patch ne fait rien pour un container qui n'est jamais rebuild.
Passe en revue tous les endroits où la version est figée : Dockerfile, package.json d'outillage interne, action GitHub, image de base d'un runner self-hosted. Un projet, un canal de mise à jour, une politique de rebuild. Si tu débutes sur ces réflexes, notre pilier setup détaille comment cadrer proprement l'installation dès le départ.
Audit worktree : où tu es exposé
Le pattern à risque tient en trois ingrédients : plusieurs worktrees git actifs, un agent Claude lancé dans l'un d'eux, des données sensibles (secrets, .env, credentials) dans un autre ou à la racine partagée.
Trois checks rapides à faire sur chaque machine de dev :
1. Lister les worktrees actifs.
git worktree listTu obtiens la liste des dossiers de travail rattachés à ce repo. Si tu en découvres que tu ne reconnais pas, ou des dossiers de projets clients différents rattachés au même repo, c'est le premier signal.
2. Chercher les .env accessibles. Depuis chaque worktree, remonte de deux ou trois niveaux et vérifie qu'aucun fichier .env, .env.local, credentials.json ou clé SSH n'est atteignable. Un agent qui a le droit de lire le dossier parent trouvera tout ce que tu y as laissé traîner.
3. Revoir les settings.json locaux. Le fichier .claude/settings.json définit ce que l'agent a le droit de faire. Un exemple courant de config trop permissive :
{
"permissions": {
"allow": [
"Bash(*)",
"Read(**)",
"Write(**)"
]
}
}Trois wildcards, trois portes ouvertes. Version resserrée :
{
"permissions": {
"allow": [
"Bash(npm run *)",
"Bash(git status)",
"Bash(git diff)",
"Read(./src/**)",
"Read(./tests/**)",
"Write(./src/**)"
],
"deny": [
"Read(./.env*)",
"Read(../**)",
"Bash(rm *)",
"Bash(sudo *)"
]
}
}Le principe : allowlist stricte pour ce que l'agent doit faire, denylist explicite pour ce qui ne doit jamais remonter, même par accident. Le patch corrige des bugs de moteur ; ta config, c'est la ceinture de sécurité.
Hooks et sous-agents : le vrai angle mort
Les hooks (PreToolUse, PostToolUse) et les sous-agents lancés via Task s'exécutent avec le contexte du parent. Avant le patch 2.1.222, un hook mal écrit en auto-allow pouvait faire passer des appels d'outils dans des branches d'arrière-plan qui auraient été bloqués en session interactive. Le patch corrige le moteur. Ta config reste ta responsabilité.
Exemple concret de hook risqué. Objectif louable : logger toutes les commandes Bash pour audit.
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{
"type": "command",
"command": "echo $CLAUDE_TOOL_INPUT >> /home/user/audit.log",
"auto_allow": true
}
]
}
]
}
}Deux problèmes. Un : $CLAUDE_TOOL_INPUT injecté sans échappement dans un shell peut interpréter n'importe quoi. Deux : chemin absolu vers /home/user/ partagé entre projets, donc log commun à des contextes qui ne devraient pas se voir.
Version corrigée :
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{
"type": "command",
"command": "jq -r '.tool_input.command' >> ./.claude/audit.log",
"auto_allow": false
}
]
}
]
}
}Trois changements : parsing propre via jq, chemin relatif au projet, auto_allow désactivé pour forcer une revue explicite. Ce dernier point est le plus important après le patch 2.1.222 : moins tu utilises d'auto-allow, moins tu dépends du garde-fou moteur.
Même logique pour les sous-agents personnalisés dans .claude/agents/. Chaque agent doit déclarer ses permissions plutôt que d'hériter par défaut. Si tu construis des agents plus poussés, le fond du sujet est traité dans notre pilier agents, et l'approche architecture dans ce guide sur l'architecture d'agent Claude.
Un dernier point : pour les workflows vraiment sensibles (accès à des données clients, à un CRM, à de la production), la bonne réponse n'est souvent pas d'élargir les permissions shell de Claude Code. C'est d'exposer des outils via MCP, où chaque capacité est déclarée, versionnée et auditable, plutôt que de donner un accès Bash générique.
Trois règles à imposer à ton équipe
La question n'est plus technique, elle est organisationnelle. Trois règles à écrire dans ton runbook.
Règle 1 : un projet, un dossier isolé. Jamais de worktrees croisés avec des clients différents sur la même machine. Si tu travailles pour le client A et le client B, ce sont deux dossiers racine distincts, deux sessions Claude Code distinctes, aucun chemin partagé. Le coût opérationnel est faible, le bénéfice de séparation est absolu.
Règle 2 : les secrets vivent dans un gestionnaire. 1Password CLI, Doppler, Vault, peu importe le choix, mais jamais de .env commité, jamais de credentials en clair à la racine partagée d'un poste de dev. Un agent qui n'a rien à lire ne peut rien fuiter. C'est la règle la plus rentable des trois.
Règle 3 : le dossier .claude/ est du code de prod. Toute modification de settings.json, de hooks ou d'agents personnalisés passe en revue avant merge, comme n'importe quel changement de code. Versionne-le, commit-le, review-le. Un settings.json permissif poussé sans revue est une régression de sécurité, pas une amélioration d'expérience développeur.
Rappel de fond, à répéter à chaque nouveau membre d'équipe : Claude Code exécute du code. Ce n'est pas un chatbot. Le modèle de menace à garder en tête est celui d'un développeur junior avec accès shell. Compétent, rapide, mais qui a besoin d'un cadre. Les patches 2.1.216 et 2.1.222 réduisent la surface d'attaque du moteur. Ton cadre organisationnel fait le reste.
Passer à la pratique lundi matin
Ordre d'action pour la semaine : vérifier la version sur tous les postes et CI, resserrer les settings.json en allowlist explicite, désactiver les auto_allow sur les hooks sensibles, migrer les secrets hors des dépôts, et poser la règle worktree = projet unique. Deux heures de travail, un mois de tranquillité.
Si tu veux structurer cette démarche à l'échelle d'une équipe, avec des agents Claude Code qui tournent en autonomie sans que tu passes ta semaine à surveiller les permissions, c'est exactement ce que couvre notre formation Claude Agent pour piloter vos agents autonomes dans un cadre sécurisé. Cinq semaines, dix sessions live, cinq agents opérationnels à la fin. Pour aller plus loin sur la sécurité côté agent une fois le cadre posé, ce guide sur la sécurisation d'un agent Claude approfondit les patterns défensifs.