Configurer iMessage dans OpenClaw

iMessage est le seul canal OpenClaw qui exige un Mac connecté à Messages, donc la configuration porte vraiment sur l’emplacement de ce Mac : sous la passerelle, ou quelque part que la passerelle atteint par SSH. Voici l’installation de l’extension, le chemin rapide local, la topologie distante avec ses règles de wrapper, et les permissions macOS qui décident si les envois fonctionnent tout court.

Chemin rapide local

• L’extension officielle s’installe sur l’hôte de la passerelle avec la commande d’installation d’extensions pour le paquet iMessage, et la documentation dit de vérifier le résultat d’application avant de continuer ; les messages privés iMessage sont en appairage par défaut, les actions d’API privée couvrent les réponses, les tapbacks, les effets, les sondages, les pièces jointes et la gestion des groupes, et un Mac distant utilise un wrapper SSH.
• Sur le Mac Messages, vous installez imsg depuis son tap Homebrew, le mettez à jour, vérifiez l’aide RPC, lancez la commande de lancement et sondez le canal ; quand l’assistant local détecte un imsg par défaut manquant, il peut proposer de l’installer par Homebrew, et un imsg géré par Homebrew peut être réinstallé ou mis à jour, tandis que les wrappers personnalisés du chemin de commande sont laissés intacts.
• La configuration active le canal et règle le chemin de commande sur le binaire imsg et le chemin de base sur la base de discussions Messages sous la bibliothèque de l’utilisateur, puis la passerelle est démarrée.
• Le premier message privé s’approuve avec les commandes de liste et d’approbation d’appairage, et les demandes d’appairage expirent après une heure.

Les permissions sont accordées par contexte de processus.

Mac distant par SSH

La plupart des installations n’ont pas besoin de SSH ; la topologie distante sert quand la passerelle ne peut pas tourner sur le Mac connecté à Messages. Le chemin de commande pointe alors vers un wrapper compatible stdio sur l’hôte de la passerelle, donné en chemin absolu pour que les lancements de service ne dépendent pas de l’expansion du dossier personnel, qui se connecte en SSH au Mac Messages et lance imsg, imsg étant installé et mis à jour sur le Mac distant plutôt que sur l’hôte de la passerelle. La configuration recommandée avec pièces jointes règle le chemin du wrapper, l’hôte distant en utilisateur à hôte, le chemin de base interprété sur le Mac Messages, les pièces jointes entrantes activées, et des racines de pièces jointes facultatives fusionnées avec le dossier de pièces jointes Messages par défaut des deux côtés. L’hôte distant identifie le Mac Messages pour les récupérations de pièces jointes entrantes et la mise en attente des pièces jointes sortantes : pour les fichiers sortants, OpenClaw crée un chemin temporaire réservé au propriétaire sur ce Mac, copie le fichier par le transport SSH et SCP strict, ne passe que le chemin distant à imsg, et tente la suppression après succès, échec ou dépassement de délai, un appel de nettoyage échoué étant journalisé comme avertissement et pouvant laisser le dossier derrière lui. Un hôte distant explicite l’emporte ; par compatibilité, OpenClaw auto-détecte la forme simple de wrapper transparent une fois par processus et réutilise l’hôte, mais les wrappers riches en options avec sauts ou commandes de proxy doivent régler l’hôte distant, la valeur doit être hôte ou utilisateur à hôte sans espaces ni options SSH, la vérification stricte des clés d’hôte signifie que la clé du Mac doit déjà figurer dans les hôtes connus de la passerelle, et les chemins de pièces jointes sont validés contre les racines autorisées. L’avertissement qui suit compte le plus : tout wrapper ou proxy devant imsg doit se comporter comme un tuyau stdio transparent pour du JSON-RPC de longue durée, en transmettant chaque morceau de stdin et de stdout dès que des octets sont disponibles, en préservant les sauts de ligne, en évitant les lectures bloquantes de taille fixe et en gardant stderr séparé, parce qu’un wrapper qui met stdin en tampon jusqu’à remplir un bloc produit des délais RPC dépassés et des redémarrages répétés du canal qui ressemblent à une panne d’iMessage alors qu’imsg lui-même est sain ; le wrapper SSH simple est sûr, et les pipelines qui filtrent la sortie par des outils à tampon de ligne ne le sont pas sauf si chaque étape est en tampon de ligne.

Permissions macOS

• Messages doit être connecté sur le Mac qui fait tourner imsg, l’accès complet au disque est requis pour le contexte de processus qui exécute OpenClaw ou imsg afin de lire la base Messages, la permission d’automatisation est requise pour envoyer par l’application Messages, et les actions avancées, réagir, modifier, annuler, répondre en fil, effets, sondages et opérations de groupe, exigent la désactivation de la protection de l’intégrité du système tandis que le texte et les médias de base fonctionnent sans.
• Les permissions sont accordées par contexte de processus, donc une passerelle sans écran sous LaunchAgent ou SSH doit lancer une commande interactive unique dans ce même contexte, lister une discussion ou envoyer un message de test, pour déclencher les invites.
• Une installation SSH distante peut lire les discussions, passer la sonde et traiter les messages entrants tandis que les envois sortants échouent sur une erreur AppleEvents non autorisé ; quand l’entrée d’automatisation dans la base TCC ou les réglages de confidentialité est enregistrée pour le wrapper de génération de clés SSH plutôt que pour imsg ou un shell local, macOS peut n’exposer aucune bascule Messages utilisable pour ce client côté serveur, réinitialiser AppleEvents ou relancer l’envoi continue d’échouer, et la solution est un contexte de processus pris en charge : faire tourner la passerelle ou au moins le pont imsg dans la session locale de l’utilisateur connecté, la démarrer depuis un LaunchAgent de cet utilisateur après avoir accordé les deux permissions depuis cette session, ou, si la topologie SSH à deux utilisateurs reste, vérifier un vrai envoi sortant par le wrapper exact avant d’activer le canal et revenir à une installation à un seul utilisateur quand l’automatisation ne peut pas être accordée.

OpenClaw sur iMessage est le billet du canal auquel cette configuration appartient, et Le déploiement iMessage d’OpenClaw les schémas d’utilisateur dédié et de Mac distant sur lesquels elle s’appuie.

Le wrapper est le canal

Tout ce que la passerelle sait de Messages passe par un seul tuyau stdio, et c’est pourquoi un wrapper qui met en tampon est indiscernable d’un canal mort et pourquoi la documentation détaille ce que le tuyau doit faire. L’API privée iMessage d’OpenClaw couvre le compromis SIP derrière les actions avancées, et Connecter votre premier canal en cinq minutes les canaux où rien de tout cela ne s’applique.

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é.

• Un Mac connecté, imsg par Homebrew, un code d’appairage.
• Le wrapper SSH doit transmettre les octets dès qu’ils arrivent.
• Accordez l’accès complet au disque et l’automatisation dans le contexte qui exécute imsg.