Claude Code 2.1.252 : trois pannes silencieuses, et la facture du durcissement

Une seule version depuis le dernier digest, la 2.1.252 du 31 août, et elle tient en quatre lignes. Que des correctifs, aucune nouveauté. Trois jours après la 2.1.251 et ses soixante-dix entrées, c'est le contraste qui raconte l'histoire : une vague de durcissement n'est jamais finie le jour où elle sort.

Le fil rouge de ces quatre bugs n'est pas technique, il est diagnostique. Un seul se nommait lui-même à l'écran. Les trois autres se manifestaient comme de la lenteur, de la maladresse ou une erreur qui pointait vers la mauvaise cause. C'est précisément le type de panne qu'on met sur son propre compte pendant des jours avant de la signaler.

Celui qui parlait : task output swap refused

Corrigé : les commandes Bash échouaient avec « task output swap refused (tasks dir moved or linked) » sur certains Mac.

Ce message ne sort pas de nulle part. La 2.1.251 avait changé, je cite, « la façon dont les fichiers de sortie des commandes Bash sont créés et relus quand la commande tourne dans le bac à sable, pour qu'une commande sandboxée ne puisse plus les rediriger ni les remplacer ». Le vocabulaire se recoupe mot pour mot : le swap qu'on refuse ici, c'est le remplacement qu'on venait d'interdire là-bas.

Le mécanisme sous-jacent est documenté dans la référence des outils : « Claude Code diffuse la sortie d'une commande vers un fichier de travail pendant qu'elle tourne ». Ce fichier est la pièce à protéger, puisqu'une commande hostile qui le remplace réécrit ce que Claude croit avoir observé. Le contrôle ajouté vérifie donc que le répertoire des tâches n'a été ni déplacé ni transformé en lien symbolique entre deux instants.

Reste la partie que le changelog ne justifie pas : pourquoi « certains Mac » et pas tous. Le changelog ne le dit pas et la doc non plus, donc prends la suite pour ce qu'elle est, une hypothèse et pas un fait établi : sur macOS, le répertoire temporaire par utilisateur vit sous /var/folders/..., et /var est lui-même un lien vers /private/var. Un contrôle qui refuse un répertoire « linked » sans résoudre d'abord le chemin canonique classe alors une installation parfaitement saine comme suspecte. Machines identiques en apparence, verdicts différents selon la façon dont TMPDIR a été résolu au démarrage.

C'est la forme la plus banale du bug de durcissement, et la moins évitable : on écrit un contrôle contre un attaquant, et le premier qu'il attrape est un utilisateur ordinaire. Au moins celui-ci se signalait franchement, avec sa cause entre parenthèses. Les trois suivants, non.

Le « toujours autoriser » qui ne s'enregistrait qu'à partir de la deuxième fois

Corrigé : « toujours autoriser » ne s'enregistrait pas dans un projet qui n'a pas encore de fichier .claude/settings.local.json.

Lis bien la condition : pas encore de fichier. Le bug ne frappait donc que le tout premier « oui, et ne redemande plus » d'un projet, c'est-à-dire exactement l'action censée créer ce fichier. Tu approuves, rien ne proteste, et à la commande suivante Claude te repose la question. Aucune erreur, aucun avertissement. La lecture naturelle, c'est que tu as mal cliqué.

La doc des réglages explique pourquoi cette première écriture est un chemin de code à part, et pas un simple write() : Claude Code crée .claude/settings.local.json « la première fois que tu donnes une approbation permanente sur une invite de permission », et cette même première fois, il ajoute **/.claude/settings.local.json à ton fichier d'exclusions git global pour que le fichier ne parte jamais dans un commit. Ce fichier d'exclusions est core.excludesFile si ta config git globale le pointe en chemin absolu ou en ~/, sinon $XDG_CONFIG_HOME/git/ignore, sinon ~/.config/git/ignore. Créer le fichier, c'est donc aussi toucher à la config git de la machine. Beaucoup plus de choses à rater qu'à la deuxième écriture.

