2026 OpenClaw dépannage côté canal : @mention en groupe, validations pairing et checklist des droits bot Slack/Discord (connecté mais sans réponse)

1. Trois familles de symptômes

Les journaux disent « traité », l'utilisateur ne voit rien : pensez politique de canal. Séparez « la plateforme a-t-elle remis au bot ? » et « la passerelle au modèle ? ».

1. @mention / requireMention : sans @Bot, la politique jette le message ; les MP échappent souvent à la règle. Bacs à sable, listes blanches, documentation. Si le comportement varie par salon, cherchez des surcharges par salle.
2. Pairing : sans pairing approve, pas de route vers le modèle. Lisez durcissement pour distinguer politique et auth.
3. Slack / Discord : chat:write manquant, bot non invité, Discord sans Message Content Intent. Webhook ≠ Socket. Multi-workspace Slack : bonne installation, URL d'événements = passerelle prod. Un tableau de bord « vert » ne garantit pas que chaque workspace envoie des payloads : croisez l'horodatage des livraisons Slack avec les journaux d'accès de la passerelle.

Changer de modèle ou réinstaller les paquets avant d'avoir vu un événement brut en entrée, c'est souvent inutile : si la plateforme n'a jamais remis le message au bot, ce n'est pas un problème de prompt.

Deux runbooks : canal (probe, pairing, mention, scopes OAuth, URL de rappel, périmètre d'installation) et session/modèle (models status, thinking, heartbeat, cron). Si Matrix fonctionne et pas l'IM, l'IM passe en premier. Une seule modification par fenêtre de maintenance, avec messages [OC-PROBE] avant/après.

Après fusion de fragments de configuration ou upgrade majeur, les valeurs par défaut de pairing reviennent souvent : ajoutez « vérifier pairing list » à la checklist de publication, comme pour les migrations SecretRef.

2. Tableau comparatif

Si le port 18789 était vraiment bloqué, les MP tomberaient aussi. La température ne fait pas disparaître les événements Discord—investir dans les intents et les ACL de salon rapporte davantage.

3. Six étapes

De l'extérieur vers l'intérieur ; une étape, une hypothèse—sinon le post-mortem n'est pas reproductible.

1. Probe : openclaw channels status --probe ; noter latence et échecs. Intermittence : timeout du reverse proxy, chaîne TLS, ou health check qui ne couvre pas le chemin webhook réel.
2. Pairing : openclaw pairing list --channel … ; les invitations massives peuvent saturer la file pending en une nuit.
3. Mention : basculer requireMention sur un bac à sable ; comparer avec et sans @. Tester avec un compte utilisateur final, pas seulement administrateur.
4. Doctor : openclaw doctor ; avec Docker, même somme de contrôle de config hôte/conteneur.
5. Logs : openclaw logs --follow pendant l'envoi d'un [OC-PROBE] ; filtrer policy, mention, pairing.
6. Persistance : sous launchd, WorkingDirectory et le openclaw.json lu doivent correspondre à la session SSH—sinon « OK à la main, vieux comportement en daemon », comme pour PATH sous launchd.

4. Paramètres et repères d'exploitation

① Discord : Message Content Intent est en pratique indispensable si le bot lit le texte des salons ; Server Members Intent seulement si vous en avez besoin fonctionnellement. ② Slack : scopes minimalistes selon Event API ou Socket Mode ; sans /invite du bot, certains événements n'existent pas.

③ HTTPS et chemins : l'URL publique, l'upstream interne et basePath doivent s'aligner—terminaison TLS qui perd les préfixes d'URL est un classique. ④ Cache : après réauth ou changement d'intents, attendre plusieurs minutes avant de conclure. ⑤ Documentation utilisateur : « merci de @ le bot dans les salons publics » réduit les tickets mieux que des bascules de config répétées.

⑥ Audit : chaque vague d'approbations pairing avec numéro de ticket et opérateur, comme les rotations de secrets (durcissement). Repère grossier : si le délai message utilisateur → première ligne de log passerelle reste typiquement sous 2–3 s en charge normale, la latence LLM n'est pas le premier suspect—regardez files et politiques canal.

5. Mac cloud VPSMAC

Faire tourner les tokens à chaque silence masque les vrais problèmes de mention/pairing et casse l'audit. Fixer l'ordre probe → pairing → doctor → logs dans un runbook vaut mieux qu'empiler des secrets.

Les portables en sommeil et les réseaux domestiques déforment les reconnexions IM ; un nœud toujours alimenté donne des traces stables. Coupler la passerelle à launchd sur VPSMAC M4 rapproche la production sans couche de compatibilité Windows/Linux supplémentaire pour l'outillage Apple.

Échafaudage rapide : guide 5 minutes, puis cette checklist côté messagerie.

6. FAQ

MP oui, groupes non ?

requireMention et politique de salon, puis message court avec et sans @Bot. Si la mention répare instantanément, documentez la règle ou exemptez les salons internes après revue sécurité.

Pairing vide mais silence ?

Revenir à channels status --probe, matrice des droits bot et logs (policy). Vérifier qu'un token d'espace de staging n'alimente pas une passerelle censée servir l'espace de production.

Différence heartbeat ?

Heartbeat et thinking ciblent plutôt les tâches planifiées et les sorties vides ; si seuls les groupes et la mention posent problème, restez côté canal. Si tout canal incluant les MP est mort, ouvrez aussi l'article heartbeat.

Intents Discord OK, serveur muet ?

Droits de salon, Read Message History, rôles sur canaux privés ; après sauvegarde du portail développeur, attendre quelques minutes.

Slack en ligne sans déclencheur ?

URL de la requête d'événements, réautorisation complète, installation par workspace ; corréler « Event Delivery » Slack et journaux d'accès passerelle à la seconde près.