Passer au contenu principal

Documentation Index

Fetch the complete documentation index at: https://docs.openclaw.ai/llms.txt

Use this file to discover all available pages before exploring further.

Pour les déploiements OpenClaw iMessage, utilisez imsg sur un hôte macOS Messages connecté. Si votre Gateway s’exécute sous Linux ou Windows, pointez channels.imessage.cliPath vers un wrapper SSH qui exécute imsg sur le Mac.Le rattrapage après indisponibilité du Gateway est optionnel. Lorsqu’il est activé (channels.imessage.catchup.enabled: true), le gateway rejoue au démarrage suivant les messages entrants arrivés dans chat.db pendant qu’il était hors ligne (plantage, redémarrage, mise en veille du Mac). Désactivé par défaut — voir Rattrapage après une indisponibilité du gateway. Clôt openclaw#78649.
La prise en charge de BlueBubbles a été supprimée. Migrez les configurations channels.bluebubbles vers channels.imessage ; OpenClaw prend uniquement en charge iMessage via imsg. Commencez par Suppression de BlueBubbles et chemin iMessage via imsg pour l’annonce courte, ou Depuis BlueBubbles pour le tableau de migration complet.
État : intégration CLI externe native. Le Gateway lance imsg rpc et communique en JSON-RPC sur stdio (pas de démon/port distinct). Les actions avancées nécessitent imsg launch et une sonde d’API privée réussie.

Actions d’API privée

Réponses, tapbacks, effets, pièces jointes et gestion des groupes.

Appairage

Les MP iMessage utilisent le mode d’appairage par défaut.

Mac distant

Utilisez un wrapper SSH lorsque le Gateway ne s’exécute pas sur le Mac Messages.

Référence de configuration

Référence complète des champs iMessage.

Configuration rapide

1

Installer et vérifier imsg

brew install steipete/tap/imsg
imsg rpc --help
imsg launch
openclaw channels status --probe
2

Configurer OpenClaw

{
  channels: {
    imessage: {
      enabled: true,
      cliPath: "/usr/local/bin/imsg",
      dbPath: "/Users/user/Library/Messages/chat.db",
    },
  },
}
3

Démarrer le gateway

openclaw gateway
4

Approuver le premier appairage par MP (dmPolicy par défaut)

openclaw pairing list imessage
openclaw pairing approve imessage <CODE>
Les demandes d’appairage expirent au bout de 1 heure.

Exigences et autorisations (macOS)

  • Messages doit être connecté sur le Mac exécutant imsg.
  • L’accès complet au disque est requis pour le contexte de processus exécutant OpenClaw/imsg (accès à la base de données Messages).
  • L’autorisation d’automatisation est requise pour envoyer des messages via Messages.app.
  • Pour les actions avancées (réagir / modifier / annuler l’envoi / réponse en fil / effets / opérations de groupe), la Protection de l’intégrité du système doit être désactivée — voir Activation de l’API privée imsg ci-dessous. L’envoi/réception de texte et de médias de base fonctionne sans cela.
Les autorisations sont accordées par contexte de processus. Si le gateway s’exécute sans interface (LaunchAgent/SSH), exécutez une commande interactive ponctuelle dans ce même contexte pour déclencher les invites :
imsg chats --limit 1
# or
imsg send <handle> "test"

Activation de l’API privée imsg

imsg est fourni avec deux modes de fonctionnement :
  • Mode de base (par défaut, aucune modification de SIP requise) : texte et médias sortants via send, surveillance/historique entrants, liste des conversations. C’est ce que vous obtenez immédiatement après un nouveau brew install steipete/tap/imsg plus les autorisations macOS standard ci-dessus.
  • Mode API privée : imsg injecte une dylib d’assistance dans Messages.app pour appeler des fonctions IMCore internes. C’est ce qui débloque react, edit, unsend, reply (en fil), sendWithEffect, renameGroup, setGroupIcon, addParticipant, removeParticipant, leaveGroup, ainsi que les indicateurs de saisie et les confirmations de lecture.
