Suppression de BlueBubbles et utilisation d’iMessage via imsg
OpenClaw n’intègre plus le canal BlueBubbles. La prise en charge d’iMessage passe par le Pluginimessage inclus : le Gateway lance imsg en tant que processus enfant, localement ou par l’intermédiaire d’un wrapper SSH, et communique en JSON-RPC via stdin/stdout. Aucun serveur, aucun Webhook, aucun port.
Si votre configuration contient encore channels.bluebubbles, migrez-la vers channels.imessage. L’ancienne URL de documentation /channels/bluebubbles redirige vers Migration depuis BlueBubbles, qui contient la table complète de conversion de la configuration et la liste de vérification pour la transition.
Modifications apportées
- Le parcours iMessage pris en charge ne comporte aucun serveur HTTP BlueBubbles, aucune route Webhook, aucun mot de passe REST ni aucun environnement d’exécution du Plugin BlueBubbles.
- OpenClaw lit et surveille Messages au moyen d’
imsgsur le Mac où la session Messages.app est ouverte. - Les fonctions de base d’envoi, de réception, d’historique et de gestion des médias utilisent les interfaces
imsghabituelles et les autorisations macOS. - Les actions avancées (réponses dans un fil, réactions Tapback, modification, annulation de l’envoi, effets, accusés de lecture, indicateurs de saisie et gestion des groupes) nécessitent le pont d’API privée : exécutez
imsg launch, ce qui exige la désactivation de SIP. - Les Gateway Linux et Windows peuvent toujours utiliser iMessage en faisant pointer
channels.imessage.cliPathvers un wrapper SSH qui exécuteimsgsur le Mac connecté.
Procédure à suivre
-
Installez et vérifiez
imsgsur le Mac exécutant Messages : -
Accordez les autorisations d’accès complet au disque et d’automatisation au contexte de processus qui exécute
imsget OpenClaw. -
Convertissez l’ancienne configuration :
-
Redémarrez le Gateway et vérifiez son état :
- Testez les messages privés, les groupes, les pièces jointes et toutes les actions d’API privée dont vous dépendez avant de supprimer votre ancien serveur BlueBubbles.
Notes de migration
channels.bluebubbles.serverUrletchannels.bluebubbles.passwordn’ont aucun équivalent pour iMessage : aucun serveur ne doit être contacté ni authentifié.allowFrom,groupAllowFrom,groups,includeAttachments,attachmentRoots,mediaMaxMb,textChunkLimitetactions.*conservent leur signification souschannels.imessage.channels.imessage.includeAttachmentsreste désactivé par défaut. Activez-le explicitement si vous souhaitez que les photos, mémos vocaux, vidéos ou fichiers entrants parviennent à l’agent.- Avec
groupPolicy: "allowlist", copiez l’ancien blocgroups, y compris toute entrée générique"*". Les listes d’autorisation des expéditeurs de groupe et le registre des groupes constituent des contrôles distincts : un blocgroupscontenant des entrées, mais sanschat_idcorrespondant (ni entrée"*"), entraîne l’abandon du message lors de l’exécution, tandis qu’un blocgroupsvide consigne un avertissement au démarrage, même si le filtrage des expéditeurs laisse toujours passer les messages. - Les liaisons ACP comportant
match.channel: "bluebubbles"doivent être remplacées par"imessage". - Les anciennes clés de session BlueBubbles ne deviennent pas des clés de session iMessage. Les approbations d’association reposent sur les identifiants des expéditeurs ; les entrées
allowFromcopiées continuent donc de fonctionner, mais l’historique des conversations associé aux clés de session BlueBubbles n’est pas transféré.