Claude Code 2.1.248 : un mode restreint arrive, et tes longues sessions perdaient leur cache toutes les heures

Deux versions depuis la 2.1.247, dont une seule a des notes, et elle est énorme. Le nouveau drapeau --restricted coupe l'exécution et ignore tes réglages utilisateur, un correctif rend le cache de prompt que le rafraîchissement de jeton faisait tomber une fois par heure, et les sessions cloud amorcées depuis ta machine n'emportent plus tes fichiers de secrets en cours d'édition.

claude-code changelog securite

Deux versions depuis le dernier digest : la 2.1.248 du 27 août et la 2.1.250 du 28. La 2.1.249 n'existe pas, elle a sauté. Et la 2.1.250 se résume à « Bug fixes and reliability improvements », soit la troisième version muette du mois : tout est dans la 2.1.248, et elle est copieuse.

Le fil rouge n'est jamais énoncé, mais il est net une fois qu'on aligne les entrées : cette version resserre le périmètre. Ce que Claude Code a le droit d'exécuter, ce qu'il a le droit de lire, et ce qui a le droit de sortir de ta machine. En dessous, un second fil, plus discret et plus rentable : trois correctifs sur le cache de prompt. Voilà le tri.

--restricted : un Claude Code qui n'exécute rien et ignore tes réglages

C'est l'ajout de la version, et il change une catégorie entière d'usages. Le nouveau drapeau --restricted, ou la variable CLAUDE_CODE_RESTRICTED=1, démarre une session amputée :

  • les outils intégrés qui exécutent des commandes ou du code disparaissent, ainsi que WebFetch ;
  • les outils de fichiers restent confinés aux répertoires de travail ;
  • le mode bypassPermissions est refusé, y compris son alias --dangerously-skip-permissions ;
  • les fichiers de réglages utilisateur, projet et locaux ne sont plus chargés.

La doc du drapeau ajoute trois choses que le changelog laisse de côté, et chacune compte.

La première, c'est l'usage visé. La doc ne parle pas de « mode sûr » générique : elle écrit noir sur blanc que c'est pour le cas où « un harnais d'évaluation pilote claude sur une machine partagée et où Claude Code ne doit ni exécuter de commandes ni lire les réglages utilisateur et projet de cette machine ». C'est un mode de confinement de configuration, pas un bac à sable. Si ton besoin est de faire tourner du code hostile sans risque, la réponse reste le sandboxing, pas ce drapeau.

La deuxième, c'est la nuance sur --tools. Tu peux récupérer les outils retirés, mais seulement en les nommant individuellement dans --tools. Le préréglage default ne les ramène pas. Autrement dit, --restricted --tools default ne rouvre rien, contrairement à ce qu'on pourrait croire en lisant vite.

La troisième, c'est le périmètre exact des réglages. Le changelog dit « ignore les fichiers de réglages utilisateur, projet et locaux ». La doc formule la même règle par la positive, et c'est plus utile : la session charge uniquement les managed settings et ce que tu passes en --settings. Un administrateur garde donc la main, et toi tu pars d'une base propre et explicite.

Une dernière remarque qui a son importance si tu scriptes : le drapeau exige la 2.1.248 ou plus récent. Sur une version antérieure, il n'est pas ignoré poliment, il n'existe pas.

Ton cache de prompt tombait une fois par heure

Le correctif le plus rentable de la version tient en une ligne au milieu de cinquante autres, et il faut la dérouler pour voir ce qu'elle coûtait :

Corrigé : un défaut de cache de prompt (et une perte du contexte de réflexion étendue) survenant environ une fois par heure dans les longues sessions, causé par les définitions d'outils re-rendues après un rafraîchissement du jeton OAuth.

Le mécanisme est déplaisant. Le cache de prompt fonctionne par correspondance de préfixe : tant que le début de ta requête est identique octet pour octet à celui du tour précédent, tu ne paies pas le retraitement. Les définitions d'outils vivent tout au début de ce préfixe. Un rafraîchissement de jeton OAuth les faisait re-rendre, le préfixe changeait, et tout le cache tombait. Comme les jetons se rafraîchissent à intervalle régulier, ça se produisait à peu près chaque heure, sur une session d'autant plus chère à reconstituer qu'elle était longue. La perte du contexte de réflexion étendue au passage est le deuxième prix à payer, et celui-là ne se voit pas sur une facture.

