OpenClaw v2026.5.6 et v2026.5.7 : Fix Codex OAuth, Doctor et Stabilité Plugins

OpenClaw enchaîne deux releases correctives en mai 2026

En l'espace de quelques jours, OpenClaw a publié les versions 2026.5.6 puis 2026.5.7, deux correctifs ciblés qui font suite à la grosse release 2026.5.5 publiée la semaine précédente. Ces deux versions partagent un point commun : elles colmatent des régressions introduites par le mécanisme de réparation automatique du Gateway, en particulier autour de l'authentification OAuth pour les utilisateurs Codex et GPT-5.5. Pour les opérateurs en production qui utilisent un compte Codex pour faire tourner GPT-5.5 via OpenClaw, ces correctifs ne sont pas optionnels : ils restaurent un comportement attendu et empêchent un sabotage silencieux de la configuration.

Au-delà du fix Codex, ces deux versions apportent un durcissement notable du système de plugins, une amélioration de la fiabilité de l'outil web fetch, ainsi que plusieurs ajustements sur les channels et le provider Telegram. Dans cet article, nous analysons en détail ce que contiennent ces deux correctifs, qui doit absolument mettre à jour, et pourquoi cette série de releases révèle une attention particulière d'OpenClaw aux setups OAuth en entreprise.

Sommaire

• Le contexte : pourquoi deux releases en cinq jours
• Le bug introduit par 2026.5.5
• Ce que corrige 2026.5.6
• Ce que corrige 2026.5.7
• Améliorations fetch et plugins
• Channels et provider Telegram
• Qui doit mettre à jour absolument
• Comment mettre à jour en sécurité
• Conclusion : OpenClaw mature son cycle de releases

Le contexte : pourquoi deux releases en cinq jours

OpenClaw a adopté un rythme de releases hebdomadaire depuis le début de l'année 2026. La version 2026.5.5, publiée début mai, contenait plus de 50 corrections et améliorations, dont certaines touchaient le comportement de la commande doctor --fix. Cet outil de diagnostic et de réparation automatique permet aux administrateurs de relancer un Gateway défaillant sans intervention manuelle. Mais comme tout outil de réparation automatique, il peut faire trop bien son travail.

C'est exactement ce qui s'est produit avec 2026.5.5. Une logique de "normalisation" des routes provider a été introduite, partant du principe que toutes les routes openai-codex/ étaient en réalité des erreurs et devaient pointer vers openai/. Pour la majorité des utilisateurs, cette logique ne posait aucun problème. Mais pour ceux qui utilisaient un compte ChatGPT Pro ou Codex avec authentification OAuth pour accéder à GPT-5.5, la "réparation" cassait silencieusement leur configuration.

Le problème a été remonté très rapidement par la communauté, ce qui a déclenché la publication de 2026.5.6 quelques jours plus tard, puis 2026.5.7 pour finaliser le correctif.

Le bug introduit par 2026.5.5

Pour comprendre l'ampleur du bug, il faut comprendre comment OpenClaw gère les multiples sources d'authentification possibles pour un même modèle.

Le cas Codex / GPT-5.5

Depuis le lancement de GPT-5.5 par OpenAI fin 2025, deux chemins d'authentification sont possibles. Le premier passe par une clé API OpenAI standard, configurée comme provider openai/gpt-5.5. Le second passe par un compte ChatGPT Pro ou Codex via OAuth, configuré comme provider openai-codex/gpt-5.5. Cette distinction est importante car les quotas, les limites de débit et les modèles disponibles diffèrent entre les deux modes.

Pour les opérateurs qui paient un abonnement ChatGPT Pro et veulent l'utiliser avec OpenClaw plutôt que de payer en plus une clé API à la consommation, la route openai-codex/* est essentielle. Sans elle, ils sont obligés de basculer en facturation API et perdent l'avantage économique de leur abonnement.

La régression silencieuse

Avec 2026.5.5, la commande doctor --fix détectait les routes openai-codex/ comme "incorrectes" et les réécrivait en openai/. À la prochaine requête, l'authentification OAuth Codex échouait, et OpenClaw essayait sans succès d'utiliser une clé API qui n'existait pas. L'agent retournait alors une erreur d'authentification, et l'utilisateur ne comprenait pas pourquoi son setup, qui fonctionnait depuis des semaines, ne marchait plus subitement.

Le caractère silencieux du problème en faisait sa dangerosité. Aucun message clair n'avertissait que la configuration avait été modifiée. Seule une lecture attentive des fichiers de configuration permettait de comprendre la source du problème.

Ce que corrige 2026.5.6

La version 2026.5.6, publiée quelques jours après la 5.5, corrige le comportement de doctor --fix pour qu'il ne réécrive plus les routes openai-codex/* valides. C'est le correctif principal, attendu par toute la communauté Codex.