Pour accéder à la surface d’actions avancées documentée sur cette page de canal, vous avez besoin du mode API privée. Le README de imsg est explicite sur cette exigence :
Les fonctionnalités avancées telles que read, typing, launch, l’envoi riche adossé au pont, la mutation de messages et la gestion des conversations sont optionnelles. Elles exigent que SIP soit désactivé et qu’une dylib d’assistance soit injectée dans Messages.app. imsg launch refuse l’injection lorsque SIP est activé.
La technique d’injection de l’assistant utilise la propre dylib de imsg pour accéder aux API privées de Messages. Il n’y a pas de serveur tiers ni d’environnement d’exécution BlueBubbles dans le chemin iMessage d’OpenClaw.
Désactiver SIP est un véritable compromis de sécurité. SIP est l’une des protections principales de macOS contre l’exécution de code système modifié ; le désactiver à l’échelle du système ouvre une surface d’attaque supplémentaire et peut provoquer des effets de bord. Notamment, désactiver SIP sur les Mac Apple Silicon désactive aussi la possibilité d’installer et d’exécuter des apps iOS sur votre Mac.Considérez cela comme un choix opérationnel délibéré, pas comme une valeur par défaut. Si votre modèle de menace ne peut pas tolérer que SIP soit désactivé, iMessage intégré est limité au mode de base — envoi/réception de texte et de médias uniquement, sans réactions / modification / annulation d’envoi / effets / opérations de groupe.

Configuration

  1. Installez (ou mettez à niveau) imsg sur le Mac qui exécute Messages.app :
    brew install steipete/tap/imsg
    imsg --version
    imsg status --json
    
    La sortie de imsg status --json indique bridge_version, rpc_methods et les selectors par méthode afin que vous puissiez voir ce que la version actuelle prend en charge avant de commencer.
  2. Désactivez la Protection de l’intégrité du système. Cela dépend de la version de macOS, car l’exigence Apple sous-jacente varie selon l’OS et le matériel :
    • macOS 10.13–10.15 (Sierra–Catalina) : désactivez Library Validation via Terminal, redémarrez en mode Récupération, exécutez csrutil disable, redémarrez.
    • macOS 11+ (Big Sur et versions ultérieures), Intel : mode Récupération (ou Récupération par Internet), csrutil disable, redémarrez.
    • macOS 11+, Apple Silicon : séquence de démarrage avec le bouton d’alimentation pour entrer en mode Récupération ; sur les versions récentes de macOS, maintenez la touche Maj gauche lorsque vous cliquez sur Continuer, puis csrutil disable. Les configurations de machine virtuelle suivent un flux distinct — prenez d’abord un instantané de la VM.
    • macOS 26 / Tahoe : les politiques de validation de bibliothèques et les contrôles d’autorisations privées imagent se sont encore renforcés ; imsg peut nécessiter une version mise à jour pour suivre. Si l’injection de imsg launch ou certains selectors commencent à renvoyer false après une mise à niveau majeure de macOS, consultez les notes de version de imsg avant de supposer que l’étape SIP a réussi.
    Suivez le flux du mode Récupération d’Apple pour votre Mac afin de désactiver SIP avant d’exécuter imsg launch.
  3. Injectez l’assistant. Avec SIP désactivé et Messages.app connecté :
    imsg launch
    
    imsg launch refuse l’injection lorsque SIP est encore activé ; cela sert donc aussi de confirmation que l’étape 2 a été prise en compte.
  4. Vérifiez le pont depuis OpenClaw :
    openclaw channels status --probe
    
    L’entrée iMessage doit indiquer works, et imsg status --json | jq '.selectors' doit afficher retractMessagePart: true ainsi que les sélecteurs de modification / saisie / lecture exposés par votre version de macOS. Le filtrage par méthode du Plugin OpenClaw dans actions.ts n’annonce que les actions dont le sélecteur sous-jacent vaut true ; la surface d’actions que vous voyez dans la liste d’outils de l’agent reflète donc ce que le pont peut réellement faire sur cet hôte.
