Claude Code 2.1.293-294 : des hooks qui ne bloquaient pas toujours ce qu'ils promettaient

La 2.1.293 de Claude Code, sortie le 7 octobre 2026, et la 2.1.294, sortie le lendemain, forment un duo contrasté. La première compte plusieurs dizaines d'entrées, pour l'essentiel des correctifs ponctuels sur des surfaces précises : Remote Control, vim, les mods, Claude Tag dans Slack. La seconde ne contient que deux lignes, et les deux visent la même chose : les hooks écrits en langage naturel, qui jugent plutôt que d'exécuter une commande. L'un pouvait laisser passer exactement ce qu'il était censé bloquer, l'autre faisait arrêter Claude trop tôt. À côté de ça, un bug sur le bypass permissions des sessions lancées depuis claude agents referme un autre angle mort de permissions, et Claude Haiku 5.5 arrive comme nouveau modèle Haiku par défaut.

Des hooks qui jugent, et qui jugeaient mal

Un hook Claude Code classique exécute une commande shell qui renvoie un code de sortie, net et binaire. Mais la doc sur les hooks le confirme : « Claude Code supports prompt-based hooks (type: "prompt") that use an LLM to evaluate whether to allow or block an action, and agent hooks (type: "agent") that spawn an agentic verifier with tool access. » Autrement dit, un hook qui dit « bloque les commandes qui touchent à la production » n'exécute aucun filtre déterministe : il envoie la situation à un modèle, qui répond par un JSON {"ok": true/false, "reason": "..."}, et Claude Code applique la décision qui en sort. Pratique pour une règle trop floue pour un if shell, mais la fiabilité du blocage dépend alors du jugement du modèle appelé, pas d'un test qui tombe juste à chaque fois.

La 2.1.294 corrige justement un cas où ce jugement se trompait : un hook prompt ou agent écrit comme une instruction, le changelog donne l'exemple « Block commands that... », pouvait laisser passer l'action qu'il était censé bloquer. La même version touche aussi aux hooks prompt placés sur Stop et SubagentStop : un hook écrit « Carry on if the build is broken » juge, à chaque tour, si Claude doit continuer ou s'arrêter, et la 2.1.294 améliore ce jugement pour que Claude s'arrête moins souvent trop tôt. Les agent hooks restent de toute façon annoncés comme expérimentaux, la doc le dit sans détour : « Agent hooks are experimental. Behavior and configuration may change in future releases. For production workflows, prefer command hooks. » Et si un blocage doit tenir à coup sûr, la doc sur les permissions rappelle que ce sont les règles deny qui ont le dernier mot, pas un hook : « PreToolUse hook decisions don't bypass permission rules. Claude Code evaluates deny and ask rules regardless of what a PreToolUse hook returns. » Un hook en langage naturel reste un bon filet de rattrapage éditorial, pas un mur.

Le bypass permissions mal transmis aux sessions lancées depuis claude agents

claude agents --dangerously-skip-permissions permet de lancer plusieurs sessions en arrière-plan directement en mode bypassPermissions (--allow-dangerously-skip-permissions le rend seulement disponible dans leur cycle Shift+Tab), un mode qui saute les demandes de confirmation sauf les actions qu'aucun mode n'approuve automatiquement. Avant de l'accorder, Claude Code exige une acceptation explicite et unique : d'après la doc sur la vue des agents, « Claude Code refuses claude --bg --permission-mode bypassPermissions until you've accepted the bypass disclaimer by running claude --dangerously-skip-permissions once interactively, since that mode lets a session you aren't watching act without approval. »

La 2.1.293 corrige un cas où cette vérification se faisait mal : quand l'acceptation n'était enregistrée que dans .claude/settings.local.json ou dans un fichier passé via --settings, les sessions lancées en arrière-plan l'ignoraient. claude agents proposait le bypass, mais la session qui démarrait ne l'obtenait pas forcément, sans que rien ne te le signale. Ça recoupe une règle déjà documentée pour defaultMode : une valeur posée dans les réglages de projet ou locaux ne suffit pas à élever les droits d'une session, seuls les réglages managés, un fichier --settings ou ~/.claude/settings.json comptent pour auto et bypassPermissions. Depuis la 2.1.293, Claude Code demande d'abord le consentement avant de lancer la session, et si une session finit malgré tout sans bypass, une notice courte reste affichée pour le dire, plutôt que de laisser croire que le mode s'est appliqué.

