Skip to main content

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 Plugin imessage 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’imsg sur 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 imsg habituelles 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.cliPath vers un wrapper SSH qui exécute imsg sur le Mac connecté.

Procédure à suivre

  1. Installez et vérifiez imsg sur le Mac exécutant Messages :
  2. Accordez les autorisations d’accès complet au disque et d’automatisation au contexte de processus qui exécute imsg et OpenClaw.
  3. Convertissez l’ancienne configuration :
  4. Redémarrez le Gateway et vérifiez son état :
  5. 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.serverUrl et channels.bluebubbles.password n’ont aucun équivalent pour iMessage : aucun serveur ne doit être contacté ni authentifié.
  • allowFrom, groupAllowFrom, groups, includeAttachments, attachmentRoots, mediaMaxMb, textChunkLimit et actions.* conservent leur signification sous channels.imessage.
  • channels.imessage.includeAttachments reste 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 bloc groups, 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 bloc groups contenant des entrées, mais sans chat_id correspondant (ni entrée "*"), entraîne l’abandon du message lors de l’exécution, tandis qu’un bloc groups vide 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 allowFrom copiées continuent donc de fonctionner, mais l’historique des conversations associé aux clés de session BlueBubbles n’est pas transféré.

Voir aussi