Cousin immédiat, un second correctif de cache : la définition de l'outil ScheduleWakeup changeait entre une session et son --resume quand le compte était passé en dépassement d'usage, ce qui provoquait un défaut de cache complet au premier tour de la session reprise. Même mécanique, même cause racine, une définition d'outil instable.

Troisième entrée du même fil, et celle-ci est un gain de contexte pur : l'empreinte de l'outil Workflow passe d'environ 5 700 tokens à environ 1 000, la référence d'écriture de scripts ayant été déplacée dans un skill workflow-authoring chargé à la demande. C'est la même logique que le tool search des serveurs MCP : ne mettre dans le prompt que ce qui sert, différer le reste. Environ 4 700 tokens rendus à chaque session, sans rien faire.

Et pendant qu'on est sur le cache, la version ajoute experimental.cacheTtl ("5m" ou "1h") au frontmatter d'un agent : une durée de vie de cache par agent, utilisée quand aucun réglage de TTL de sous-agent n'est configuré. C'est la suite directe de ce qu'on décrivait dans le digest de la 2.1.243 à 2.1.245 : promptCacheTtl couvre la conversation principale, subagentPromptCacheTtl couvre tout le reste, et voilà maintenant le cran plus fin, agent par agent.

Deux précautions avant de t'en servir. D'abord le préfixe experimental. n'est pas décoratif : le champ est absent du tableau des champs de frontmatter de la doc des sous-agents, qui liste name, description, tools, model, permissionMode, maxTurns et compagnie sans lui. Non documenté veut dire susceptible de changer de nom ou de disparaître. Ensuite, l'heure de cache se facture : les écritures en cache coûtent plus cher, donc un agent qui travaille par rafales courtes paie la surcharge sans jamais profiter de la durée. Le bon candidat, c'est l'agent qu'on rappelle après une longue pause.

Trois familles de fichiers de secrets qui montaient dans le cloud

Le correctif de sécurité de la version, et il mérite qu'on s'y arrête parce qu'il concerne des fichiers que personne n'a l'idée de surveiller :

Corrigé : /ultrareview et les sessions cloud amorcées localement téléversaient les modifications non validées de fichiers du type prod.env et *.tfvars, ainsi que les copies d'éditeur (swap, temporaires, sauvegardes) de fichiers d'identifiants (par exemple key.pem.tmp, id_rsa.swo) ; elles restent maintenant sur ta machine.

Il faut connaître le mécanisme d'amorçage pour mesurer la portée. La doc d'ultrareview est explicite sur ce point : pour une revue de branche, « Claude Code empaquette l'état du dépôt et le téléverse vers un bac à sable distant », alors que pour une revue de pull request, « Claude Code ne téléverse rien depuis ta machine ». Le paquet inclut les modifications non validées, c'est précisément ce qui fait l'intérêt de la revue de branche : elle voit ton travail en cours.

Le filtre existait donc déjà, mais il ratait trois catégories. Les fichiers d'environnement dont le nom ne colle pas au motif attendu, prod.env plutôt que .env. Les *.tfvars de Terraform, qui contiennent régulièrement des identifiants d'infrastructure. Et surtout les artefacts d'éditeur : key.pem.tmp, id_rsa.swo. Ceux-là sont les plus vicieux, parce qu'ils apparaissent tout seuls dès que tu ouvres une clé dans vim, portent un nom que ton .gitignore ne couvre probablement pas, et survivent à un crash de l'éditeur sans que tu le saches.

Rien à faire côté configuration, le correctif est dans le client. Mais deux réflexes à en tirer. Si tu as lancé des revues de branche sur un dépôt qui contient ce genre de fichiers, c'est le moment de considérer que ces secrets ont quitté ton poste, avec la politique interne que ça implique. Et pour la suite, souviens-toi que la revue de PR ne téléverse rien : quand le contenu du répertoire est sensible, pousse la branche et passe le numéro de PR.

Toujours sur les identifiants, la même version cesse d'envoyer sur le mauvais écran : les noms de modèles dans /model et dans les avis de bascule du mode rapide sont désormais rendus en code, de sorte qu'un suffixe comme [1m] s'affiche littéralement au lieu d'être interprété en lien.

claude agents cesse de manger tes worktrees et tes sessions

Une grappe de correctifs sur la vue agents et les sessions d'arrière-plan, dont trois qui détruisaient ou perdaient quelque chose.

Le worktree emporté sous la session. Une session d'arrière-plan perdait son checkout : elle conserve maintenant le verrou du worktree pendant son exécution, de sorte que le nettoyage et un git worktree remove la laissent tranquille. C'est le second digest d'affilée où un balayage automatique supprimait un worktree occupé.