Si openclaw channels status --probe indique que le canal est works mais que certaines actions lèvent “iMessage <action> requires the imsg private API bridge” au moment de l’envoi, exécutez de nouveau imsg launch — l’assistant peut disparaître (redémarrage de Messages.app, mise à jour de l’OS, etc.) et l’état available: true mis en cache continuera d’annoncer les actions jusqu’à ce que la prochaine sonde l’actualise.

Quand vous ne pouvez pas désactiver SIP

Si la désactivation de SIP n’est pas acceptable pour votre modèle de menace :
  • imsg revient au mode de base — texte + médias + réception uniquement.
  • Le Plugin OpenClaw annonce toujours l’envoi de texte/médias et la surveillance entrante ; il masque simplement react, edit, unsend, reply, sendWithEffect et les opérations de groupe dans la surface d’actions (selon le filtrage de capacité par méthode).
  • Vous pouvez exécuter un Mac non Apple Silicon distinct (ou un Mac bot dédié) avec SIP désactivé pour la charge de travail iMessage, tout en gardant SIP activé sur vos appareils principaux. Voir Utilisateur macOS bot dédié (identité iMessage séparée) ci-dessous.

Contrôle d’accès et routage

channels.imessage.dmPolicy contrôle les messages directs :
  • pairing (par défaut)
  • allowlist
  • open (nécessite que allowFrom inclue "*")
  • disabled
Champ de liste d’autorisation : channels.imessage.allowFrom.Les entrées de liste d’autorisation doivent identifier les expéditeurs : identifiants ou groupes d’accès d’expéditeur statiques (accessGroup:<name>). Utilisez channels.imessage.groupAllowFrom pour les cibles de conversation telles que chat_id:*, chat_guid:* ou chat_identifier:* ; utilisez channels.imessage.groups pour les clés de registre numériques chat_id.

Liaisons de conversation ACP

Les anciennes conversations iMessage peuvent également être liées à des sessions ACP. Flux opérateur rapide :
  • Exécutez /acp spawn codex --bind here dans le MP ou la conversation de groupe autorisée.
  • Les futurs messages dans cette même conversation iMessage sont routés vers la session ACP lancée.
  • /new et /reset réinitialisent sur place la même session ACP liée.
  • /acp close ferme la session ACP et supprime la liaison.
Les liaisons persistantes configurées sont prises en charge via les entrées bindings[] de niveau supérieur avec type: "acp" et match.channel: "imessage". match.peer.id peut utiliser :
  • un identifiant de MP normalisé comme +15555550123 ou user@example.com
  • chat_id:<id> (recommandé pour des liaisons de groupe stables)
  • chat_guid:<guid>
  • chat_identifier:<identifier>
Exemple :
{
  agents: {
    list: [
      {
        id: "codex",
        runtime: {
          type: "acp",
          acp: { agent: "codex", backend: "acpx", mode: "persistent" },
        },
      },
    ],
  },
  bindings: [
    {
      type: "acp",
      agentId: "codex",
      match: {
        channel: "imessage",
        accountId: "default",
        peer: { kind: "group", id: "chat_id:123" },
      },
      acp: { label: "codex-group" },
    },
  ],
}
Consultez Agents ACP pour le comportement partagé des liaisons ACP.

Modèles de déploiement

Utilisez un identifiant Apple et un utilisateur macOS dédiés afin que le trafic du bot soit isolé de votre profil Messages personnel.Flux typique :
  1. Créez/connectez-vous à un utilisateur macOS dédié.
  2. Connectez-vous à Messages avec l’identifiant Apple du bot dans cet utilisateur.
  3. Installez imsg dans cet utilisateur.
  4. Créez un wrapper SSH afin qu’OpenClaw puisse exécuter imsg dans le contexte de cet utilisateur.
  5. Faites pointer channels.imessage.accounts.<id>.cliPath et .dbPath vers ce profil utilisateur.
