OpenClaw 2026.10.5 : mets à jour sans perdre le fil

19 octobre 2026

☕ Ce matin, parlons d’un sujet moins glamour qu’un nouveau modèle — et beaucoup plus important le jour où ton agent travaille vraiment : pouvoir mettre à jour sans transformer ton Gateway en expérience de spéléologie.

OpenClaw 2026.10.5 est sorti le 18 octobre. Son changement le plus utile n’est pas une fonction à cocher : la release travaille la fiabilité des mises à jour, des redémarrages et des sessions interrompues. Autrement dit, elle vise le moment où une automatisation cesse d’être une démo et commence à compter.

Le vrai problème : une mise à jour est un workflow, pas une commande

Sur une machine personnelle, openclaw update paraît simple. En pratique, l’opération traverse un système de fichiers, un gestionnaire de paquets, un Gateway déjà occupé et parfois un redémarrage. C’est précisément dans ces transitions qu’apparaissent les états pénibles : paquet remplacé mais non activé, lease de transfert oubliée, Gateway bloqué, ou résultat affiché comme un échec alors que l’installation a bien changé.

La note de version de 2026.10.5 annonce des corrections sur ces chemins : mises à jour qui se terminent ou se récupèrent d’elles-mêmes, gestion des fichiersystems et de pnpm 12, élévation Windows, shells de connexion macOS, et nettoyage des journaux d’activation ou leases de handoff devenus obsolètes. Le cas --no-restart reçoit aussi un résultat plus honnête.

La conséquence pratique est simple : ne juge plus une mise à jour seulement à la dernière ligne du terminal. Après une opération sensible, vérifie la version installée et la santé du Gateway. Si tu pilotes des crons ou des canaux, fais-le sur un créneau calme et garde une fenêtre d’observation. La meilleure mise à jour est celle dont tu n’as pas besoin de raconter le sauvetage.

Un redémarrage ne devrait pas effacer le travail en cours

La seconde partie de la release est tout aussi concrète. OpenClaw indique que des tours interrompus, des premiers messages pendant la préparation d’un worktree, du travail de subagents et des tâches différées peuvent reprendre après un redémarrage du Gateway. La release cite aussi la préservation de l’entrée utilisateur et des données de session validées face aux redémarrages, écritures concurrentes et publications échouées.

Ce n’est pas une promesse que chaque appel externe devient magique. Une API distante peut toujours expirer, une écriture non idempotente peut toujours demander un contrôle humain. Mais la frontière s’améliore : OpenClaw tente de restaurer son état et de rendre visible une fin incomplète, au lieu de faire comme si rien ne s’était passé.

Pour les workflows multi-agents, c’est un changement de nature. Un subagent qui rend son résultat après un redémarrage évite de relancer aveuglément une tâche coûteuse. Un message conservé évite de reconstruire le contexte à la main. Et une reprise explicite donne une base pour concevoir des actions réellement sûres à rejouer.

La checklist utile avant de passer en 2026.10.5

• Lis ton mode d’installation. npm, pnpm, Bun, service géré ou machine distante n’exposent pas les mêmes points de friction. La release cible beaucoup de cas, pas une configuration abstraite.
• Évite de mettre à jour au milieu d’une action irréversible. Publication, paiement, suppression ou envoi externe : attends que la tâche soit terminée ou assure-toi qu’elle possède une clé d’idempotence.
• Contrôle le redémarrage. Après l’update, vérifie que le Gateway répond, qu’un canal peut recevoir un message et que tes automatisations critiques sont visibles.
• Teste une reprise sur un workflow sans enjeu. Lance une tâche longue, redémarre de façon contrôlée, puis observe le statut et le résultat. C’est bien plus instructif que lire cent lignes de changelog.
• Regarde la politique de plugins. La release durcit les hooks d’approbation : un hook ne peut plus modifier silencieusement des arguments déjà approuvés en trusted-inline. Si tu maintiens un plugin de transformation, une approbation séparée peut être nécessaire.

Ce qui compte aussi, mais après la fiabilité

2026.10.5 apporte également le canal X avec limites de coût, des appels vocaux enrichis, un choix de modèles plus dynamique, la recherche ClawHub depuis le Gateway et des améliorations de performance sur les lectures de sessions, transcripts et métadonnées. Ce sont de bonnes nouvelles. Mais pour une installation qui héberge des agents, la valeur la plus durable reste ailleurs : moins de travail perdu quand l’infrastructure tousse.

Cette priorité prolonge d’ailleurs l’idée derrière notre lecture de 2026.10.4 sur un Gateway qui survit au sommeil. La différence est nette : 2026.10.4 traitait une panne de disponibilité très concrète ; 2026.10.5 élargit le filet de sécurité aux transitions d’update et de reprise.

Verdict LaPince

Utile pour : les personnes qui font tourner des crons, des canaux ou des subagents et qui ont déjà eu peur de relancer une tâche sans savoir ce qui avait été commis.

La limite : la résilience interne ne remplace ni les sauvegardes, ni des intégrations idempotentes, ni un test après mise à jour. C’est une ceinture de sécurité, pas un permis de conduire les yeux fermés.

Prochaine action : planifie la mise à jour, vérifie ton Gateway ensuite, puis teste une reprise contrôlée sur une automatisation sans effet externe. Si elle repart proprement, tu viens de gagner plus qu’une ligne de version.

Sources primaires

• OpenClaw 2026.10.5 — GitHub Release, publiée le 18 octobre 2026.
• Paquet npm openclaw 2026.10.5, vérifié le 19 octobre 2026.
• Contribution record 2026.10.5, référencé par la release.