Les builds récents d’OpenClaw resserrent les garde-fous de bind local et d’authentification du gateway. Quand gateway.bind quitte le loopback sans gateway.auth.token valide, le démarrage échoue tôt. Quand votre shell interactif résout un openclaw global plus récent mais que launchd pointe encore vers un ancien préfixe, vous voyez doctor propre alors que les sondes RPC échouent : split brain classique. Un troisième motif conserve seulement la clé dépréciée gateway.token, que le nouveau schéma ignore, et le tableau boucle sur des 401. Un quatrième place l’état sous une sync d’entreprise ou un home réseau, ce qui fait concourir les écritures d’upgrade avec le lecteur du démon. Un cinquième expose 18789 sur une interface publique avant que l’auth applicative soit complète, ce qui amplifie le bruit des scanners et pousse l’astreinte à poursuivre de faux timeouts modèle.

Les cinq points de contrôle ci-dessous imposent l’ordre : figer versions et fichiers avant de toucher températures ou clés API. Si l’onboarding premier boot n’est pas fini, terminez la check-list d’installation avant de revenir aux chemins propres à l’upgrade.

Traitez les upgrades comme un problème d’alignement entre binaires, métadonnées plist et fichiers de configuration ; choisissez ensuite tunnel contre stratégie de bind contrôlée.

Un piège subtil est l’héritage d’environnement : les jobs launchd n’importent pas automatiquement les exports de profil shell ajoutés pour commodité. Si vous avez généré un token en session interactive et ne l’avez echoé que dans un rc shell, le daemon ne le verra jamais. Le motif durable persiste les secrets là où le service lit déjà la configuration, ou utilise les hooks env-file documentés si votre packaging les supporte, puis redémarrez et relancez doctor pour confirmer la vue côté service. Inscrivez à côté du label plist le SHA ou semver attendu du CLI dans le ticket de change afin que le prochain upgrade n’élargisse pas silencieusement l’écart entre exécution humaine et exécution supervisée.

Quand plusieurs ingénieurs partagent un Mac cloud d’expérimentation, ajoutez une courte note de rotation au runbook : qui a lancé force en dernier, quel profil possède le gateway, et si des binds temporaires ont été annulés. Les hôtes partagés amplifient le split brain car chacun suppose son PATH universel. Une seule table autoritaire de binaires, labels plist et adresses d’écoute réduit les suppositions du vendredi soir.

Après rafraîchissement d’image dorée, vérifiez explicitement que la version Node globale correspond encore aux chemins codés dans vos LaunchAgents personnalisés. Les équipes plateforme oublient parfois de réécrire ces agents quand l’image de base change de préfixe npm, ce qui laisse un service silencieux sur un binaire fantôme. Comparez la sortie de openclaw --version lancée par launchd avec celle de votre shell avant tout changement de bind ou de token.

Reliez ces pratiques à l’article stabilité 24/7 : les heartbeats supposent que le même exécutable répond après reboot froid et après upgrade. Si un script de monitoring utilise un PATH différent de celui du plist, vous verrez des alertes contradictoires sans cause réseau ni cause modèle.

Sur Mac cloud la posture par défaut est loopback plus forward SSH local ou un Tailnet avec ACL serrées. Ce modèle de menace diffère de lier 18789 sur une interface publique. Mettez le tableau en page un du runbook pour que l’astreinte arrête de débattre des binds à la volée.

Le dépannage amont commence par openclaw status, openclaw gateway status, openclaw logs --follow et openclaw doctor. Sur images cloud notez aussi si Node et le préfixe global correspondent aux attentes plist après rafraîchissement d’image dorée.

Tailscale et les tunnels SSH ont un coût opérationnel différent. Tailscale donne des noms DNS et des ACL qui évitent de mémoriser des drapeaux SSH par hôte pour les petites équipes, mais ajoute une autre chaîne de dépendances à patcher et auditer. Le port forwarding SSH est ennuyeux, ce qui est un avantage quand la conformité veut une liste de pièces mobiles minimale. Certaines équipes combinent les deux : Tailscale pour l’atteignabilité, bind loopback sur le gateway, règles deny explicites pour que les binds LAN accidentels n’apparaissent pas pendant les upgrades. Documentez le mode dégradé quand le tunnel tombe : les agents doivent décroître proprement plutôt que marteler un socket mort.

La planification capacitaire compte toujours : upgrader OpenClaw ne supprime pas la pression mémoire des grosses chaînes d’outils. Si les logs montrent OOM à côté des redémarrages gateway, capturez cela séparément des échecs d’auth. Le playbook stockage et mémoire de ce site aide à décider quand la marge M4 Pro achète de la stabilité versus quand il suffit de métadonnées superviseur plus propres.

