Dépanner iMessage dans OpenClaw

Une panne iMessage tient généralement à l’une de trois couches : le pont imsg, la pile Messages de macOS en dessous, ou une liste d’autorisation d’OpenClaw. La première règle de la documentation est de trouver la couche avant de changer la configuration, et le test est simple : la base sur le Mac change-t-elle quand un téléphone envoie un message ? Voici les vérifications dans l’ordre de la documentation.

Le pont et le Mac

• Pour un binaire imsg manquant ou un RPC non pris en charge, validez avec l’aide RPC, l’état JSON et la sonde du canal ; une sonde qui signale le RPC non pris en charge signifie mettre à jour imsg, des actions d’API privée indisponibles signifient lancer la commande de lancement dans la session utilisateur macOS connectée et sonder à nouveau, et une passerelle qui n’est pas sous macOS utilise l’installation du Mac distant par SSH au lieu du chemin local par défaut.
• Quand les messages partent mais que rien n’arrive en entrée, prouvez d’abord si le message a atteint le Mac local : listez les discussions, surveillez une discussion, et interrogez la base de discussions pour sa dernière date de message et son rowid, parce que si la base ne change pas, OpenClaw ne peut pas recevoir le message même quand l’état JSON signale un pont sain.
• Si les messages envoyés depuis le téléphone ne créent aucune nouvelle ligne, réparez la couche Messages et Apple Push de macOS avant de changer la configuration d’OpenClaw : un redémarrage unique du démon Push, du centre cellulaire, du démon des services d’identité et de l’agent de messagerie, puis la commande de lancement et un redémarrage de la passerelle, suivis d’un nouveau message depuis le téléphone et d’une nouvelle ligne de base ou d’un événement de veille avant de déboguer les sessions.
• Ce rafraîchissement ne doit pas devenir une boucle périodique de relancement du pont, parce que des lancements répétés plus des redémarrages de passerelle pendant un travail actif peuvent interrompre les livraisons et abandonner des exécutions de canal en cours.

Si chat.db ne change pas, OpenClaw ne peut pas recevoir le message même quand imsg status --json signale un pont sain.

Hors macOS, messages privés, groupes

Le chemin de commande par défaut doit tourner sur le Mac connecté à Messages, donc sous Linux ou Windows le chemin pointe vers un script wrapper qui se connecte en SSH à ce Mac et lance imsg avec les arguments transmis, après quoi la sonde du canal pour iMessage le confirme. Les messages privés ignorés se ramènent à la politique de messages privés, à la liste des messages privés et aux approbations d’appairage listées par la commande d’appairage. Les messages de groupe ignorés se ramènent à la politique de groupe, à la liste des expéditeurs de groupe, au comportement du registre des groupes, et à la mention obligatoire, où les motifs sont les motifs explicites ou le nom et l’emoji d’identité de l’agent routé, et la solution pour traiter chaque message des expéditeurs autorisés est une mention obligatoire réglée sur faux pour cette discussion dans la carte des groupes racine ou de compte en vigueur.

Pièces jointes et permissions

• Les pièces jointes distantes en échec se ramènent à la clé d’hôte distant, aux racines de pièces jointes distantes, à l’authentification par clé SSH et SCP depuis l’hôte de la passerelle, à la clé d’hôte du Mac présente dans les hôtes connus de la passerelle, et à la lisibilité du chemin distant sur le Mac qui fait tourner Messages.
• Les invites de permission macOS manquées se rattrapent en relançant une commande interactive dans un terminal graphique dans le même contexte d’utilisateur et de session, en listant une discussion ou en envoyant un message de test, et en approuvant les invites.
• Confirmez ensuite que l’accès complet au disque et l’automatisation sont accordés pour le contexte de processus qui exécute OpenClaw ou imsg, puisqu’un accord dans un autre contexte ne se transmet pas.

OpenClaw sur iMessage est le billet du canal auquel ces symptômes appartiennent, et Contrôle d’accès iMessage dans OpenClaw les listes d’autorisation derrière les messages privés et les groupes ignorés.

Prouver la couche d’abord

La vérification de la base est toute la méthode : un pont sain avec une base silencieuse est un problème Apple, et aucun réglage d’OpenClaw ne le corrige, et c’est pourquoi la documentation place la réparation Push avant tout changement de configuration. Le comportement des messages iMessage dans OpenClaw explique la récupération qui rejoue ce que le pont a manqué une fois revenu, et Configurer iMessage dans OpenClaw les règles de wrapper qui produisent de fausses pannes quand un tuyau met en tampon.

Sur Diali

iMessage ne fait pas partie des canaux que Diali connecte aujourd’hui : WhatsApp, Telegram, Discord, Slack, Mattermost, Matrix, SMS et voix. OpenClaw hébergé sur Diali est l’assistant et La sécurité chez Diali décrit la frontière qui s’applique à chaque canal connecté.

• Aucune nouvelle ligne de base signifie un problème Apple, pas de configuration.
• Relancez la pile Push une fois ; jamais en boucle.
• Accordez les permissions dans le contexte qui exécute imsg.