Mais 2026.5.6 ne s'arrête pas là. Plusieurs améliorations de fiabilité ont été apportées au système de plugins et au gestionnaire de fetch web :

• Nettoyage des headers tiers : OpenClaw filtre désormais les métadonnées de symboles non standard injectées par certains plugins avant de transmettre les headers au système natif fetch / Headers. Cela évite des comportements étranges sur certains environnements Node.js récents.
• Normalisation des headers debug-proxy : les headers de replay utilisés par le debug proxy sont normalisés pour éviter des collisions de cas (header Content-Type vs content-type).
• Cleanup borné après web-fetch timeout : quand un fetch web dépasse son timeout, le cleanup du dispatcher gardé est désormais borné dans le temps. Cela évite que des connexions réseau bloquées occupent indéfiniment des "lanes" du Gateway, ce qui pouvait conduire à des saturations difficiles à diagnostiquer.

Ces améliorations sont silencieuses mais cumulativement importantes pour les déploiements en production avec un trafic significatif.

Ce que corrige 2026.5.7

La version 2026.5.7, publiée juste après 2026.5.6, finalise le correctif Codex et apporte plusieurs autres améliorations.

Récupération automatique des routes cassées par 2026.5.5

Le point clé de 2026.5.7 est la capacité de récupération automatique. Si vous avez fait tourner doctor --fix sous 2026.5.5 et que votre configuration Codex a été corrompue, 2026.5.7 détecte cette situation et restaure automatiquement les routes openai-codex/* quand seule l'authentification OAuth Codex est disponible.

Concrètement, lors du démarrage du Gateway, 2026.5.7 vérifie si une configuration OAuth Codex valide existe et si la route openai/ actuellement configurée pourrait correspondre à une route openai-codex/ originale. Si c'est le cas, la route est restaurée et l'utilisateur reçoit une notification claire dans les logs.

Améliorations annexes

Au-delà du fix Codex, 2026.5.7 inclut plusieurs autres améliorations :

• Améliorations sur la gestion des channels (canaux de communication entre agents)
• Renforcement du système de permissions (granularité plus fine sur certains scopes)
• Corrections diverses sur les model providers
• Améliorations sur l'intégration Telegram (gestion des commandes inline et des callbacks)

Pour comprendre l'écosystème de providers et son rôle dans OpenClaw, consultez notre guide complet OpenClaw qui couvre l'architecture du Gateway et la gestion des providers.

Améliorations fetch et plugins

Le système de plugins d'OpenClaw repose sur le protocole MCP (Model Context Protocol), que nous avons analysé en détail dans notre guide MCP. Les améliorations apportées par 2026.5.6 et 2026.5.7 renforcent la fiabilité de ce système crucial.

Pourquoi le fetch web est critique

L'outil fetch web est l'un des outils les plus utilisés par les agents OpenClaw. Il permet à un agent d'aller chercher du contenu sur internet pour répondre à une question, vérifier une information, ou enrichir sa réponse. Mais le fetch web est aussi l'un des outils les plus risqués en termes de stabilité : un site lent ou inaccessible peut bloquer un agent indéfiniment.

Avant les correctifs de 2026.5.6, certains timeouts mal gérés pouvaient conduire à une accumulation de requêtes "fantômes" qui consommaient des ressources sans jamais retourner. Sur un Gateway servant beaucoup de requêtes, cette accumulation pouvait conduire à une saturation et à des refus de service.

Le cleanup borné

La solution apportée par 2026.5.6 est élégante. Quand un fetch dépasse son timeout, OpenClaw lance un cleanup en arrière-plan, mais ce cleanup a lui-même un délai maximum. Si après ce délai, la connexion sous-jacente n'a pas pu être proprement fermée, OpenClaw force la libération de la lane Gateway et retourne une erreur d'outil claire à l'agent.

Cette approche garantit qu'aucune requête fetch ne peut bloquer indéfiniment une lane, même face à un site distant qui se comporte mal. C'est exactement le type de robustesse opérationnelle attendue pour un déploiement en production sérieux.

Channels et provider Telegram

Les channels OpenClaw permettent d'orchestrer des conversations entre plusieurs agents. C'est un mécanisme proche des "rooms" Slack ou des canaux Discord, mais conçu pour des agents IA. Notre analyse comparative entre Claude Code Channels et OpenClaw Agents explore en profondeur ce paradigme.

Améliorations de robustesse des channels

2026.5.7 apporte plusieurs améliorations sur la gestion des channels. La principale concerne la propagation des erreurs entre agents. Quand un agent participant à un channel échoue, l'erreur est désormais correctement propagée aux autres agents du channel, qui peuvent réagir en conséquence (relancer une tâche, alerter un humain, basculer sur un agent de secours).

Provider Telegram

Le provider Telegram d'OpenClaw a également reçu plusieurs corrections. La gestion des callbacks inline (quand un utilisateur clique sur un bouton dans un message Telegram) est désormais plus fiable. Les commandes slash (/start, /help, etc.) sont mieux parsées dans les contextes de groupe vs conversations privées.

Pour les utilisateurs qui ont déployé OpenClaw avec une intégration Telegram comme front-end, ces améliorations valent le coup de mettre à jour. Notre guide OpenClaw WhatsApp Business reste valable pour les analogies sur la gestion des intégrations messageries.

Qui doit mettre à jour absolument

La question pratique pour les opérateurs : faut-il mettre à jour immédiatement, attendre, ou même downgrader si on a déjà installé 2026.5.5 ?

Cas 1 : utilisateurs Codex / GPT-5.5 avec OAuth

Impératif : passer à 2026.5.7 immédiatement. Si vous utilisez un compte ChatGPT Pro ou Codex via OAuth pour faire tourner GPT-5.5, vous risquez à tout moment de voir votre configuration cassée si doctor --fix se déclenche automatiquement (ce qui peut arriver lors d'une mise à jour ou d'un redémarrage).

Cas 2 : utilisateurs en production avec trafic important

Recommandé : passer à 2026.5.7. Les améliorations sur le fetch web et le cleanup borné apportent une robustesse opérationnelle utile pour tout déploiement servant un trafic non trivial.

Cas 3 : utilisateurs en développement ou expérimentation

Optionnel mais conseillé. Si vous êtes encore en phase d'évaluation d'OpenClaw, vous pouvez attendre la prochaine release majeure. Mais comme les correctifs sont mineurs et bien isolés, mettre à jour ne présente pas de risque particulier.

Cas 4 : déploiements stables avec peu de variations

Si vous tournez sur 2026.5.4 ou antérieur sans utiliser OAuth Codex et sans subir de problèmes, vous pouvez attendre la prochaine version stable. Pas d'urgence absolue.

Comment mettre à jour en sécurité

Quelques bonnes pratiques pour effectuer la mise à jour vers 2026.5.7 sans perturber un déploiement en production.

Sauvegarde préalable de la configuration

Avant toute mise à jour, copiez votre fichier de configuration OpenClaw et votre dossier de credentials. En cas de problème, vous pourrez restaurer rapidement l'état antérieur.

cp ~/.openclaw/config.yaml ~/.openclaw/config.yaml.backup-$(date +%Y%m%d)
cp -r ~/.openclaw/credentials ~/.openclaw/credentials.backup-$(date +%Y%m%d)

Mise à jour via la commande standard

OpenClaw propose une commande de mise à jour intégrée qui gère proprement les redémarrages :

openclaw update --version 2026.5.7

Sur macOS, cette commande gère désormais correctement les LaunchAgents grâce au correctif introduit dans 2026.5.3. Sur Linux, le service systemd est redémarré automatiquement.

Vérification post-update

Après la mise à jour, vérifiez le bon fonctionnement avec quelques commandes simples :

openclaw version
openclaw doctor
openclaw test --provider openai-codex

Le doctor ne doit plus signaler de problème sur les routes Codex, et le test du provider doit retourner une réponse valide.

Procédure de rollback

Si vous rencontrez un problème inattendu après la mise à jour, le rollback est possible via :

openclaw update --version 2026.5.4

Cette version est généralement considérée comme stable et précédait la régression introduite par 2026.5.5. Pour aller plus loin sur le déploiement et la maintenance d'OpenClaw en environnement professionnel, consultez notre guide de déploiement entreprise.

Conclusion : OpenClaw mature son cycle de releases

La séquence 2026.5.5 → 2026.5.6 → 2026.5.7 illustre à la fois les forces et les défis du modèle de développement rapide d'OpenClaw. La force, c'est la capacité de l'équipe à publier une régression critique, la corriger en quelques jours et finaliser le correctif dans la foulée. Le défi, c'est qu'une release contenant 50+ corrections augmente mécaniquement le risque de régressions inattendues.

Pour les utilisateurs en production, deux enseignements pratiques. Premièrement, ne jamais mettre à jour aveuglément vers la dernière version la nuit du déploiement. Attendez 48 à 72 heures pour laisser la communauté détecter les éventuels problèmes. Deuxièmement, l'écosystème OpenClaw mérite un monitoring actif des releases : un canal interne dédié, une revue hebdomadaire des changelogs, et une procédure de mise à jour standardisée.

Pour aller plus loin sur les choix d'architecture et les bonnes pratiques d'opération d'OpenClaw, notre guide architecture multi-agents et notre guide sécurité OpenClaw constituent des références essentielles. Et si vous démarrez avec OpenClaw, notre tutoriel d'installation Docker reste le point d'entrée recommandé pour un premier déploiement maîtrisé.