Pour les revues budgétaires, joignez au dossier un glossaire court : loopback signifie 127.0.0.1 sur l’hôte, LAN signifie une interface RFC1918, tunnel signifie que le navigateur ne parle jamais directement au nom public du Mac. Quand finance mélange ces termes, on achète du mauvais réseau pour de bonnes raisons applicatives. Gardez le tableau à côté du diagramme d’architecture et reliez la check-list premier boot pour éviter que des captures d’écran anciennes ne réintroduisent des binds publics.

En multi-région, chaque instance gateway devrait avoir son propre enregistrement de change pour mode de bind et commande de tunnel. Sinon une équipe migre avec succès vers loopback plus SSH pendant qu’une autre garde des binds LAN expérimentaux, et vous comparez des pommes et des poires dans les mêmes indicateurs. Consolidez les métriques par région et par mode, pas globalement mélangées.

Quand ~/.openclaw/openclaw.json contient déjà gateway.auth.token mais que les dashboards renvoient encore 401, l’étape suivante n’est pas de générer un dixième token. Vérifiez le répertoire de travail launchd et si OPENCLAW_STATE_DIR correspond à votre shell interactif. Certaines images cloud séparent les homes pour comptes d’automatisation versus comptes de login ; un plist visant le mauvais compte produit l’illusion que cat montre un token pendant que le service n’en voit aucun.

Si doctor signale une config plus récente touchée par un binaire plus ancien, corrigez d’abord PATH puis réinstallez les métadonnées superviseur depuis l’installation voulue. Évitez les boucles rapides config set pendant qu’un vieux binaire reste supervisé, sinon les gardes de version meta bloquent des mutations sans retour UI clair.

openclaw doctor
openclaw config get gateway.auth.token
openclaw gateway status --deep
openclaw gateway install --force
openclaw gateway restart

Pour les passations collez ces quatre sorties de commandes à côté de la section heartbeat dans l’article stabilité 24/7 afin que l’équipe de nuit ne dépende pas du folklore de chat sur les tweaks de port.

Si la CI cuit des images, ajoutez une fumée automatisée qui exécute doctor de façon non interactive après build et fait échouer le pipeline quand les alertes dépassent un seuil que vous définissez. Cela décale les régressions d’upgrade vers la gauche où elles coûtent moins. Conservez l’artefact de fumée à côté de la chaîne de version d’image pour comparer mardi et jeudi sans archéologie SSH.

Après chaque exécution de force, vérifiez explicitement qu’un seul LaunchAgent utilisateur actif possède le processus gateway et qu’aucun ProgramArguments orphelin ne pointe vers d’anciens chemins npm. Le statut deep montre souvent des doublons oubliés d’expériences passées qui retiennent des ports ou lisent de mauvais tokens. Désactivez ces doublons avant de redéployer sinon le split brain revient au prochain reboot.

Supposez que loopback fonctionne déjà sur le serveur ; sinon retournez à la check-list d’installation pour onboarding et démon. Ajoutez ensuite les chemins distants pour que les erreurs réseau ne se déguisent pas en échecs d’auth.

Dans l’étape six, documentez aussi quelles règles de pare-feu entre portable et Mac cloud sont autorisées et si des VPN split-tunnel peuvent couper SSH. Beaucoup de faux problèmes d’auth viennent de VPN d’entreprise qui bloquent les forwards locaux, pas de tokens erronés. Une phrase dans le runbook épargne des heures.

Comparé à emprunter le portable d’un collègue comme hôte gateway, ancrer OpenClaw sur un Mac cloud louable KVMNODE facilite la tenue des chemins binaires, labels plist, tokens et commandes de tunnel dans un seul enregistrement de change ; les portables perdent encore du temps à la veille et aux upgrades OS. Pour les équipes qui doivent documenter observabilité, rollback d’upgrade et renouvellements en revues hebdomadaires, le bare metal dédié multi-métro est en général plus simple à exécuter que du matériel dispersé : louer court dans la région choisie pour valider upgrades et tunnels, puis décider M4 Pro et durées longues via grille tarifaire et centre d’aide plutôt que demandes chat la nuit de release.

Lors des revues d’incident, classez explicitement les événements force selon les barrières A à C. Sans cette taxonomie, l’équipe croit que force est un remède universel, ce qui mène à des rotations de tokens pendant que le superviseur garde d’anciennes métadonnées, recréant de la dérive. La cohérence du langage dans les tickets est aussi importante que la cohérence de configuration.