Claude Code 2.1.309 : le sandbox et les permissions se durcissent partout

La 2.1.309 de Claude Code, sortie le 22 octobre 2026, ne ressemble à aucun des digests récents de ce site. Elle ne lance aucune fonctionnalité spectaculaire : elle referme une dizaine de trous de sécurité dans le sandbox et le système de permissions, d'un coup, et elle change trois comportements par défaut que beaucoup d'utilisateurs tiennent pour acquis. Si tu lances Claude Code en mode bypass permissions, si sed -i fait partie de tes habitudes, ou si tu passes par claude ultrareview depuis un script, cette version te concerne directement. La 2.1.308 qui la précède ne portait, elle, qu'une ligne : « correctifs de bugs et améliorations de fiabilité », sans détail public.

Une dizaine de trous de sandbox et de permissions colmatés d'un coup

Le sandbox Bash isole les commandes shell au niveau du système d'exploitation : il limite les fichiers et les hôtes réseau qu'une commande peut atteindre, ce qui permet à Claude Code d'exécuter certaines commandes sans te demander confirmation à chaque fois. La 2.1.309 corrige plusieurs façons d'échapper à cette isolation. Sur macOS et Linux, les fichiers de démarrage du shell, comme .bashrc ou .zshrc, s'exécutaient hors du sandbox avant chaque commande : un morceau de code logé là pouvait tourner sans aucune restriction. Sur macOS, une règle denyWrite qui vise un dossier accessible par un lien symbolique ne s'appliquait pas à son emplacement réel, ce qui revenait à laisser une porte ouverte derrière la porte fermée. Une commande sandboxée, ou une édition de fichier auto-acceptée, pouvait modifier le fichier de configuration MCP passé avec --mcp-config. En mode print et dans les sessions SDK, un serveur MCP que tu avais désactivé pouvait aussi se reconnecter via une invite de permission ultérieure. Enfin, quand le sandbox est activé mais ne peut pas tourner, les commandes que tes réglages excluent du sandbox (excludedCommands) demandent désormais confirmation avant d'écrire dans les chemins de sa liste d'écriture, et le repli sans sandbox y est refusé.

Du côté des permissions, le correctif le plus parlant touche le contrôle qui décide si une commande Bash a besoin de ton feu vert avant de s'exécuter : il faisait confiance à une variable définie par une commande dont la redirection pouvait échouer à s'ouvrir, ce qui pouvait laisser passer une commande sans la bonne vérification. Des commandes composées qui changent de dossier avant de lancer git échappaient à l'invite que déclenche normalement un cd seul. Une règle Edit(path) qui refuse l'écriture sur un fichier ne bloquait pas une redirection Bash visant ce même fichier dans certaines commandes à sous-shell. Les sessions isolées par worktree laissaient passer des commandes préfixées par une locale, ou certaines commandes arithmétiques en zsh, que le garde-fou d'isolation est pourtant censé refuser. Le changelog ne dit ni comment ces trous ont été trouvés ni s'ils ont été exploités. Il liste en revanche deux autres correctifs du même ordre : sur Windows, certaines commandes PowerShell Set-Location ou cd visant le dossier courant avec des arguments en plus étaient auto-approuvées, et sur Linux, les interdictions d'écriture du sandbox sautaient quand une commande en arrière-plan survivait à la session.

sed -i devient une vraie commande Bash, et sort du filet de /rewind

Jusqu'ici, Claude Code traitait sed -i comme une édition de fichier simulée, avec un aperçu avant exécution, au même titre qu'un appel à l'outil Edit. La 2.1.309 change ça : sed -i reçoit désormais l'invite Bash standard et s'exécute telle qu'écrite, comme n'importe quelle autre commande shell. La conséquence concrète est à connaître avant de la découvrir en pratique : la page checkpointing documente que /rewind ne restaure pas les changements qu'une commande Bash fait à un fichier que Claude n'a pas déjà modifié avec ses propres outils d'édition. sed -i tombe maintenant dans ce cas, alors qu'avant la 2.1.309 il était suivi comme une édition normale et donc rattrapable. Si tu comptais sur /rewind pour annuler un sed -i malvenu, ce filet a disparu avec cette version : traite désormais sed -i comme tu traiterais rm ou tout autre outil destructeur en ligne de commande, en relisant la commande avant de l'approuver, et repose-toi sur git plutôt que sur /rewind pour revenir en arrière.

