Claude Code 2.1.283 : le mode auto devient la norme, cmd ne contourne plus Remove-Item

La 2.1.283 de Claude Code, sortie le 25 septembre 2026, change une chose que la plupart des utilisateurs n'ont jamais eu à régler eux-mêmes : le mode de permission dans lequel une session démarre. Jusqu'ici réservé de facto aux plans Pro, Max et Team, le mode auto devient le point de départ par défaut partout, y compris sur Enterprise, sur un compte API direct et chez les fournisseurs tiers. À côté, un vrai trou de sécurité sur Windows est refermé : PowerShell laissait cmd supprimer une racine de disque là où Remove-Item refusait déjà de le faire. Le reste, plus de quatre-vingts entrées dominées par des correctifs de fiabilité et d'interface, est résumé en vrac plus bas.

Le mode auto devient le point de départ partout

La doc sur les modes de permission est directe sur ce que change la 2.1.283 : « With Claude Code v2.1.283 or later, auto mode is the built-in starting permission mode for interactive terminal and VS Code sessions on every plan and provider. On earlier versions, it's the built-in starting permission mode only on Pro, Max, and Team plans. » Concrètement, si tu lances une session terminal ou VS Code sans avoir défini permissions.defaultMode dans un fichier de réglages, elle démarre désormais en mode auto, qu'elle tourne sur l'API Anthropic, Claude Platform on AWS, Amazon Bedrock, Google Cloud's Agent Platform ou Microsoft Foundry. Avant cette version, ce point de départ automatique ne s'appliquait qu'aux sessions qui récupèrent les feature flags côté Pro, Max et Team ; tout le reste démarrait en mode Manuel.

Ce changement ne touche que le point de départ, pas les réglages déjà en place : le changelog le précise, permissions.defaultMode continue de faire foi dès qu'il est défini quelque part, et la référence des réglages rappelle l'ordre de priorité entre fichiers utilisateur, projet et managed. Si ton organisation a déjà fixé un mode par défaut, rien ne bouge. La bascule ne s'opère que pour les sessions qui n'avaient jamais rien précisé, ce qui vise surtout les comptes Enterprise, les comptes API et les fournisseurs tiers habitués au mode Manuel par défaut. Les exécutions claude -p et l'Agent SDK ne sont pas concernées : elles démarrent toujours en mode Manuel.

Le mode auto reste conditionné à un modèle qui le supporte : Opus 4.6 ou plus récent, Sonnet 4.6 ou plus récent, ou un modèle Fable sur l'API Anthropic et Claude Platform on AWS, et seulement Sonnet 5, Opus 4.7 ou plus récent, et les modèles Fable sur Bedrock, Google Cloud's Agent Platform, Microsoft Foundry et les sessions Claude apps gateway connectées. Une session sur un modèle plus ancien démarre en Manuel sans que tu aies rien à faire. La première fois qu'une de tes sessions démarre en auto par ce mécanisme, Claude Code affiche un avis qui pointe vers la documentation, une seule fois par interface. Si tu tiens au mode Manuel par défaut, notamment sur des comptes partagés, le geste à faire est simple : fixer permissions.defaultMode explicitement dans ~/.claude/settings.json ou dans les réglages managed de l'organisation plutôt que de compter sur l'ancien comportement implicite.

PowerShell : cmd ne contourne plus les protections de Remove-Item

Sur Windows, l'outil PowerShell de Claude Code applique déjà des vérifications séparées à Remove-Item : suppression refusée sans même demander sur la racine du système de fichiers, les racines de disque et leurs dossiers de premier niveau, et sur ton dossier personnel. Le problème, c'est que ces vérifications ne portaient que sur Remove-Item. Rien n'empêchait Claude d'obtenir le même résultat en passant par les commandes internes de cmd : rd, rmdir, del ou erase, lancées via cmd /c.