La session zombie de trois semaines. La vue agents ressuscitait une session d'arrière-plan vieille de plusieurs semaines après une extinction de la machine. Elle s'affiche désormais comme arrêtée à sa vraie fin, et l'ouvrir demande confirmation avant de reprendre la conversation sauvegardée. Dans la même veine, ouvrir une session arrêtée que tu avais déjà reprise dans un autre terminal ne démarre plus un second processus sur la même conversation : la ligne indique qu'elle est ouverte ailleurs.

Le refus de suppression sur une branche pourtant mergée. claude agents et claude rm refusaient de supprimer une session avec « has commits that are not pushed anywhere » alors que la branche de son worktree était déjà fusionnée dans ta branche par défaut locale, simplement pas encore poussée. Le garde-fou était juste dans l'intention et faux dans la mesure.

Deux correctifs de diagnostic complètent la grappe, et ils visent le même angle mort : un hook qui répond n'importe quoi. Une session d'arrière-plan attendait en silence quand un hook PermissionRequest ou PreToolUse imprimait une réponse invalide ; la ligne nomme maintenant le hook et l'erreur de schéma. Et un objet {…} sur la sortie standard d'un hook qui n'est pas du JSON valide n'est plus traité silencieusement comme du texte brut, il remonte en erreur de hook avec le message d'analyse. Si tu écris des hooks, ces deux-là t'épargneront une soirée.

Les messages entre sessions débarquent sur Bedrock, Vertex et Foundry

La messagerie entre sessions (SendMessage et ListAgents) fonctionne maintenant entre sessions d'une même machine sur Amazon Bedrock, Google Vertex et Microsoft Foundry, et dans les sessions à télémétrie désactivée. C'est un déblocage réel : la fonctionnalité dépendait de l'évaluation d'un feature flag, donc n'importe quelle variable coupant le trafic non essentiel la désactivait au passage.

Attention en revanche si tu vas vérifier dans la doc : au moment où on écrit, la section Availability liste toujours ces mêmes plateformes comme non prises en charge, et indique encore que DISABLE_TELEMETRY ou DO_NOT_TRACK suffisent à couper la messagerie. La doc n'a pas rattrapé le changelog, qui date d'hier. Fie-toi à /list-agents dans ta session plutôt qu'à la page.

Trois ajustements accompagnent l'ouverture. Une valeur invalide de crossSessionInbound n'est plus ignorée en silence : elle déclenche un avertissement et met les messages en attente si elle vient de tes réglages utilisateur, ou les refuse si elle vient des managed settings. Le mécanisme se rabat sur un répertoire /tmp privé par utilisateur quand le répertoire par défaut est inutilisable, et l'avis comme /status nomment le répertoire à corriger. Enfin, dans les espaces de noms utilisateur Linux, la confiance équivalente à root pour les propriétaires non mappés est limitée aux répertoires système canoniques : un durcissement discret, mais c'est exactement le genre de raccourci qui donne une élévation de privilèges en conteneur.

Dernier point de la même famille : un SendMessage envoyé depuis un sous-agent vers une autre session précise désormais dans son résultat que la réponse éventuelle arrivera dans la conversation de la session parente, pas au sous-agent. Détail d'ergonomie pour un humain, correction importante pour un agent qui attendrait une réponse qui n'arrivera jamais chez lui.