Conséquence concrète si tu as pesté ces derniers jours : va rouvrir les .claude/settings.local.json de tes projets récents. Les règles allow que tu croyais avoir posées n'y sont peut-être jamais arrivées.

La connexion malade n'est pas une connexion coupée

Corrigé : les sessions Remote Control hébergées par Claude Desktop ou VS Code se figeaient pendant plusieurs minutes après la fin d'un outil quand la connexion à claude.ai était dégradée.

La doc de Remote Control promet le contraire, et elle est explicite : « si ton portable se met en veille ou que ton réseau tombe, Claude Code se reconnecte automatiquement quand ta machine revient en ligne. Pendant que la connexion se reconstruit, Claude Code met en file d'attente les messages, les demandes de permission et les mises à jour de statut, et les délivre une fois la connexion rétablie ».

Cette garantie couvre la coupure. Elle ne couvrait pas la connexion à moitié vivante, celle qui ne se déclare jamais morte et n'ouvre donc jamais la file d'attente. Le symptôme est traître : l'outil a fini côté machine, mais le résultat n'arrive pas sur ton téléphone. Rien n'indique une panne réseau, l'indicateur reste vert. Tu conclus que Claude est lent, ou que ta requête était trop lourde. Plusieurs minutes de blocage lues comme de la latence normale.

C'est aussi le seul des quatre correctifs à cibler des hôtes précis, Claude Desktop et l'extension VS Code, pas la session en terminal.

32 Mo, et l'erreur qui accusait le mauvais coupable

Corrigé : les notifications de tâche d'arrière-plan avec une très grosse sortie d'échec (par exemple des erreurs git sur un disque plein) faisaient dépasser à la conversation la limite de taille des requêtes API.

Deux plafonds cohabitent ici, et l'écart entre les deux est tout le bug. Côté local, la référence des outils est généreuse : « une commande dont la sortie dépasse 5 Go est tuée ». Côté API, la page des erreurs fixe la barre bien plus bas, et la nomme : Request too large for the API's 32MB request limit.

Une tâche d'arrière-plan qui échoue notifie la conversation, en y recopiant sa sortie d'échec. Tant que cette sortie tient dans un écran, personne ne se pose de question. Un git qui part en boucle d'erreurs sur un disque plein, lui, produit des dizaines de mégaoctets en quelques secondes : bien en dessous du plafond local de 5 Go, largement au-dessus des 32 Mo de la requête. La conversation devient alors intransmissible.

Le piège est dans le remède affiché. Face à Request too large, la doc conseille de réduire le nombre de fichiers, de lancer /compact, de retirer des pièces jointes. Tous ces conseils visent ce que tu as mis dans la conversation. Ici, le bloc fautif était une notification automatique que tu n'avais pas demandée, et /compact ne l'atteignait pas puisqu'il siège dans le tour le plus récent. Tu pouvais élaguer ton contexte pendant une heure sans rien débloquer.

Ce qu'il faut en retenir

Mets-toi à jour, c'est une version sans risque : quatre correctifs, aucun changement de comportement à réapprendre, aucune nouveauté à intégrer.

Le seul geste actif à prévoir concerne le deuxième point. Si tu as ouvert un projet neuf avec Claude Code cette semaine et accordé une approbation permanente, vérifie que ton .claude/settings.local.json existe et contient bien la règle. Sinon, redonne-la, elle tiendra cette fois.

Et garde en tête le motif général, parce qu'il resservira au prochain gros durcissement. Trois de ces quatre bugs se déguisaient en autre chose : une maladresse de l'utilisateur, une lenteur du réseau, une conversation trop chargée. Quand un comportement bizarre apparaît juste après une version dense en correctifs de sécurité, la piste à explorer en premier n'est pas ta configuration, c'est le changelog des trois derniers jours.