Claude Code 2.1.314 corrige un fail-open de politique gérée et ajoute un paramètre qui bloque les écritures hors des répertoires de travail

Mettez à jour maintenant si vos garde-fous Claude Code vivent dans les paramètres gérés. Claude Code 2.1.314, daté du 30 octobre 2026 dans le journal des modifications d'Anthropic, corrige un cas où une session pouvait démarrer sans aucune politique. Il comble aussi trois failles plus ciblées dans le sandbox, les hooks et les sources de paramètres, et ajoute le premier paramètre qui fait refuser par les outils de fichiers de Claude toute écriture hors des répertoires de travail, dans tous les modes de permission. Notre notation de Claude Code reste conditionnelle : il s'agit d'une version de durcissement de routine, et la bonne réponse est de mettre à niveau, pas de reconsidérer l'outil.

Ce qui s'est passé

Le fail-open de politique gérée

Le journal des modifications (notre traduction) : « Correction : forceRemoteSettingsRefresh, défini uniquement dans les paramètres gérés distants, cessait de s'appliquer une fois la copie stockée expirée, ce qui laissait des sessions démarrer sans politique lorsque le serveur était injoignable ».

Concrètement : une organisation qui définissait forceRemoteSettingsRefresh uniquement dans ses paramètres gérés distants s'attendait à ce que Claude Code refuse de fonctionner sans gestion. Une fois la copie en cache expirée, ce paramètre cessait de s'appliquer : une machine incapable de joindre le serveur de paramètres démarrait donc une session sans politique. Les machines qui n'avaient jamais perdu le contact avec le serveur n'étaient pas exposées par ce chemin.

Trois autres corrections de permissions et de sandbox

Toutes traduites de l'entrée 2.1.314 :

• « Correction : les protections du sandbox ne s'appliquaient pas à un worktree rejoint par claude -p --resume ou --continue »
• « Correction : un fichier de paramètres exclu avec --setting-sources fournissait encore certains paramètres, comme les règles du mode auto et les consentements de permission enregistrés »
• « Correction : les hooks correspondant à Bash ne s'exécutaient pas sur les commandes shell lancées par l'outil Monitor ; ces hooks peuvent bloquer ou demander, mais pas approuver ni réécrire ces commandes »

Nouveaux paramètres de durcissement

• « Ajout de permissions.blockWritesOutsideWorkingDirectories : Write, Edit et NotebookEdit refusent les chemins hors des répertoires de travail dans tous les modes de permission »
• « Modification : les outils de fichiers de Claude demandent désormais avant de modifier la copie locale des paramètres gérés par le serveur de votre organisation, comme ils le font pour vos fichiers de paramètres »
• « Modification : les requêtes signalées réessaient sur un autre modèle au lieu de se terminer par un refus lorsque ANTHROPIC_DEFAULT_OPUS_MODEL, availableModels ou deniedModels ne laissent qu'un modèle Opus plus ancien, ou aucun »

La même entrée ajoute la compaction d'inactivité à VS Code et à l'onglet Code de Claude Desktop : « une conversation de plus de 200 000 tokens laissée inactive est résumée, et le résumé est utilisé à votre prochain message si le cache de prompts a expiré ».

Pourquoi c'est important

Le fail-open fait la une. forceRemoteSettingsRefresh existe pour qu'une machine gérée ne fonctionne pas sans politique, et il a échoué exactement dans le cas pour lequel il était prévu : un cache expiré plus un serveur injoignable. Toutes les règles de refus, tous les paramètres de sandbox ou toutes les restrictions de modèles fournis par les paramètres gérés distants étaient absents de ces sessions.

Les trois autres corrections suppriment chacune un contournement discret :

• Tâches headless reprises. Quiconque reprenait des tâches claude -p dans des worktrees sandboxés les exécutait sans les protections du sandbox.
• Fichiers de paramètres exclus. Un fichier exclu avec --setting-sources pouvait encore introduire des règles du mode auto et des consentements de permission enregistrés dans une session.
• Commandes de l'outil Monitor. Les commandes shell lancées par l'outil Monitor sautaient les hooks Bash : un hook bloquant ne se déclenchait donc pas sur elles.

Le nouveau paramètre permissions.blockWritesOutsideWorkingDirectories ne couvre que les outils de fichiers de Claude (Write, Edit et NotebookEdit). Le journal des modifications ne dit pas qu'il s'applique à Bash : une commande shell peut donc toujours écrire ailleurs, sauf si le sandbox ou une règle de refus l'arrête.

Ce qui change pour vous

• Flottes gérées : mettez à niveau chaque machine vers 2.1.314, en commençant par celles qui comptent sur forceRemoteSettingsRefresh pour bloquer les sessions sans politique.
• Pipelines headless : si vous exécutez claude -p --resume ou --continue dans des worktrees sandboxés, mettez à niveau avant la prochaine exécution.
• Exécutions sans surveillance : envisagez de définir permissions.blockWritesOutsideWorkingDirectories dans les paramètres gérés ou de projet, et associez-le au sandbox ou à des règles de refus Bash, car il ne couvre pas les commandes shell.
• Équipes utilisant --setting-sources : après la mise à niveau, revérifiez quelles règles du mode auto et quels consentements de permission enregistrés s'appliquent encore.

Ce que cela ne vous dit pas

Le journal des modifications ne cite aucun CVE et ne lie aucun avis de sécurité : il n'existe donc pas de cote de sévérité officielle. Il n'y a pas d'entrée 2.1.313 : le journal passe de 2.1.312 (27 octobre) directement à 2.1.314, sans donner de raison. Nous n'avons pas testé 2.1.314 nous-mêmes.