Claude Haiku 5.5 devient le modèle Haiku par défaut

La 2.1.293 ajoute Claude Haiku 5.5 (claude-haiku-5-5), qui devient le modèle Haiku par défaut sur l'API Anthropic. Il a la fenêtre de contexte à 1M tokens commune à toute la gamme actuelle, et son tarif reste dans la logique « rapide et pas cher » de la lignée Haiku : le changelog le situe à 0,10 $ / 0,50 $ par million de tokens en entrée / sortie, et à 0,50 $ / 2,50 $ pour les prompts de plus de 100 000 tokens. La page des modèles le positionne pour les tâches à haut volume et sensibles à la latence, comme la classification, l'extraction ou le routage.

Le reste, en vrac

• Compaction de contexte : Claude traitait parfois ses propres dernières actions avant une compaction comme terminées après elle, et revenait dessus ou les refaisait sans que ça soit nécessaire. Corrigé dans la 2.1.293.
• Fuite mémoire MCP : une connexion MCP en HTTP conservait en mémoire chaque requête envoyée jusqu'à sa fermeture.
• ← et message en attente : déplacer une session vers l'arrière-plan avec ← pouvait faire perdre un message envoyé pendant que Claude travaillait ; si un message en file d'attente ne peut pas suivre, ← reste maintenant sur place et te le signale.
• Règles de projet ignorées en lecture : les règles limitées à un chemin et les fichiers CLAUDE.md imbriqués ne se chargeaient pas quand Claude lisait un seul fichier via cat, head, tail, sed -n ou grep dans l'outil Bash plutôt qu'avec l'outil Read. Si tes règles de projet semblaient parfois ignorées sans raison apparente, voilà une explication plausible.
• Déconnexions surprises : claude logs, stop, kill, rm, ainsi que claude daemon status, stop, uninstall, pouvaient te déconnecter quand ta session avait expiré ou était sur le point de le faire.
• Windows, mauvais processus tué : arrêter une status line, un hook ou une commande shell pouvait terminer un tout autre processus ayant reçu le même identifiant entre-temps.
• Deux retours en arrière : la 2.1.293 annule la modification du message de refus du mode auto introduite en 2.1.281, et annule aussi le correctif de la 2.1.290 qui empêchait une session cloud de rester endormie après un redémarrage de conteneur ayant perdu le réveil d'une tâche /loop ou planifiée. Ce bug précis est donc redevenu actif : Claude n'en est plus averti et la session reste endormie. Si tu fais tourner des sessions cloud de longue durée, mieux vaut s'en souvenir.
• Artifacts : les bibliothèques chargées dans un artifact sont désormais épinglées à des versions précises, vieilles d'au moins deux semaines.
• Claude in Chrome : moins d'actions refusées quand le navigateur met du temps à répondre sur l'état de ses onglets.

Ce qu'il faut retenir

Si tu t'appuies sur des hooks prompt ou agent pour faire respecter une règle qui doit tenir à coup sûr, ces deux versions rappellent une limite de fond : ce sont des hooks qui jugent, pas des filtres qui s'exécutent, et un jugement se trompe parfois. Pour un blocage dur, une règle deny reste le seul mécanisme qu'aucun hook ne peut contourner. Si tu lances des sessions en arrière-plan avec claude agents --dangerously-skip-permissions, guette désormais la notice qui signale une session lancée sans bypass, surtout si ton acceptation du mode vit dans un fichier de réglages locaux. Et si tu fais tourner des sessions cloud longues avec des tâches planifiées, sache qu'un redémarrage de conteneur peut de nouveau les laisser endormies sans réveil : un bug que la 2.1.290 avait corrigé et que la 2.1.293 a réintroduit en annulant ce correctif. Pour le reste, Claude Haiku 5.5 devient le modèle Haiku par défaut, au tarif d'entrée de gamme habituel de la lignée.