La première exécution peut nécessiter des approbations GUI (Automation + Full Disk Access) dans la session utilisateur du bot.
Topologie courante :
  • le gateway s’exécute sur Linux/VM
  • iMessage + imsg s’exécutent sur un Mac dans votre tailnet
  • le wrapper cliPath utilise SSH pour exécuter imsg
  • remoteHost active la récupération des pièces jointes par SCP
Exemple :
{
  channels: {
    imessage: {
      enabled: true,
      cliPath: "~/.openclaw/scripts/imsg-ssh",
      remoteHost: "bot@mac-mini.tailnet-1234.ts.net",
      includeAttachments: true,
      dbPath: "/Users/bot/Library/Messages/chat.db",
    },
  },
}
#!/usr/bin/env bash
exec ssh -T bot@mac-mini.tailnet-1234.ts.net imsg "$@"
Utilisez des clés SSH afin que SSH et SCP soient tous deux non interactifs. Assurez-vous d’abord que la clé d’hôte est approuvée (par exemple ssh bot@mac-mini.tailnet-1234.ts.net) afin que known_hosts soit renseigné.
iMessage prend en charge la configuration par compte sous channels.imessage.accounts.Chaque compte peut remplacer des champs tels que cliPath, dbPath, allowFrom, groupPolicy, mediaMaxMb, les paramètres d’historique et les allowlists de racines de pièces jointes.

