• Partenaires

Utilisateurs qui regardent le poste (Total: 0, Members: 0, Invité: 0)

CrdaN

CrdaN

Administrateur
PREMIUM
Marchand
Level 5
Level 4
Level 3
Level 2
Level 1
29 Avr. 2012
5,336
437
999
Discord
crdan
Claude Code 2.1.162 : comprendre pourquoi un agent IA bloque avant de forcer

Anthropic a publié Claude Code 2.1.162 le 3 juin 2026. Ce n’est pas une mise à jour “waouh” avec une grosse feature marketing, mais elle est très intéressante pour ceux qui utilisent des agents IA au quotidien : meilleure visibilité sur les sessions bloquées, corrections de règles de permissions, meilleur comportement de WebFetch, fixes Windows et plusieurs améliorations autour des agents en arrière-plan.

Source officielle :

Pour Cheat-Gam3, le sujet est concret : quand on donne accès à un agent IA à un projet, un dépôt, un terminal ou un MCP, le vrai risque n’est pas seulement “l’IA se trompe”. Le vrai risque, c’est de ne pas comprendre pourquoi elle agit, pourquoi elle attend, et quelle permission elle demande.

Le changement à retenir : waitingFor dans claude agents --json​


La note la plus utile pour les workflows automatisés : `claude agents --json` inclut maintenant `waitingFor`. En clair, quand une session est en attente, on peut voir ce qui la bloque : par exemple une demande de permission.

C’est très pratique si vous lancez plusieurs agents sur un projet :

  • un agent qui prépare une PR ;
  • un agent qui vérifie des tests ;
  • un agent qui relit une config ;
  • un agent qui surveille un build ;
  • un agent qui travaille sur un bot Discord ou un outil forum.

Avant, une session “bloquée” pouvait juste ressembler à un agent silencieux. Maintenant, le statut peut être exploité plus proprement : est-ce qu’il attend une validation ? Est-ce qu’il est réellement planté ? Est-ce qu’il est juste en pause parce qu’une action sensible nécessite votre accord ?

Pourquoi c’est important pour la sécurité​


Un agent IA qui attend une permission n’est pas un bug. C’est souvent un garde-fou. Le mauvais réflexe serait de passer en mode “autorise tout” parce que ça va plus vite.

Sur un projet réel, surtout avec MCP, terminal et accès fichiers, il faut garder une différence entre :

  • actions lisibles : lire un fichier, inspecter un log, chercher une erreur ;
  • actions modifiantes : éditer un fichier, installer une dépendance, changer une config ;
  • actions sensibles : pousser sur Git, appeler une API, toucher à des secrets, supprimer des fichiers ;
  • actions externes : envoyer un message, publier, déployer, déclencher un workflow public.

La valeur de `waitingFor`, c’est de rendre ces blocages plus visibles. Un agent en attente d’une permission doit déclencher une vraie mini-review, pas un clic automatique.

Pour voir le contenu, vous devez réagir aux messages avec l'une de ces réactions :

Réagir Réagir, Love Love, Haha Haha, Oula Oula, Triste Triste, Colère Colère

WebFetch et permissions : un fix à ne pas sous-estimer​


La version 2.1.162 corrige aussi un point important : les règles de permission WebFetch s’appliquent mieux aux domaines préapprouvés. D’après le changelog, les règles explicites `WebFetch(domain:...)` en deny/ask/allow prennent maintenant priorité sur l’auto-allow de certains hôtes.

Pourquoi ça compte ? Parce que les agents IA ne travaillent plus seulement avec vos fichiers locaux. Ils lisent des docs, changelogs, issues GitHub, pages de fournisseurs, et parfois du contenu externe non fiable. Une page web peut contenir du texte piégé, des instructions trompeuses ou simplement des informations fausses.

La bonne pratique :

  • autoriser les domaines nécessaires, pas tout le web ;
  • mettre en “ask” les sources inhabituelles ;
  • refuser les domaines qui n’ont rien à faire dans le projet ;
  • ne jamais laisser une page externe dicter des actions terminal ou secrets ;
  • séparer lecture documentaire et action système.

Même si WebFetch est utile, une source externe doit rester une source externe. Elle informe l’agent, elle ne le commande pas.

Windows : permissions de chemins mieux gérées​


La mise à jour corrige aussi des règles de permissions Windows qui ne matchaient pas correctement avec des chemins contenant des backslashes (`~\`, `\\server\share`) ou des variations de casse. Elle corrige également le cas où des règles Read deny ne masquaient pas bien certains fichiers dans Glob/Grep.

C’est typiquement le genre de détail qui semble petit… jusqu’au jour où un agent voit un fichier qu’il ne devait pas voir.

Pour les utilisateurs Windows, surtout ceux qui bossent avec des dossiers partagés, NAS, projets synchronisés ou dépôts multi-outils, ça rappelle une règle simple : les permissions doivent être testées, pas supposées.

Agents en arrière-plan : moins de pertes silencieuses​


Le changelog mentionne plusieurs corrections autour des sessions background : attache plus fiable, statuts moins tronqués, réponses qui ne se perdent plus si l’envoi échoue, meilleure gestion des démarrages de service, messages plus clairs.

C’est utile pour les workflows longs : refactor, audit, génération de docs, correction de tests, préparation de release. Quand un agent tourne en arrière-plan, on a besoin de trois choses :

  • savoir ce qu’il fait ;
  • savoir ce qu’il attend ;
  • pouvoir reprendre sans perdre le contexte.

Sans ça, on finit par relancer plusieurs fois la même tâche, créer des modifications concurrentes, ou approuver trop vite parce qu’on ne sait plus où on en est.

Pour voir le contenu, vous devez réagir aux messages avec l'une de ces réactions :

Réagir Réagir, Love Love, Haha Haha, Oula Oula, Triste Triste, Colère Colère

Workflow conseillé pour Cheat-Gam3​


Si vous utilisez Claude Code, Cursor, Codex ou d’autres agents IA sur des projets communautaires, voici un workflow simple :

  1. Créer une branche dédiée avant de laisser un agent modifier du code.
  2. Limiter les outils au strict nécessaire : lecture, recherche, tests, puis écriture si besoin.
  3. Demander un plan court avant les modifications.
  4. Surveiller les permissions au lieu de les autoriser en masse.
  5. Forcer un résumé avant approbation si l’agent est bloqué.
  6. Relire le diff avant commit, surtout sur configs, scripts, `.env.example`, CI et dépendances.
  7. Tester petit : une commande de vérification claire vaut mieux qu’un “ça devrait marcher”.

Conclusion​


Claude Code 2.1.162 n’est pas la mise à jour la plus flashy, mais elle améliore un point essentiel : la lisibilité du contrôle humain. Voir pourquoi un agent attend, mieux appliquer les règles WebFetch, corriger les permissions Windows et rendre les sessions background plus fiables, c’est exactement ce qui rend les agents IA moins chaotiques.

Mon avis : si vous utilisez Claude Code avec MCP, terminal ou agents en arrière-plan, cette mise à jour mérite d’être installée rapidement. Pas pour aller plus vite à tout prix, mais pour éviter le pire réflexe avec les agents IA : approuver sans comprendre.