La 2.1.283 étend la même règle à ces commandes. La doc sur les chemins critiques est explicite : « The system-paths case also applies to rd, rmdir, del, and erase when Claude runs them through cmd, as in cmd /c rd /s /q C:\Users. By default, Claude Code denies such a command in every mode, without asking you. This cmd check requires Claude Code v2.1.283 or later. » Le refus s'applique dans tous les modes, y compris bypassPermissions, la doc le confirme ailleurs pour les refus Remove-Item du même type. La détection couvre aussi les cas moins évidents : une variable PowerShell placée après du texte littéral est traitée comme vide, donc cmd /c rd /s /q "C:\$name" est vu comme une suppression de C:\ et refusé ; un joker en fin de commande compte comme le dossier qu'il viderait, donc cmd /c del /q C:\* est bloqué alors que cmd /c del /q dist\* dans ton projet ne l'est pas.

Une variable d'environnement, CLAUDE_CODE_DISABLE_POWERSHELL_CMD_RM_DENY=1, permet de désactiver spécifiquement ce contrôle sur cmd si besoin, mais le refus sur Remove-Item lui-même reste actif quoi qu'il arrive. Si tu utilises Claude Code sur Windows avec l'outil PowerShell activé, ce correctif referme un contournement réel : jusqu'ici, un modèle qui aurait dû être bloqué sur une suppression dangereuse pouvait obtenir le même résultat par un chemin détourné.

Le reste, en vrac

• Contrôle des modèles autorisés : deux réglages managed s'ajoutent, availableModelsMatch: "exact" qui verrouille availableModels à la version précise d'un modèle plutôt qu'à toute sa famille, et deniedModels qui bloque des modèles précis même quand availableModels les autoriserait par ailleurs.
• /doctor prompt-audit (aussi /checkup prompt-audit) audite tes fichiers CLAUDE.md, skills, agents et commandes pour repérer des formulations de prompt pensées pour d'anciens modèles.
• Désinstallation de plugin : quand deux plugins installés ont des identifiants qui ne diffèrent que par la casse, claude plugin uninstall ne supprime plus l'autre plugin, avec ses options et ses secrets, à la place de celui qui est nommé.
• /context compte désormais les instructions envoyées par les serveurs MCP dans le total affiché, avec leur propre ligne.
• Sorties d'outils MCP : une image renvoyée par un outil MCP est maintenant aussi enregistrée dans un fichier, ce qui permet à Bash, Read et aux autres outils de l'ouvrir ensuite.
• Workflows dynamiques : un workflow lancé pendant un repli de modèle ne fait plus tourner tous ses agents sur le modèle de repli au lieu de retenter le modèle configuré.
• Le nom claude-ai redevient utilisable pour un skill, une commande, un workflow, ou les skills et prompts d'un serveur MCP : la réservation introduite en 2.1.282 est annulée, Skill(claude-ai:*) redevient une règle de préfixe ordinaire.
• Sandbox managed : un bloc sandbox des réglages managed n'est plus ignoré en entier quand une seule valeur imbriquée est invalide ; la valeur fautive échoue désormais en mode fermé et le reste du bloc s'applique.
• Code Review : une demande @claude review qui restait sans réponse parce que GitHub ne renvoyait pas la pull request est désormais retentée une fois automatiquement, avec un commentaire explicatif si l'échec persiste.

Ce qu'il faut retenir

Le changement le plus large est le premier : si tu gères des sessions Claude Code sur un compte Enterprise, une API directe, ou derrière Bedrock, Vertex ou Foundry, sans avoir jamais touché à permissions.defaultMode, tes prochaines sessions terminal ou VS Code démarreront en mode auto plutôt qu'en mode Manuel. Ce n'est pas une régression de sécurité, le mode auto garde ses propres garde-fous, mais c'est un changement de réflexe si tu comptais sur le mode Manuel par défaut pour valider chaque action. Vérifie ton réglage si tu veux garder la main. Le correctif PowerShell, lui, vaut d'être lu même sans y penser tous les jours : c'est exactement le genre de contournement qu'on ne découvre qu'après coup, et il est refermé sans rien à faire de ton côté.