Médias, segmentation et cibles de livraison

  • l’ingestion des pièces jointes entrantes est désactivée par défaut — définissez channels.imessage.includeAttachments: true pour transmettre les photos, mémos vocaux, vidéos et autres pièces jointes à l’agent. Lorsqu’elle est désactivée, les iMessages contenant uniquement des pièces jointes sont rejetés avant d’atteindre l’agent et peuvent ne produire aucune ligne de journal Inbound message.
  • les chemins de pièces jointes distants peuvent être récupérés via SCP lorsque remoteHost est défini
  • les chemins de pièces jointes doivent correspondre aux racines autorisées :
    • channels.imessage.attachmentRoots (local)
    • channels.imessage.remoteAttachmentRoots (mode SCP distant)
    • motif de racine par défaut : /Users/*/Library/Messages/Attachments
  • SCP utilise une vérification stricte de la clé d’hôte (StrictHostKeyChecking=yes)
  • la taille des médias sortants utilise channels.imessage.mediaMaxMb (16 Mo par défaut)
  • limite de segment de texte : channels.imessage.textChunkLimit (4000 par défaut)
  • mode de segmentation : channels.imessage.chunkMode
    • length (par défaut)
    • newline (découpage donnant la priorité aux paragraphes)
Cibles explicites préférées :
  • chat_id:123 (recommandé pour un routage stable)
  • chat_guid:...
  • chat_identifier:...
Les cibles par identifiant sont également prises en charge :
  • imessage:+1555...
  • sms:+1555...
  • user@example.com
imsg chats --limit 20

Actions d’API privée

Lorsque imsg launch est en cours d’exécution et que openclaw channels status --probe signale privateApi.available: true, l’outil de message peut utiliser des actions natives d’iMessage en plus des envois de texte normaux.
{
  channels: {
    imessage: {
      actions: {
        reactions: true,
        edit: true,
        unsend: true,
        reply: true,
        sendWithEffect: true,
        sendAttachment: true,
        renameGroup: true,
        setGroupIcon: true,
        addParticipant: true,
        removeParticipant: true,
        leaveGroup: true,
      },
    },
  },
}
  • react : ajouter/supprimer des tapbacks iMessage (messageId, emoji, remove). Les tapbacks pris en charge correspondent à love, like, dislike, laugh, emphasize et question.
  • reply : envoyer une réponse en fil à un message existant (messageId, text ou message, plus chatGuid, chatId, chatIdentifier ou to).
  • sendWithEffect : envoyer du texte avec un effet iMessage (text ou message, effect ou effectId).
  • edit : modifier un message envoyé sur les versions macOS/API privée prises en charge (messageId, text ou newText).
  • unsend : retirer un message envoyé sur les versions macOS/API privée prises en charge (messageId).
  • upload-file : envoyer des médias/fichiers (buffer en base64 ou un media/path/filePath hydraté, filename, asVoice facultatif). Alias hérité : sendAttachment.
  • renameGroup, setGroupIcon, addParticipant, removeParticipant, leaveGroup : gérer les conversations de groupe lorsque la cible actuelle est une conversation de groupe.
Le contexte iMessage entrant inclut à la fois des valeurs MessageSid courtes et des GUID de message complets lorsqu’ils sont disponibles. Les ID courts sont limités au cache récent de réponses en mémoire et sont vérifiés par rapport à la conversation actuelle avant utilisation. Si un ID court a expiré ou appartient à une autre conversation, réessayez avec le MessageSidFull complet.
OpenClaw masque les actions d’API privée uniquement lorsque l’état de sonde mis en cache indique que le pont est indisponible. Si l’état est inconnu, les actions restent visibles et déclenchent les sondes à la demande afin que la première action puisse réussir après imsg launch sans actualisation manuelle séparée de l’état.
Lorsque le pont d’API privée est actif, les conversations entrantes acceptées sont marquées comme lues avant la distribution et une bulle de saisie est affichée à l’expéditeur pendant que l’agent génère. Désactivez le marquage comme lu avec :
{
  channels: {
    imessage: {
      sendReadReceipts: false,
    },
  },
}
Les anciennes versions d’imsg antérieures à la liste de capacités par méthode désactiveront silencieusement la saisie/lecture ; OpenClaw journalise un avertissement unique par redémarrage afin que l’absence d’accusé de lecture soit attribuable.
OpenClaw s’abonne aux tapbacks iMessage et route les réactions acceptées comme événements système au lieu de texte de message normal, de sorte qu’un tapback utilisateur ne déclenche pas une boucle de réponse ordinaire.Le mode de notification est contrôlé par channels.imessage.reactionNotifications :
  • "own" (par défaut) : notifier uniquement lorsque des utilisateurs réagissent à des messages rédigés par le bot.
  • "all" : notifier pour tous les tapbacks entrants provenant d’expéditeurs autorisés.
  • "off" : ignorer les tapbacks entrants.
Les remplacements par compte utilisent channels.imessage.accounts.<id>.reactionNotifications.

Écritures de configuration

iMessage autorise par défaut les écritures de configuration initiées par le canal (pour /config set|unset lorsque commands.config: true). Désactiver :
{
  channels: {
    imessage: {
      configWrites: false,
    },
  },
}

Fusion des MP envoyés séparément (commande + URL dans une seule composition)

Lorsqu’un utilisateur saisit ensemble une commande et une URL — par exemple Dump https://example.com/article — l’app Messages d’Apple divise l’envoi en deux lignes chat.db distinctes :
  1. Un message texte ("Dump").
  2. Une bulle d’aperçu d’URL ("https://...") avec des images d’aperçu OG comme pièces jointes.
Les deux lignes arrivent dans OpenClaw à ~0,8-2,0 s d’intervalle sur la plupart des configurations. Sans coalescence, l’agent reçoit la commande seule au tour 1, répond (souvent « envoyez-moi l’URL »), et ne voit l’URL qu’au tour 2 — moment auquel le contexte de la commande est déjà perdu. Cela vient du pipeline d’envoi d’Apple, pas d’un comportement introduit par OpenClaw ou imsg. channels.imessage.coalesceSameSenderDms permet à un DM de fusionner des lignes consécutives du même expéditeur en un seul tour d’agent. Les discussions de groupe continuent à être distribuées message par message afin de préserver la structure des tours multi-utilisateurs.
Activez-le lorsque :
  • Vous expédiez des Skills qui attendent command + payload dans un seul message (dump, paste, save, queue, etc.).
  • Vos utilisateurs collent des URL, des images ou du contenu long avec des commandes.
  • Vous pouvez accepter la latence de tour de DM ajoutée (voir ci-dessous).
Laissez-le désactivé lorsque :
  • Vous avez besoin d’une latence minimale pour les déclencheurs de DM d’un seul mot.
  • Tous vos flux sont des commandes ponctuelles sans suivi de charge utile.

Scénarios et ce que l’agent voit

L’utilisateur composechat.db produitIndicateur désactivé (par défaut)Indicateur activé + fenêtre de 2500 ms
Dump https://example.com (un envoi)2 lignes à ~1 s d’écartDeux tours d’agent : « Dump » seul, puis l’URLUn tour : texte fusionné Dump https://example.com
Save this 📎image.jpg caption (pièce jointe + texte)2 lignesDeux tours (pièce jointe supprimée lors de la fusion)Un tour : texte + image préservés
/status (commande autonome)1 ligneDistribution instantanéeAttend jusqu’à la fenêtre, puis distribue
URL collée seule1 ligneDistribution instantanéeDistribution instantanée (une seule entrée dans le bucket)
Texte + URL envoyés comme deux messages séparés délibérés, à quelques minutes d’intervalle2 lignes hors fenêtreDeux toursDeux tours (la fenêtre expire entre eux)
Rafale rapide (>10 petits DM dans la fenêtre)N lignesN toursUn tour, sortie bornée (première + dernières, plafonds texte/pièces jointes appliqués)
Deux personnes écrivent dans une discussion de groupeN lignes de M expéditeursM+ tours (un par bucket d’expéditeur)M+ tours — les discussions de groupe ne sont pas coalescées

Rattraper après une interruption du Gateway

Lorsque le Gateway est hors ligne (plantage, redémarrage, mise en veille du Mac, machine éteinte), imsg watch reprend depuis l’état actuel de chat.db une fois que le Gateway redémarre — tout ce qui est arrivé pendant l’intervalle n’est, par défaut, jamais vu. Le rattrapage rejoue ces messages au démarrage suivant afin que l’agent ne manque pas silencieusement le trafic entrant. Le rattrapage est désactivé par défaut. Activez-le par canal :
channels: {
  imessage: {
    catchup: {
      enabled: true,             // master switch (default: false)
      maxAgeMinutes: 120,        // skip rows older than now - 2h (default: 120, clamp 1..720)
      perRunLimit: 50,           // max rows replayed per startup (default: 50, clamp 1..500)
      firstRunLookbackMinutes: 30, // first run with no cursor: look back 30 min (default: 30)
      maxFailureRetries: 10,     // give up on a wedged guid after 10 dispatch failures (default: 10)
    },
  },
}

Fonctionnement

Un passage par démarrage de monitorIMessageProvider, séquencé comme suit : imsg launch prêt → watch.subscribeperformIMessageCatchup → boucle de distribution en direct. Le rattrapage lui-même utilise chats.list + messages.history par discussion avec le même client JSON-RPC que celui utilisé par imsg watch. Tout ce qui arrive pendant le passage de rattrapage passe normalement par la distribution en direct ; le cache de déduplication entrante existant absorbe tout chevauchement avec les lignes rejouées. Chaque ligne rejouée est injectée dans le chemin de distribution en direct (evaluateIMessageInbound + dispatchInboundMessage), de sorte que les listes d’autorisation, la politique de groupe, l’anti-rebond, le cache d’écho et les accusés de lecture se comportent de façon identique pour les messages rejoués et les messages en direct.

Sémantique du curseur et des nouvelles tentatives

Le rattrapage conserve un curseur par compte à <openclawStateDir>/imessage/catchup/<account>__<hash>.json (le répertoire d’état OpenClaw vaut par défaut ~/.openclaw, surchargeable avec OPENCLAW_STATE_DIR) :
{
  "lastSeenMs": 1717900800000,
  "lastSeenRowid": 482910,
  "updatedAt": 1717900801234,
  "failureRetries": { "<guid>": 1 }
}
  • Le curseur avance à chaque distribution réussie et reste en place lorsque la distribution d’une ligne lève une exception — le démarrage suivant réessaie la même ligne depuis le curseur conservé.
  • Après maxFailureRetries exceptions consécutives pour le même guid, le rattrapage journalise un warn et force l’avancement du curseur au-delà du message bloqué afin que les démarrages suivants puissent progresser.
  • Les GUID déjà abandonnés sont ignorés dès qu’ils sont vus (aucune tentative de distribution) lors des exécutions ultérieures et comptés sous skippedGivenUp dans le résumé d’exécution.

Signaux visibles par l’opérateur

imessage catchup: replayed=N skippedFromMe=… skippedGivenUp=… failed=… givenUp=… fetchedCount=…
imessage catchup: giving up on guid=<guid> after <N> failures; advancing cursor past it
imessage catchup: fetched <X> rows across chats, capped to perRunLimit=<Y>
Une ligne WARN ... capped to perRunLimit signifie qu’un seul démarrage n’a pas vidé tout l’arriéré. Augmentez perRunLimit (max 500) si vos interruptions dépassent régulièrement le passage par défaut de 50 lignes.

Quand le laisser désactivé

  • Le Gateway fonctionne en continu avec redémarrage automatique par watchdog et les interruptions durent toujours moins de quelques secondes — la valeur par défaut désactivée convient.
  • Le volume de DM est faible et les messages manqués ne changeraient pas le comportement de l’agent — la fenêtre initiale firstRunLookbackMinutes peut distribuer un ancien contexte surprenant lors de la première activation.
Lorsque vous activez le rattrapage, le premier démarrage sans curseur ne remonte que sur firstRunLookbackMinutes (30 min par défaut), pas sur toute la fenêtre maxAgeMinutes — cela évite de rejouer un long historique de messages antérieurs à l’activation.

Dépannage

Validez le binaire et la prise en charge RPC :
imsg rpc --help
imsg status --json
openclaw channels status --probe
Si la sonde indique que RPC n’est pas pris en charge, mettez à jour imsg. Si les actions d’API privée ne sont pas disponibles, exécutez imsg launch dans la session utilisateur macOS connectée et relancez la sonde. Si le Gateway ne s’exécute pas sur macOS, utilisez plutôt la configuration Mac distant via SSH ci-dessus au lieu du chemin imsg local par défaut.
Le cliPath: "imsg" par défaut doit s’exécuter sur le Mac connecté à Messages. Sous Linux ou Windows, définissez channels.imessage.cliPath sur un script wrapper qui se connecte à ce Mac via SSH et exécute imsg "$@".
#!/usr/bin/env bash
exec ssh -T messages-mac imsg "$@"
Exécutez ensuite :
openclaw channels status --probe --channel imessage
Vérifiez :
  • channels.imessage.dmPolicy
  • channels.imessage.allowFrom
  • les approbations d’appairage (openclaw pairing list imessage)
Vérifiez :
  • channels.imessage.groupPolicy
  • channels.imessage.groupAllowFrom
  • le comportement de liste d’autorisation de channels.imessage.groups
  • la configuration des motifs de mention (agents.list[].groupChat.mentionPatterns)
Vérifiez :
  • channels.imessage.remoteHost
  • channels.imessage.remoteAttachmentRoots
  • l’authentification par clé SSH/SCP depuis l’hôte du Gateway
  • l’existence de la clé d’hôte dans ~/.ssh/known_hosts sur l’hôte du Gateway
  • la lisibilité du chemin distant sur le Mac exécutant Messages
Relancez dans un terminal graphique interactif dans le même contexte utilisateur/session et approuvez les demandes :
imsg chats --limit 1
imsg send <handle> "test"
Confirmez que l’accès complet au disque + Automation sont accordés pour le contexte de processus qui exécute OpenClaw/imsg.

Repères de référence de configuration

Connexe