3.28 a doté le homard d'une armure neuve. Carapace renforcée, pinces affûtées, prêt au combat.
Et puis la réalité s'est rappelée à lui.
L'équipe sécurité IA de Cisco a disséqué un skill communautaire populaire et découvert qu'il s'agissait, en substance, d'un malware — il exfiltrait silencieusement des données vers des serveurs contrôlés par des attaquants et contournait les garde-fous de sécurité par injection de prompts. Des chercheurs ont scanné 31 000 skills : 26 % contenaient au moins une vulnérabilité. La campagne ClawHavoc a implanté plus de 800 skills malveillants dans ClawHub. Le homard avait une nouvelle carapace, mais l'océan était devenu plus hostile.
Trois versions en trois jours. 3.31, 4.1, 4.2. Ce n'est pas un sprint de fonctionnalités — c'est un siège. Changements cassants, verrouillages sécuritaires et réécriture d'infrastructure, le tout visant un seul objectif : rendre OpenClaw plus difficile à pirater, plus facile à contrôler, et plus transparent sur ce qu'il fait.
Le conseil habituel, en double dose : homards en production, lisez avant de mettre à jour.
Les installations de plugins ont désormais un videur
Le changement le plus susceptible de casser votre workflow est aussi le plus nécessaire.
Avant, on pouvait installer n'importe quel skill sans se poser de questions. Code dangereux, dépendances malveillantes, charges utiles d'injection de prompts — l'installation passait sans broncher, et on ne s'en rendait compte qu'une fois le mal fait.
C'est terminé. OpenClaw lance un scan de code dangereux intégré avant chaque installation de plugin. Si des problèmes critiques sont détectés, l'installation échoue immédiatement. La seule façon de passer outre : le flag explicite \--dangerously-force-unsafe-install\ — un nom choisi pour vous faire hésiter en le tapant.
Le contexte est clair : l'écosystème de skills avait un problème de confiance. Cisco a découvert qu'un skill communautaire populaire exfiltrait des données utilisateur via des commandes curl silencieuses. ClawHub abritait 2 857 skills au moment de l'analyse, dont 341 confirmés malveillants à travers plusieurs campagnes. Le chiffre est ensuite monté à plus de 824. Le verrou à l'installation arrive tard, mais il est indispensable.
Si vous maintenez des skills qui dépendent de paquets avec des vulnérabilités connues, ou si vous récupérez des dépendances de skills via la passerelle, attendez-vous à des échecs d'installation après la mise à jour. La solution : soit nettoyer l'arbre de dépendances, soit choisir consciemment l'installation forcée.
xAI et Firecrawl : les chemins de configuration ont déménagé
Si vous utilisez la recherche xAI ou Firecrawl pour le web fetching, vos chemins de configuration sont désormais invalides.
Recherche xAI : tout ce qui se trouvait sous \tools.web.x_search.<em class="italic text-slate-200">\ migre vers \plugins.entries.xai.config.xSearch.</em>\. L'authentification se standardise sur \plugins.entries.xai.config.webSearch.apiKey\ / \XAI_API_KEY\.
Firecrawl : l'ancien chemin \tools.web.fetch.firecrawl.<em class="italic text-slate-200">\ est supprimé. La nouvelle adresse : \plugins.entries.firecrawl.config.webFetch.</em>\. Le fallback web_fetch passe désormais par une frontière fetch-provider propre au lieu d'une branche core exclusive à Firecrawl.
Bonne nouvelle : un seul \openclaw doctor --fix\ effectue la migration automatiquement. Mais si des scripts, automatisations ou pipelines CI référencent directement les anciens chemins, il faudra les mettre à jour manuellement.
C'est un volet d'une évolution architecturale plus large : les réglages spécifiques aux fournisseurs quittent la configuration monolithique pour rejoindre des espaces de noms gérés par les plugins. Des frontières plus nettes, une propriété plus claire.
Les tâches de fond ont un cerveau
Le système de tâches de fond d'OpenClaw a été entièrement reconstruit.
Avant, les tâches ACP, les jobs cron et les tâches subagent avaient chacun leurs propres mécanismes de suivi — quand ils en avaient. Débugger une tâche bloquée relevait de la divination. Annuler une tâche relevait de la prière.
Désormais, tout passe par un registre unifié adossé à SQLite. ACP, subagent, cron et exécution CLI en arrière-plan alimentent un même système doté d'un suivi de cycle de vie, de pistes d'audit et d'une visibilité d'état.
Ce que ça change pour les utilisateurs :
- •\
/tasks\dans n'importe quelle session de chat affiche un tableau de bord en temps réel de toutes les tâches de fond de la session — statut, activité récente et compteurs de fallback d'un coup d'œil. - •Les tâches bloquées indiquent la raison. Fini les devinettes.
- •Annulation en douceur. Les tâches annulées attendent que le travail en cours se termine avant de s'arrêter réellement, pas de coupure brutale.
- •Récupération des exécutions perdues. Le système détecte les tâches orphelines et fournit des conseils de récupération via doctor.
- •Contrôle des flux. \
openclaw flows list|show|cancel\offre une surface de contrôle linéaire pour les workflows multi-tâches.
Pour ceux qui pilotent des automatisations complexes — agents chaînés, jobs planifiés, traitements en arrière-plan — le débogage de tâches passe du mystère au diagnostic.
Exécution de commandes : les verrous se resserrent
C'est la zone la plus dense en renforcement sécuritaire. Plusieurs modifications affectent directement la façon dont les commandes s'exécutent et qui peut les exécuter.
L'appairage de nœud ne vaut plus permission d'exécution. Avant, terminer l'appairage d'un appareil accordait automatiquement les droits d'exécution de commandes sur le nœud. Désormais, l'appairage doit être explicitement approuvé avant l'activation des commandes. Un vecteur d'escalade de privilèges via le flux d'appairage est fermé.
Les variables d'environnement sensibles sont purgées de l'environnement d'exécution shell. URL d'index de paquets Python (\PIP_INDEX_URL\), endpoints Docker, chemins de certificats TLS, chemins de compilateur — tout cela est désormais interdit de passage du scope de la requête vers l'environnement d'exécution. Une surface d'attaque de chaîne d'approvisionnement documentée est fermée : les attaquants pouvaient auparavant injecter des variables d'environnement pour rediriger les téléchargements de paquets vers des sources malveillantes.
\tools.exec.host=auto\ est désormais un pur flag de routage. Il ne signifie plus implicitement « utiliser le bac à sable si disponible ». Si aucun bac à sable n'existe et qu'on en demande un explicitement, ça échoue immédiatement au lieu de basculer silencieusement vers une exécution sans bac à sable. Plus de rétrogradation silencieuse.
Mises à jour par plateforme
Les agents peuvent désormais réagir aux messages avec un emoji — un ❤️ sur une photo, un 👍 sur une confirmation. Plus besoin de taper « Belle photo ! » à chaque fois.
Telegram
Les demandes d'approbation dans les groupes restent dans leur fil de discussion d'origine, au lieu de s'échapper vers le chat racine. Les contrôles de refroidissement d'erreurs (\errorPolicy\ et \errorCooldownMs\) empêchent les mêmes erreurs transitoires de noyer les notifications.
Matrix
Les réponses en streaming se mettent à jour en place dans un seul message, au lieu d'envoyer un nouveau message par chunk. Le contexte d'historique de messages est aussi disponible, pour que les agents comprennent la conversation qui les a déclenchés.
Slack
Les demandes d'approbation d'exécution de commandes peuvent désormais être complétées entièrement dans Slack — plus besoin de sauter vers l'interface web ou le terminal.
Android
L'intégration Google Assistant App Actions permet de déclencher OpenClaw directement depuis l'assistant vocal, en passant les prompts dans l'interface de chat.
macOS
Voice Wake permet d'activer le mode conversation par un mot de réveil. Mains libres.
LINE
Support des plugins bundlés avec envoi sortant d'images, vidéos et audio. La résolution du contrat runtime sur les installations npm globales est corrigée.
QQ Bot
Plugin de canal bundlé complet : configuration multi-comptes, commandes slash, rappels et support média riche sur le chat privé, les messages @groupe et les canaux de guilde.
Authentification de la passerelle : fini la confiance implicite
Hébergeurs en propre, c'est pour vous.
Le mode \trusted-proxy\ de la passerelle rejette désormais les configurations mixtes utilisant simultanément des tokens partagés. Le fallback de connexion directe locale ne laisse plus passer implicitement les appelants du même hôte — un token explicitement configuré est exigé.
Si votre installation reposait sur « même machine = confiance », elle cassera après la mise à jour. Ajoutez une configuration d'authentification explicite.
La limitation de débit de l'authentification partagée reste active pendant les tentatives de handshake WebSocket, et les en-têtes Origin non concordants sur les requêtes HTTP trusted-proxy sont rejetés.
---
3.28 a blindé le homard. 3.31 à 4.2 lui ont appris à se battre.
Les installations de plugins ont un videur. Les tâches de fond ont un cerveau. Les chemins de configuration ont des frontières nettes. Les environnements d'exécution ont été débarrassés de leur surface d'attaque. La passerelle exige des identifiants au lieu de supposer la bonne foi.
Trois versions. Trois jours. Le périmètre de sécurité s'est resserré, et tout ce qui s'y trouve est devenu plus difficile à briser.
Le homard a sorti ses pinces. N'approchez pas sans permission.