claude ultrareview exige que tu fasses confiance au dossier

Ultrareview lance une revue de code approfondie dans un bac à sable cloud, avec une flotte d'agents qui vérifient chaque trouvaille avant de te la remonter. En session interactive, Claude Code te demande déjà de faire confiance au dossier avant de laisser agir des règles permissions.allow ou des répertoires additionnels issus du dépôt, via la boîte de dialogue de confiance du workspace. La sous-commande claude ultrareview, pensée pour tourner dans un script ou une CI sans session interactive, n'exigeait pas jusqu'ici cette confiance. La 2.1.309 l'impose : sur un terminal, elle pose la question (Trust <folder>? [y/N]) ; partout ailleurs, elle refuse net avec Error: Workspace not trusted plutôt que de continuer sur un dossier jamais validé. Pour un script ou une CI, deux options : ajouter --trust-workspace à la commande (l'option ne prend pas de valeur, place ton numéro de pull request ou ta branche de base avant), ou fixer CLAUDE_CODE_DISABLE_ULTRAREVIEW_TRUST_CHECK=1 dans l'environnement qui lance la commande. Si tes pipelines appellent déjà claude ultrareview sans l'un des deux, ils vont commencer à échouer avec cette version.

Le bypass permissions mode refuse les rm et rmdir dangereux au lieu d'attendre

En mode bypass permissions, Claude Code désactive la plupart des invites de permission, mais garde un filet pour les suppressions critiques, comme rm -rf /Applications ou rm -rf ~ : le mode affiche une invite avec un compte à rebours de deux minutes dans le terminal, et refuse la commande si le délai expire sans réponse, pour que les sessions sans surveillance continuent de tourner. Dans l'app Desktop et l'extension VS Code, où ce compte à rebours du terminal n'existe pas, la 2.1.309 remplace l'invite par un refus immédiat, accompagné d'une piste de réécriture qui indique comment reformuler la commande. Concrètement, une session sans surveillance dans ces deux interfaces ne s'arrête plus sur une invite de suppression : la commande est refusée et la session continue.

Le reste, en vrac

La 2.1.309 ajoute aussi, dans l'extension VS Code, un avertissement dans les logs qui dit quoi faire quand la dictée ou une requête de l'extension échoue à la vérification de certificat, utile derrière un proxy qui inspecte le trafic TLS. À la création ou à la réutilisation d'un worktree, git ne va plus chercher les objets à la demande, ni sur un clone ordinaire ni sur un clone partiel avec un sandbox Bash configuré : un tel clone partiel récupère désormais ses objets d'abord. La gestion d'un disque plein est plus claire, qu'il s'agisse d'une commande Bash coupée en plein milieu ou d'un démarrage sur un volume temporaire saturé. Dans l'extension VS Code, l'attente après chaque édition avant de revérifier les erreurs descend à 0,75 seconde dans la plupart des cas, contre 1 à 1,5 seconde avant. Le reste, soit la majorité des 62 correctifs listés, touche des usages périphériques : Claude Tag dans Slack, les sessions cloud, les runners auto-hébergés, et une dizaine de détails propres à l'extension VS Code. Rien de tout cela ne change une habitude de travail si tu n'es pas directement concerné.

Ce qu'il faut retenir

La 2.1.309 n'a rien d'une version de fonctionnalités : c'est une version de nettoyage sécuritaire, avec quatre changements qui touchent vraiment la façon dont tu travailles. Le sandbox et les permissions colmatent une dizaine de trous d'un coup, sed -i sort du filet de /rewind en devenant une commande Bash à part entière, claude ultrareview refuse de tourner en script sur un dossier jamais validé, et le bypass permissions mode refuse désormais net un rm ou rmdir dangereux dans l'app Desktop et VS Code plutôt que de demander confirmation. Si tu automatises des revues avec claude ultrareview, vérifie tes scripts avant qu'ils tombent sur Error: Workspace not trusted. Si tu utilises sed -i pour des éditions rapides, sache que /rewind ne te couvre plus.