Ing. Calogero Bono
Anthropic a publié sur GitHub la version 2.1.314 de Claude Code, l'outil qui travaille sur le code depuis le terminal, depuis VS Code et depuis Claude Desktop. La nouveauté la plus concrète est un nouveau réglage de permissions qui empêche Claude d'écrire des fichiers hors des dossiers de travail. Le reste est une longue liste de corrections, dont beaucoup visent ceux qui utilisent Claude Code en entreprise, avec passerelles, fournisseurs cloud et règles centralisées. Ce sont justement les détails de sécurité et de gestion qui décident si un outil de ce type entre ou non dans une équipe.
Quelques termes, avant d'entrer dans les faits. Une passerelle (gateway) est un serveur intermédiaire placé entre les développeurs et les modèles, qui permet à l'entreprise de contrôler qui utilise quoi. Un IdP (fournisseur d'identité) est le système qui gère les identités et les groupes d'utilisateurs. Bedrock, Vertex et Foundry sont les services cloud d'Amazon, Google et Microsoft à partir desquels on peut utiliser les modèles. Une compaction est le résumé d'une longue conversation, pour ne pas saturer la mémoire du modèle. Un hook est un script qui se déclenche à un moment précis, par exemple avant une commande.
Que fait le blocage des écritures hors dossier ?
Selon les notes de version publiées sur le dépôt officiel de Claude Code, le nouveau réglage s'appelle permissions.blockWritesOutsideWorkingDirectories. Lorsqu'il est activé, les outils Write, Edit et NotebookEdit refusent les chemins situés hors des dossiers de travail, dans tous les modes de permission.
Le détail final est celui qui compte. Jusqu'ici, même avec des règles strictes, le comportement dépendait du mode choisi. Ici, la note indique que le refus vaut dans tous les modes, y compris lorsque l'utilisateur a choisi de laisser plus de liberté à l'agent. Le nom de l'option montre qu'elle est facultative et qu'il faut l'activer.
Dans le même esprit vont quelques corrections sur le sandbox. La description de sandbox.excludedCommands indiquait que les commandes listées s'exécutaient toujours hors du sandbox, alors qu'elle précise désormais que chaque commande d'un appel doit correspondre à une entrée. Par ailleurs, les protections du sandbox ne s'appliquaient pas à un worktree ouvert avec claude -p --resume ou --continue, ce qui est désormais corrigé. Une autre correction concerne un fichier de paramètres exclu avec --setting-sources qui continuait à fournir certains réglages, comme les règles du mode auto et les consentements déjà enregistrés.
Que change-t-il pour la passerelle et les administrateurs ?
La passerelle des applications Claude reçoit une nouveauté pensée pour les organisations. Chaque upstream, c'est-à-dire chaque destination vers laquelle la passerelle achemine les requêtes, peut avoir une liste facultative de groupes. Seuls les développeurs appartenant aux groupes IdP listés sont envoyés vers cet upstream, y compris en cas de failover, c'est-à-dire lorsque la passerelle bascule sur une solution de secours après une panne.
Pour les upstreams Bedrock arrive guardrail_trace. Cela sert à enregistrer quel filtre des garde-fous d'Amazon Bedrock s'est déclenché sur une requête, sans sauvegarder le texte qui l'a déclenché. C'est un compromis utile pour comprendre pourquoi une requête a été bloquée sans conserver de données sensibles dans les journaux.
Plusieurs corrections concernent les paramètres gérés par les administrateurs.
- Les réglages TLS définis par un administrateur n'étaient pas appliqués dans les sessions de Claude Desktop, et ils le sont désormais.
- Avec forceRemoteSettingsRefresh défini uniquement dans les paramètres distants, une copie enregistrée et expirée n'était plus appliquée. Les sessions pouvaient démarrer sans politique si le serveur était injoignable.
- Sur les machines dotées de plugins gérés, le changement de modèle était refusé si un plugin personnel avait un manifeste cassé ou un téléchargement échoué.
- Si un administrateur limite le niveau d'effort d'un modèle, Claude Code abaisse l'effort, réessaie et indique le niveau utilisé. Auparavant, les sessions échouaient à chaque tour.
Un upstream Vertex de la passerelle pouvait en outre rester bloqué pendant plusieurs minutes lorsqu'un point de terminaison de jetons Google acceptait la connexion sans répondre. Cela aussi est corrigé.
Quelles corrections concernent Bedrock, Foundry et Vertex ?
La version contient plusieurs interventions pour ceux qui n'utilisent pas directement les API d'Anthropic.
Bedrock
Les sessions Bedrock avec beaucoup d'images échouaient à chaque tour, ainsi que /compact, avec une erreur d'entrée trop longue. Claude Code supprime désormais les images les plus anciennes puis compacte. Une autre correction concerne la proposition de mise à jour du modèle sur Bedrock et Vertex, qui réapparaissait à chaque démarrage même lorsque les paramètres gérés bloquaient le modèle.
Microsoft Foundry
Les sessions échouaient lorsque la ressource ne disposait d'aucun déploiement pour le modèle Sonnet, Opus ou Haiku par défaut. Claude Code se rabat désormais sur un modèle plus ancien de la même famille.
Passerelles tierces
Si une passerelle n'accepte pas les blocs tool_reference de la recherche d'outils, la requête est renvoyée une fois sans cette fonction, et la session s'en souvient. Il en va de même lorsqu'une passerelle ou un fournisseur refuse nommément l'un des en-têtes bêta de Claude Code, avec un nouvel envoi sans cet en-tête. Les identifiants de modèle écrits avec un point, comme claude-opus-4.8, étaient traités comme un modèle plus ancien, avec une fenêtre de contexte, une limite de sortie, un effort, des modes de raisonnement et un coût erronés. Ce n'est plus le cas.
Côté certificats, les connexions TLS échouaient avec UNABLE_TO_GET_ISSUER_CERT lorsque le magasin système contenait un certificat racine renouvelé et signé croisé avec son prédécesseur. Cela aussi est réglé.
Que change-t-il dans l'usage au quotidien ?
Pour ceux qui écrivent du code, la nouveauté visible est la compaction au repos dans VS Code et dans l'onglet Code de Claude Desktop. Une conversation de plus de 200K tokens laissée inactive est résumée, et ce résumé est utilisé au message suivant si le cache du prompt a expiré.
Viennent ensuite plusieurs corrections liées au terminal et à l'intégration continue.
- claude -p se terminait avec le code 0 et sans sortie si le démarrage échouait. Il affiche désormais l'erreur et se termine avec 1, ce qui compte pour les scripts.
- claude ultrareview et claude remote-control ne posent plus la question de la confiance dans le dossier dans un job CI avec terminal. Avec CI défini, ils refusent immédiatement un dossier non fiable.
- Un hook PreCompact avec une sortie très volumineuse faisait échouer ou répéter la compaction. La sortie de chaque hook est désormais tronquée à 10 000 caractères.
- Les mises à jour du diff en arrière-plan prenaient brièvement le verrou de l'index du dépôt, ce qui pouvait faire échouer une commande git lancée au même moment.
- Les hooks qui interceptent Bash ne se déclenchaient pas sur les commandes lancées par l'outil Monitor. Ils se déclenchent désormais, mais ils peuvent bloquer ou demander une confirmation, sans approuver ni réécrire ces commandes.
Le reste concerne des retouches d'interface, comme les tableaux markdown, le mode vim, la sélection des agents, le collage de texte et d'images, les titres de session et les boîtes de dialogue de permission.
Limites à connaître
La note de version dont nous disposons est tronquée à la fin, donc nous ne pouvons pas exclure d'autres entrées. Nous n'avons pas la date de publication, et il n'existe pas de documentation détaillée du réglage sur les écritures. Nous ne savons pas s'il est actif par défaut, et le texte laisse penser que non. Nous ignorons aussi comment est défini précisément un dossier de travail, par exemple avec des liens symboliques ou des dépôts liés.
Il s'agit de déclarations de l'éditeur, non de tests indépendants. Un blocage sur les outils d'écriture ne dit rien de ce que peut faire une commande shell, qui suit les règles du sandbox. Il faut aussi lire avec prudence la phrase sur les hooks et Monitor, car elle change ce qu'un hook peut garantir.
Ce que cela change pour ceux qui travaillent dans le numérique
Si tu diriges une équipe, la première chose à faire est de lire la liste et de comprendre quelles corrections touchent ton cas. Ceux qui utilisent Bedrock avec beaucoup d'images, Foundry avec des déploiements partiels ou une passerelle d'entreprise trouvent des corrections directes. Ceux qui travaillent seuls avec le forfait de base voient surtout la compaction au repos et les retouches.
Pour une agence ou une société de développement, la règle sur les écritures est un argument à présenter aux clients. Elle montre qu'un agent peut être confiné au projet, ce qui est utile lorsque plusieurs dépôts ou fichiers de configuration se trouvent sur le même ordinateur. Le principe de fond reste valable – un agent doit être traité comme un collaborateur disposant d'accès minimaux. On l'a vu aussi avec l'extension piégée de Claude Code sur Cursor avec backdoor SSH, où le risque venait de l'environnement entourant l'outil.
Ceux qui lancent en CI des scripts avec claude -p doivent revérifier les codes de sortie. Une erreur qui passait auparavant pour un succès arrêtera désormais le pipeline, ce qui est la bonne chose, mais cela peut surprendre. Si tu fais tourner des environnements de développement sur tes propres serveurs, n'oublie pas que la machine compte aussi, et c'est pourquoi il faut des serveurs gérés avec mises à jour de sécurité.
Notre avis
Cette version en dit long sur la phase que traversent les agents de programmation. Les nouvelles fonctions sont peu nombreuses, tandis que la partie importante est faite de corrections sur des cas limites, des proxys, des certificats, des politiques et des solutions de repli. C'est le signe d'un outil qui sort de l'ordinateur portable du développeur isolé pour entrer dans des contextes où rien ne doit rester ambigu.
Le blocage des écritures hors dossier est le bon choix, mais il laisse deux doutes. Le premier est qu'il soit facultatif. Une protection qu'il faut connaître pour l'activer ne protège vraiment que ceux qui sont déjà vigilants. Le second est que le sujet des permissions demande autant de corrections, entre réglages exclus qui continuaient à s'appliquer et hooks qui ne se déclenchaient pas. Ce n'est pas une faute, mais cela rappelle que les contrôles doivent être vérifiés et non tenus pour acquis.
Reste la question de qui contrôle le code généré. Un agent plus confiné ne remplace pas la relecture humaine, et c'est pourquoi restent utiles les pratiques de pull request et code review sur GitHub ainsi que les outils d'IA pour la code review.
Questions fréquentes
Que fait permissions.blockWritesOutsideWorkingDirectories ?
Il fait refuser à Write, Edit et NotebookEdit les chemins situés hors des dossiers de travail. Selon les notes de version, il vaut dans tous les modes de permission. Nous n'avons pas de détails sur le traitement de cas particuliers comme les liens symboliques.
Le blocage est-il actif par défaut ?
Les notes ne le disent pas explicitement. Elles parlent d'un nouveau réglage ajouté, il est donc prudent de le vérifier dans ta configuration. Consulte la documentation officielle avant de considérer la protection comme acquise.
Ceux qui utilisent Bedrock ou Foundry doivent-ils mettre à jour ?
Si tu as rencontré les problèmes décrits, oui. La version corrige les sessions Bedrock avec beaucoup d'images et le cas de Foundry sans déploiement pour le modèle par défaut. Avant de mettre à jour les ordinateurs de toute l'équipe, teste la version sur une seule machine.
Que sont les groupes sur les upstreams de la passerelle ?
Il s'agit d'une liste facultative de groupes IdP associée à chaque upstream. Seuls les développeurs de ces groupes y sont acheminés, y compris en failover. Cela sert à séparer qui peut utiliser quelles destinations.
La compaction au repos est-elle disponible partout ?
Non, selon la note elle a été ajoutée à VS Code et à l'onglet Code de Claude Desktop. Elle concerne les conversations de plus de 200K tokens laissées inactives. Le résumé n'est utilisé que si le cache du prompt a expiré.
Ce qu'il faut suivre dans les prochains mois, entre permissions et agents en entreprise
Le sujet n'est pas cette version mais la direction prise. Les agents auront de plus en plus de contrôles centralisés, et il vaut mieux s'y préparer dès maintenant.
- Vérifie ta configuration des permissions et décide s'il faut activer le blocage des écritures hors dossier, peut-être d'abord sur un projet de test.
- Contrôle les scripts CI qui utilisent claude -p, car désormais une erreur de démarrage sort avec le code 1 et peut arrêter le pipeline.
- Si tu utilises une passerelle ou un fournisseur cloud, relis la liste complète des corrections et compare les cas avec tes journaux. Pour comprendre les coûts des différents fournisseurs, lis aussi la comparaison entre Claude et OpenAI, et garde à l'esprit que les pannes en cours sur plusieurs modèles peuvent aussi te toucher.
