Claude Code 2.1.260 : les permissions se resserrent, /diff arrive

Une seule version depuis le dernier digest, la 2.1.260 du 3 septembre. Le changelog officiel aligne plus de soixante entrées, mais le fil rouge est net : cette version revoit ce qu'une règle de permission, le mode sandbox strict et un fichier CLAUDE.md géré sont censés bloquer. Elle resserre d'un côté, elle relâche de l'autre. À côté de ça, un nouveau panneau /diff arrive en plein écran.

Les brèches de permission refermées

Trois correctifs bouchent des trous dans les contrôles de permission. Le premier est le plus large : une règle dont le chemin contient des parenthèses, pour protéger par exemple un dossier nommé (archive), était silencieusement ignorée par le sandbox Bash au lieu d'être appliquée. Un dossier que tu croyais protégé par une règle de refus restait donc modifiable, sans erreur ni avertissement. Les règles Read et Edit suivent la syntaxe des motifs .gitignore : une règle malformée doit bloquer l'accès, pas se taire.

Le deuxième corrige un cas voisin : une règle de refus au motif incompilable, un crochet [ jamais fermé par exemple, faisait échouer toute modification de fichier avec une erreur Invalid regular expression, même sur des chemins que la règle ne visait pas. Une telle règle de refus ne protège désormais que le chemin littéral qu'elle décrit, au lieu de casser tous les outils d'édition.

Le troisième touche zsh en particulier, et c'est le genre de détail que seul quelqu'un qui connaît le shell peut exploiter : assigner une valeur aux paramètres spéciaux REPORTTIME, REPORTMEMORY ou DIRSTACKSIZE peut cacher une substitution de commande $(...) qui s'exécute au moment même de l'affectation. Le classificateur de l'auto mode approuvait ça comme une simple assignation de variable. Ces commandes demandent maintenant confirmation, dans la même famille que les conditions [[ ]] refermées en 2.1.257 et déjà couvertes dans le digest de la 2.1.257-258 : zsh interprète certaines constructions différemment de bash, et l'auto mode doit suivre.

Le bac à sable change deux fois de comportement

Deux changements touchent au bac à sable lui-même, dans des directions opposées. D'un côté, les commandes tapées au prompt bash-mode, le préfixe !, tournent désormais hors du sandbox même quand le mode sandbox strict est actif, celui que la doc décrit comme ignorant complètement l'échappatoire dangerouslyDisableSandbox. La logique : taper !, c'est toi qui écris directement dans ton propre terminal, pas Claude qui exécute une commande générée. Si tu administres une flotte et que tu comptais sur le mode strict pour garantir qu'aucune commande, générée ou tapée, ne sorte jamais du sandbox, ce point mérite vérification : le bash-mode est désormais une sortie délibérée, par conception, pas une faille qu'on referme.

De l'autre côté, un changement de la 2.1.259 vient d'être annulé. Cette même version avait étendu la couverture des règles de refus Read() à davantage de formes de commandes Bash, un correctif que le digest de la 2.1.259 couvrait. Effet de bord non anticipé : une règle Read(./**/build/**), écrite pour protéger un dossier de build généré, bloquait aussi npm run build lui-même, dans tous les modes de permission y compris manuel, et faisait demander confirmation à des compositions comme cd DIR && grep même en auto mode. Le correctif est retiré en attendant une version qui ne casse pas la commande la plus banale d'un dépôt JavaScript.

CLAUDE.md géré ne déclenche plus de dialogue de sécurité

Un CLAUDE.md poussé par des réglages gérés déclenchait jusqu'ici le même dialogue d'approbation de sécurité qu'un hook ou une commande shell gérée. Ce n'est plus le cas : seuls les hooks, les commandes shell, les réglages sandbox et les variables d'environnement non sûres continuent d'exiger une validation explicite avant de s'appliquer. La doc des réglages gérés par serveur liste précisément ce qui compte comme un réglage à approuver, catégorie par catégorie. Un fichier d'instructions texte n'a jamais pu exécuter de code par lui-même ; le retirer de cette liste évite une invite qui n'apportait pas de garantie réelle, sans toucher aux catégories qui, elles, en apportent une.

Un panneau /diff en plein écran

Côté fonctionnalité, /diff ouvre un panneau à côté de la conversation en mode plein écran, qui affiche tes changements non commités au fur et à mesure que Claude édite. Jusqu'ici, vérifier ce qui avait changé demandait de sortir vers un git diff dans un autre terminal ou d'attendre la fin du tour pour relire le résumé. La même commande ferme et rouvre le panneau.

Fable 5.1, trois correctifs de suite

Fable 5.1 récolte trois correctifs dans cette version. Le sélecteur /model ne le proposait pas aux organisations qui y ont pourtant accès, seule la commande tapée explicitement fonctionnait. La mise en cache de prompt ne couvrait pas le contexte ajouté après un résultat d'outil, donc il repartait en entrée non mise en cache à chaque tour utilisant un outil, ce qui gonflait la facture des sessions agentiques qui enchaînent les appels d'outils. Et /effort invalidait le cache de prompt sur Fable 5.1 : changer d'effort en cours de session ne le fait plus. Aucun de ces trois ne change ce que tu dois faire : ils réparent ce que Fable 5.1 promettait déjà depuis son lancement, couvert dans le digest de la 2.1.257-258.

Le reste, en vrac

Une règle de permission suivie de texte après la parenthèse fermante, comme Bash(ls) x, ne correspondait jamais à rien et était ignorée en silence ; elle est maintenant signalée comme réglage invalide.
/cost et le champ prompt_cache de la status line indiquent maintenant la cause probable d'un raté du cache de prompt : définitions d'outils modifiées, prompt système changé, session inactive au-delà du TTL.
Les serveurs MCP fournis par le SDK (comme les connecteurs Desktop) manquaient parfois au premier tour d'une session et n'apparaissaient qu'au suivant.
Claude in Chrome échouait avec « Not connected » en pleine tâche dans les sessions cloud, quand un connecteur était ajouté ou retiré en cours de route.
/rewind annonçait un succès alors que les fichiers de sauvegarde du checkpoint étaient absents et que rien n'avait été restauré ; il laissait aussi un suivi de lecture périmé, provoquant des messages « File unchanged since last read » après une restauration.
La sélection de lignes dans l'IDE était perdue quand tu lançais un skill ou une commande avec des lignes sélectionnées.
L'auto-compact des modèles à un million de tokens (Opus, Fable) se déclenche maintenant avant d'atteindre la limite, et la compaction de récupération ne dépasse plus le délai de dix minutes sur les très gros contextes.
GitLab : la détection de dépôt fonctionne dans les sous-groupes imbriqués, et une référence owner/repo#123 pointe enfin vers gitlab.com plutôt que github.com dans un dépôt GitLab.
ctrl+l / cmd+k en mode plein écran efface maintenant la vue de la conversation comme un clear de terminal ; remonte pour retrouver les messages précédents.

Ce qu'il faut en retenir

Si tu es un utilisateur individuel, le point qui te concerne vraiment c'est /diff : essaie-le au prochain tour où tu veux vérifier une édition sans sortir du terminal. Le reste des correctifs de permission referme des trous que tu ne croisais sans doute jamais en pratique. Si tu administres une flotte, vérifie deux choses avant de faire confiance au mode sandbox strict : que tes règles Read et Edit avec parenthèses correspondent bien à ce qu'elles sont censées protéger, et que le bash-mode ! de tes utilisateurs n'est pas devenu, sans que tu le saches, la sortie de secours de ton isolement.