Le reste, en vrac

  • Tes sessions Desktop et Cowork ne disparaissent plus au bout de 30 jours. Le nettoyage des transcripts conserve maintenant les sessions écrites par le bureau tant qu'elles sont dans l'application, sauf si une politique d'organisation gère la rétention. Le nouveau réglage desktopSessionCleanupPeriodDays plafonne cette exemption.
  • /loop en mode dynamique et le mode autonome sans prompt sont désormais toujours disponibles, y compris sur Bedrock, Vertex et Foundry.
  • /usage-credits arrive pour les organisations Enterprise facturées via AWS Marketplace, l'Enterprise en self-serve et les essais Enterprise, pour demander un relèvement de limite à son administrateur. Symétriquement, les messages de limite de débit et de mode rapide cessent de te renvoyer vers cette commande quand elle n'existe pas chez toi, par exemple sous DISABLE_EXTRA_USAGE_COMMAND.
  • /web-setup prévient quand ton jeton GitHub CLI n'a pas la portée workflow, parce que les poussées vers de très gros dépôts peuvent être refusées sans elle. Dans la même zone, /ultrareview <PR#> vérifie maintenant avant de lancer que le compte GitHub relié à ton compte Claude peut accéder au dépôt, et explique comment corriger, au lieu d'échouer une fois la session cloud démarrée.
  • Diagnostics des réglages gérés côté serveur : un avertissement au démarrage quand ils ne se chargent pas, et une ligne dans /doctor et /status expliquant l'échec ou la raison de l'absence de récupération (fournisseur tiers, ANTHROPIC_BASE_URL personnalisée).
  • Connexion : tu n'es plus renvoyé à l'écran de login quand un autre processus Claude Code détient le verrou de rafraîchissement du jeton alors que le tien a expiré, la requête échoue avec une erreur réessayable. Et la connexion Console recommandée dans /login, qui échouait sur une erreur OAuth avant même d'afficher une URL sur les machines où elle est inutilisable (ANTHROPIC_API_KEY défini, helper de clé configuré), bascule maintenant sur la connexion par clé d'API.
  • Windows et terminaux : la liste claude agents ne répondait plus au clavier après un détachement de session, ou dans un onglet resté en win32-input-mode. claude logs laissait le suivi souris, le collage entre crochets et l'écran alternatif activés dans le terminal d'où il avait été lancé. Les avertissements de démarrage s'affichaient décalés d'une colonne vers la droite. Et le dialogue de confiance affichait un caractère abîmé quand une règle longue était coupée au milieu d'un emoji.
  • Ergonomie : shift+entrée dans le champ de dispatch de la vue agents insère un retour à la ligne comme dans le prompt, ctrl+entrée envoie et attache. L'indicateur de mode de permission ne reste plus caché derrière l'astuce « Press Ctrl-C again to exit » quand tu fais shift+tab juste après un ctrl+c. Les @-mentions d'autres sessions reconnaissent enfin les noms tapés en caractères non latins, coréen saisi via IME par exemple.
  • MCP et gateways : un serveur MCP dont le headersHelper fournit l'en-tête Authorization partait en découverte OAuth sur un 401 au lieu de rejouer le helper et de réessayer, comme la doc le promet. /mcp classait une entrée d'un .mcp.json de projet déclarant le type connecteur claude.ai sous l'en-tête de confiance « claude.ai », elle apparaît maintenant sous sa vraie portée. La découverte de modèles de gateway ne s'exécutait jamais quand apiKeyHelper est le seul moyen d'identification. Et un /login vers une passerelle Claude apps se bloquait quand le dialogue d'approbation de sécurité des managed settings était requis.
  • Divers : les sessions cloud échouaient parfois au démarrage quand les identifiants du conteneur n'étaient pas encore lisibles. Les sessions Remote Control n'affichaient parfois jamais de demande de permission ni les derniers messages après une reconnexion silencieuse. claude remote-control refusait ses propres options quand un drapeau global les précédait. Les échecs d'export de télémétrie Anthropic se journalisent désormais en [Anthropic telemetry] plutôt qu'en [3P telemetry] OTEL diag error, pour ne plus être pris pour une panne de ton collecteur. Le badge PR du pied de prompt interroge GitHub moins souvent tant que la PR ne bouge pas. Les variables d'environnement de délai client, de mode de démarrage MCP et de chien de garde de flux ne déclenchent plus l'approbation des réglages. Et sous VS Code, un onglet de discussion coincé sur « No conversation found » démarre maintenant une nouvelle conversation.

Ce qu'il faut en retenir

Une version à prendre, et une seule chose à décider aujourd'hui : si tu utilises /code-review ultra en mode branche sur des dépôts qui contiennent des fichiers d'environnement ou des clés, mets-toi à jour avant la prochaine revue, et prends dix minutes pour vérifier ce qui a pu partir avant. Le reste du temps, la revue de PR est le mode qui ne téléverse rien.

Pour tout le monde, la 2.1.248 rend du contexte et de l'argent sans rien demander : le cache qui ne tombe plus toutes les heures, et 4 700 tokens de description d'outil qui ne s'installent plus dans chaque session. C'est rare qu'une mise à jour se rentabilise aussi mécaniquement.

Et si tu automatises Claude Code sur une machine partagée, va lire --restricted. C'est le premier drapeau du client qui te donne une session dont tu connais exactement la configuration, parce qu'elle ne lit que la tienne.

Pierre Rondeau

Pierre Rondeau

Développeur et indie builder. Je construis des produits et automatisations avec l'IA. Créateur de Claude Hub.

LinkedIn