imsg sullo stesso host macOS con accesso effettuato a Messaggi. Se il Gateway viene eseguito altrove, configurare channels.imessage.cliPath affinché punti a un wrapper SSH trasparente che esegua imsg sul Mac.Il ripristino dei messaggi in entrata è automatico. Dopo il riavvio di un bridge o del Gateway, iMessage riproduce i messaggi persi durante l’interruzione e sopprime la vecchia «bomba di arretrati» che Apple può scaricare dopo un ripristino Push, eliminando i duplicati affinché nulla venga inoltrato due volte. Non è necessaria alcuna configurazione per abilitarlo: vedere Ripristino dei messaggi in entrata dopo il riavvio di un bridge o del Gateway.imsg rpc e comunica tramite JSON-RPC su stdio, senza daemon o porta separati. La modalità API privata è fortemente consigliata per un canale iMessage completo; risposte, tapback, effetti, sondaggi, risposte agli allegati e azioni di gruppo richiedono imsg launch e una verifica riuscita dell’API privata.
Per la comune configurazione locale, la procedura di configurazione di OpenClaw può proporre, previa conferma dell’utente, l’installazione o l’aggiornamento di imsg tramite Homebrew sul Mac con accesso effettuato a Messaggi. La configurazione manuale e le topologie con wrapper SSH restano a carico dell’operatore: installare o aggiornare imsg nello stesso contesto utente che eseguirà il Gateway o il wrapper.
Azioni dell'API privata
Associazione
Mac remoto
Riferimento della configurazione
Configurazione rapida
- Mac locale (percorso rapido)
- Mac remoto tramite SSH
Installare e verificare imsg
imsg, può proporre l’installazione di steipete/tap/imsg tramite Homebrew. Se rileva un’istanza di imsg gestita da Homebrew, può proporne la reinstallazione o l’aggiornamento. I wrapper cliPath personalizzati non vengono modificati.Configurare OpenClaw
Avviare il Gateway
Approvare la prima associazione per messaggio diretto (dmPolicy predefinita)
Requisiti e autorizzazioni (macOS)
- Sul Mac che esegue
imsgdeve essere stato effettuato l’accesso a Messaggi. - L’accesso completo al disco è obbligatorio per il contesto del processo che esegue OpenClaw/
imsg(accesso al database di Messaggi). - L’autorizzazione di automazione è obbligatoria per inviare messaggi tramite Messages.app.
- Per le azioni avanzate (reazione / modifica / annullamento dell’invio / risposta in thread / effetti / sondaggi / operazioni sui gruppi), la protezione dell’integrità del sistema deve essere disabilitata; vedere Abilitazione dell’API privata di imsg. L’invio e la ricezione di testo e contenuti multimediali di base funzionano senza disabilitarla.
Gli invii tramite wrapper SSH non riescono con AppleEvents -1743
Gli invii tramite wrapper SSH non riescono con AppleEvents -1743
channels status --probe ed elaborare i messaggi in entrata, mentre gli invii in uscita continuano a non riuscire a causa di un errore di autorizzazione AppleEvents:/usr/libexec/sshd-keygen-wrapper anziché per imsg o per il processo della shell locale, macOS potrebbe non mostrare un’opzione di Messaggi utilizzabile per tale client SSH lato server:tccutil reset AppleEvents o eseguire nuovamente imsg send tramite lo stesso wrapper SSH potrebbe continuare a non riuscire, perché il contesto di processo che necessita dell’autorizzazione di automazione per Messaggi è il wrapper SSH, non un’app a cui l’interfaccia utente possa concederla.Utilizzare invece uno dei contesti di processo imsg supportati:- Eseguire il Gateway, o almeno il bridge
imsg, nella sessione locale dell’utente con accesso effettuato a Messaggi. - Avviare il Gateway con un LaunchAgent per tale utente dopo aver concesso l’accesso completo al disco e l’autorizzazione di automazione dalla stessa sessione.
- Se si mantiene la topologia SSH con due utenti, verificare che un reale
imsg sendin uscita riesca tramite il wrapper esatto prima di abilitare il canale. Se non è possibile concedergli l’autorizzazione di automazione, riconfigurare il sistema con una configurazioneimsga utente singolo anziché affidarsi al wrapper SSH per gli invii.
Abilitazione dell’API privata di imsg
imsg viene distribuito con due modalità operative. Per OpenClaw, la modalità API privata è la configurazione consigliata perché fornisce al canale le azioni native di iMessage attese dagli utenti. La modalità di base resta utile per installazioni a basso rischio, per la verifica iniziale o per host sui quali non è possibile disabilitare SIP.
- Modalità di base (predefinita, non richiede modifiche a SIP): testo e contenuti multimediali in uscita tramite
send, monitoraggio/cronologia in entrata, elenco delle chat. È quanto viene fornito immediatamente da una nuova installazione dibrew install steipete/tap/imsgcon le autorizzazioni macOS standard indicate sopra. - Modalità API privata:
imsginserisce una dylib helper inMessages.appper chiamare funzioni interne diIMCore. Ciò abilitareact,edit,unsend,reply(in thread),sendWithEffect,pollepoll-vote(sondaggi nativi di Messaggi),renameGroup,setGroupIcon,addParticipant,removeParticipant,leaveGroup, oltre agli indicatori di digitazione e alle conferme di lettura.
imsg indica esplicitamente il requisito:
Le funzionalità avanzate comeLa tecnica di inserimento dell’helper utilizza la dylib diread,typing,launch, invio avanzato supportato dal bridge, modifica dei messaggi e gestione delle chat sono facoltative. Richiedono che SIP sia disabilitato e che una dylib helper venga inserita inMessages.app.imsg launchrifiuta di eseguire l’inserimento quando SIP è abilitato.
imsg per accedere alle API private di Messaggi. Nel percorso iMessage di OpenClaw non sono presenti server di terze parti né un runtime BlueBubbles.
Configurazione
-
Installare (o aggiornare)
imsgsul Mac che esegue Messages.app:L’output diimsg status --jsonriportabridge_version,rpc_methodseselectorsper ciascun metodo, in modo da mostrare ciò che la build corrente supporta prima dell’avvio. -
Disabilitare System Integrity Protection e, nelle versioni moderne di macOS, Library Validation. L’iniezione di una dylib ausiliaria non Apple nel componente firmato da Apple
Messages.apprichiede che SIP sia disabilitato e che la convalida delle librerie sia meno restrittiva. Il passaggio relativo a SIP in modalità di recupero dipende dalla versione di macOS:- macOS 10.13-10.15 (Sierra-Catalina): disabilitare Library Validation tramite Terminale, riavviare in modalità di recupero, eseguire
csrutil disable, quindi riavviare. - macOS 11+ (Big Sur e versioni successive), Intel: accedere alla modalità di recupero (o al recupero via Internet), eseguire
csrutil disable, quindi riavviare. - macOS 11+, Apple Silicon: usare la sequenza di avvio con il pulsante di accensione per accedere alla modalità di recupero; nelle versioni recenti di macOS tenere premuto il tasto Maiusc sinistro quando si fa clic su Continue, quindi eseguire
csrutil disable. Le configurazioni delle macchine virtuali seguono una procedura separata, quindi creare prima uno snapshot della VM.
csrutil disabledi solito non è sufficiente. Apple continua ad applicare la convalida delle librerie aMessages.appin quanto binario della piattaforma, quindi un componente ausiliario con firma ad hoc viene rifiutato (Library Validation failed: ... platform binary, but mapped file is not) anche con SIP disabilitato. Dopo aver disabilitato SIP, disabilitare anche la convalida delle librerie e riavviare:macOS 26 (Tahoe), verificato sulla versione 26.5.1: SIP disabilitato insieme al comandoDisableLibraryValidationriportato sopra è sufficiente per iniettare il componente ausiliario dalle versioni 26.0 alla 26.5.x. Non sono necessari boot-args. Il plist è il fattore determinante e il passaggio mancante più comune quando l’iniezione non riesce su Tahoe:- Con il plist:
imsg launchesegue l’iniezione eimsg statusrestituisceadvanced_features: true. - Senza il plist (anche con SIP disabilitato):
imsg launchnon riesce e restituisceFailed to launch: Timeout waiting for Messages.app to initialize. AMFI rifiuta il componente ausiliario con firma ad hoc durante il caricamento, quindi il bridge non diventa mai pronto e l’avvio scade. Questo timeout è il sintomo riscontrato più spesso su Tahoe; la soluzione è il plist indicato sopra, non interventi più drastici.
imsg launcho specifiche funzionalità diselectorsiniziano a restituire false dopo un aggiornamento di macOS, questo controllo è in genere la causa. Verificare lo stato di SIP e della convalida delle librerie prima di presumere che il passaggio relativo a SIP non sia riuscito. Se tali impostazioni sono corrette e il bridge non riesce comunque a eseguire l’iniezione, raccogliereimsg status --jsoninsieme all’output diimsg launche segnalarlo al progettoimsg, invece di indebolire ulteriori controlli di sicurezza a livello di sistema. - macOS 10.13-10.15 (Sierra-Catalina): disabilitare Library Validation tramite Terminale, riavviare in modalità di recupero, eseguire
-
Iniettare il componente ausiliario. Con SIP disabilitato e l’accesso eseguito in Messages.app:
imsg launchrifiuta di eseguire l’iniezione se SIP è ancora abilitato, quindi questo comando funge anche da conferma dell’esecuzione del passaggio 2. -
Verificare il bridge da OpenClaw:
La voce iMessage dovrebbe restituire
workseimsg status --json | jq '{rpc_methods, selectors}'dovrebbe mostrare le funzionalità esposte dalla build di macOS in uso. La creazione di sondaggi richiedeselectors.pollPayloadMessage; la votazione richiede siaselectors.pollVoteMessagesia il metodo RPCpoll.vote. Il plugin OpenClaw pubblicizza solo le azioni supportate dal probe memorizzato nella cache, mentre con una cache vuota mantiene un comportamento ottimistico ed esegue il probe al primo invio.
openclaw channels status --probe segnala il canale come works, ma azioni specifiche generano “iMessage <action> richiede il bridge API privato imsg” al momento dell’invio, eseguire nuovamente imsg launch: il componente ausiliario può disconnettersi (riavvio di Messages.app, aggiornamento del sistema operativo e così via) e lo stato available: true memorizzato nella cache continuerà a pubblicizzare le azioni finché il probe successivo non lo aggiornerà.
Quando SIP rimane abilitato
Se la disabilitazione di SIP non è accettabile per il proprio modello di minaccia:imsgpassa alla modalità di base: solo testo, contenuti multimediali e ricezione.- Il plugin OpenClaw continua a pubblicizzare l’invio di testo/contenuti multimediali e il monitoraggio in entrata; nasconde
react,edit,unsend,reply,sendWithEffecte le operazioni di gruppo dalla superficie delle azioni, in base al controllo delle funzionalità per ciascun metodo. - È possibile utilizzare un Mac separato non Apple Silicon (o un Mac dedicato al bot) con SIP disabilitato per il carico di lavoro iMessage, mantenendo SIP abilitato sui dispositivi principali. Consultare Utente macOS dedicato al bot (identità iMessage separata) più avanti.
Controllo degli accessi e instradamento
- Criterio per i messaggi diretti
- Criterio dei gruppi + menzioni
- Sessioni e risposte deterministiche
channels.imessage.dmPolicy controlla i messaggi diretti:pairing(impostazione predefinita)allowlist(richiede almeno una voceallowFrom)open(richiede cheallowFromincluda"*")disabled
channels.imessage.allowFrom.Le voci dell’elenco consentiti devono identificare i mittenti: handle o gruppi statici di accesso dei mittenti (accessGroup:<name>). Usare channels.imessage.groupAllowFrom per destinazioni di chat quali chat_id:*, chat_guid:* o chat_identifier:*; usare channels.imessage.groups per chiavi numeriche chat_id del registro.Associazioni delle conversazioni ACP
Le chat iMessage possono essere associate a sessioni ACP. Procedura rapida per l’operatore:- Eseguire
/acp spawn codex --bind hereall’interno del messaggio diretto o della chat di gruppo consentita. - I messaggi successivi nella stessa conversazione iMessage vengono instradati alla sessione ACP avviata.
/newe/resetreimpostano sul posto la stessa sessione ACP associata./acp closechiude la sessione ACP e rimuove l’associazione.
bindings[] di primo livello con type: "acp" e match.channel: "imessage".
match.peer.id può usare:
- un handle normalizzato per messaggi diretti, come
+15555550123ouser@example.com chat_id:<id>(consigliato per associazioni di gruppo stabili)chat_guid:<guid>chat_identifier:<identifier>
Modelli di distribuzione
Utente macOS dedicato al bot (identità iMessage separata)
Utente macOS dedicato al bot (identità iMessage separata)
- Creare/accedere con un utente macOS dedicato.
- Accedere a Messaggi con l’ID Apple del bot in tale account utente.
- Installare
imsgin tale account utente. - Creare un wrapper SSH affinché OpenClaw possa eseguire
imsgnel contesto di tale account utente. - Impostare
channels.imessage.accounts.<id>.cliPathe.dbPathin modo che puntino a tale profilo utente.
Mac remoto tramite Tailscale (esempio)
Mac remoto tramite Tailscale (esempio)
- il gateway viene eseguito su Linux/VM
- iMessage +
imsgvengono eseguiti su un Mac nella propria tailnet - il wrapper
cliPathusa SSH per eseguireimsg remoteHostabilita il recupero degli allegati tramite SCP
ssh bot@mac-mini.tailnet-1234.ts.net), in modo che known_hosts venga popolato.Schema multi-account
Schema multi-account
channels.imessage.accounts.Ogni account può sovrascrivere campi quali cliPath, dbPath, allowFrom, groupPolicy, mediaMaxMb, le impostazioni della cronologia e gli elenchi di autorizzazione delle radici degli allegati.Cronologia dei messaggi diretti
Cronologia dei messaggi diretti
channels.imessage.dmHistoryLimit per inizializzare le nuove sessioni di messaggi diretti con la cronologia recente decodificata di imsg per tale conversazione. Usare channels.imessage.dms["<sender>"].historyLimit per le sostituzioni specifiche per mittente, incluso 0 per disabilitare la cronologia per un mittente.La cronologia dei messaggi diretti di iMessage viene recuperata su richiesta da imsg. Se dmHistoryLimit non è impostato, l’inizializzazione globale della cronologia dei messaggi diretti è disabilitata, ma un valore positivo di channels.imessage.dms["<sender>"].historyLimit specifico per mittente continua ad abilitarla per tale mittente.Contenuti multimediali, suddivisione e destinazioni di consegna
Allegati e contenuti multimediali
Allegati e contenuti multimediali
- l’acquisizione degli allegati in ingresso è disattivata per impostazione predefinita — impostare
channels.imessage.includeAttachments: trueper inoltrare foto, memo vocali, video e altri allegati all’agente. Se è disabilitata, gli iMessage contenenti solo allegati vengono scartati prima di raggiungere l’agente e potrebbero non produrre alcuna riga di logInbound message. - i percorsi degli allegati remoti possono essere recuperati tramite SCP quando è impostato
remoteHost - i percorsi degli allegati devono corrispondere alle radici consentite:
channels.imessage.attachmentRoots(locale)channels.imessage.remoteAttachmentRoots(modalità SCP remota)- le radici configurate estendono lo schema radice predefinito
/Users/*/Library/Messages/Attachments(vengono unite, non sostituite)
- SCP usa la verifica rigorosa della chiave dell’host (
StrictHostKeyChecking=yes) - la dimensione dei contenuti multimediali in uscita usa
channels.imessage.mediaMaxMb(valore predefinito: 16 MB)
Testo in uscita e suddivisione
Testo in uscita e suddivisione
- limite della porzione di testo:
channels.imessage.textChunkLimit(valore predefinito: 4000) - modalità di suddivisione:
channels.imessage.streaming.chunkModelength(valore predefinito)newline(suddivisione a partire dai paragrafi)
- il grassetto/corsivo/sottolineato/barrato Markdown in uscita viene convertito in testo formattato nativo (i destinatari con macOS 15+ visualizzano la formattazione; quelli con versioni precedenti visualizzano testo normale senza i marcatori); le tabelle Markdown vengono convertite in base alla modalità delle tabelle Markdown del canale
channels.imessage.sendTransport(valore predefinitoauto,bridge,applescript) seleziona il modo in cuiimsgeffettua gli invii
Formati di indirizzamento
Formati di indirizzamento
chat_id:123(consigliato per un instradamento stabile)chat_guid:...chat_identifier:...
imessage:+1555...sms:+1555...user@example.com
Azioni dell’API privata
Quandoimsg launch è in esecuzione e openclaw channels status --probe segnala privateApi.available: true, lo strumento per i messaggi può usare azioni native di iMessage oltre ai normali invii di testo.
Tutte le azioni sono abilitate per impostazione predefinita; usare channels.imessage.actions per disabilitarle singolarmente:
Azioni disponibili
Azioni disponibili
- react: aggiunge/rimuove tapback di iMessage (
messageId,emoji,remove). I tapback supportati corrispondono ad amore, mi piace, non mi piace, risata, enfasi e domanda. La rimozione senza emoji elimina qualsiasi tapback impostato. - reply: invia una risposta in thread a un messaggio esistente (
messageId,textomessage, piùchatGuid,chatId,chatIdentifieroto). La risposta con allegato richiede inoltre una build diimsgil cuisend-richsupporti--file. - sendWithEffect: invia testo con un effetto di iMessage (
textomessage,effectoeffectId). Nomi brevi: slam, loud, gentle, invisibleink, confetti, lasers, fireworks, balloon, heart, echo, happybirthday, shootingstar, sparkles, spotlight. - edit: modifica un messaggio inviato nelle versioni supportate di macOS/API privata (
messageId,textonewText). È possibile modificare solo i messaggi inviati dal gateway stesso. - unsend: ritira un messaggio inviato nelle versioni supportate di macOS/API privata (
messageId). È possibile ritirare solo i messaggi inviati dal gateway stesso. - upload-file: invia contenuti multimediali/file (
bufferin formato base64 oppure unmedia/path/filePathcaricato,filename,asVoicefacoltativo). Alias precedente:sendAttachment. - renameGroup, setGroupIcon, addParticipant, removeParticipant, leaveGroup: gestiscono le chat di gruppo quando la destinazione corrente è una conversazione di gruppo. Queste azioni modificano l’identità di Messaggi dell’host, quindi richiedono un mittente proprietario o un client Gateway
operator.admin. - poll: crea un sondaggio nativo di Messaggi di Apple (
pollQuestion,pollOptionripetuto da 2 a 12 volte, piùchatGuid,chatId,chatIdentifieroto). I destinatari con iOS/iPadOS/macOS 26+ possono visualizzarlo e votare in modo nativo; le versioni precedenti del sistema operativo ricevono il testo alternativo “Sondaggio inviato”. Richiedeselectors.pollPayloadMessage. - poll-vote: vota in un sondaggio esistente (
pollIdomessageId, più esattamente uno trapollOptionIndex,pollOptionIdopollOptionText). Richiedeselectors.pollVoteMessagee il metodo RPCpoll.vote.
poll-vote.ID dei messaggi
ID dei messaggi
MessageSid sia GUID completi dei messaggi (MessageSidFull), quando disponibili. Gli ID brevi sono limitati alla cache recente delle risposte basata su SQLite e vengono verificati rispetto alla chat corrente prima dell’uso. Se un ID breve scade, riprovare con il relativo MessageSidFull specificando come destinazione la conversazione che lo ha fornito. Gli ID completi non ignorano l’associazione alla conversazione o all’account, quindi sostituire un ID proveniente da un’altra chat con uno della destinazione corrente. Le chiamate remote delegate possono rifiutare ID completi obsoleti quando non sono disponibili elementi che attestino la conversazione corrente.Rilevamento delle funzionalità
Rilevamento delle funzionalità
imsg launch senza un aggiornamento manuale separato dello stato.Conferme di lettura e indicatore di digitazione
Conferme di lettura e indicatore di digitazione
imsg, antecedenti alla verifica dell’elenco delle funzionalità per metodo, disattivano silenziosamente la digitazione/lettura; OpenClaw registra un avviso una tantum a ogni riavvio, in modo da poter attribuire la conferma mancante.Tapback in ingresso
Tapback in ingresso
channels.imessage.reactionNotifications:"own"(valore predefinito): invia una notifica solo quando gli utenti reagiscono ai messaggi scritti dal bot."all": invia una notifica per tutti i tapback in ingresso provenienti da mittenti autorizzati."off": ignora i tapback in ingresso.
channels.imessage.accounts.<id>.reactionNotifications.Reazioni di approvazione (👍 / 👎)
Reazioni di approvazione (👍 / 👎)
approvals.exec.enabled o approvals.plugin.enabled è impostato su true e la richiesta viene instradata a iMessage, il gateway consegna una richiesta di approvazione in modo nativo e accetta un tapback per risolverla:👍(tapback Mi piace) →allow-once👎(tapback Non mi piace) →denyallow-alwaysrimane un’alternativa manuale: inviare/approve <id> allow-alwayscome risposta normale.
channels.imessage.allowFrom (o channels.imessage.accounts.<id>.allowFrom); aggiungere il numero di telefono dell’utente in formato E.164 o il relativo indirizzo email dell’ID Apple (le destinazioni chat come chat_id:* non sono voci valide per gli approvatori). La voce jolly "*" viene rispettata, ma consente a qualsiasi mittente di approvare; un elenco di approvatori vuoto disabilita completamente la scorciatoia tramite reazione. La scorciatoia tramite reazione ignora intenzionalmente reactionNotifications, dmPolicy e groupAllowFrom, poiché l’elenco di autorizzazione degli approvatori espliciti è l’unico controllo rilevante per la risoluzione dell’approvazione.L’autorizzazione del comando testuale /approve segue lo stesso elenco: quando channels.imessage.allowFrom non è vuoto, /approve <id> <decision> viene autorizzato in base a tale elenco di approvatori (non al più ampio elenco di autorizzazione dei messaggi diretti) e i mittenti consentiti dall’elenco dei messaggi diretti ma non inclusi in allowFrom ricevono un rifiuto esplicito. Quando allowFrom è vuoto, rimane attiva l’alternativa della stessa chat e /approve autorizza chiunque sia consentito dall’elenco di autorizzazione dei messaggi diretti. Aggiungere ogni operatore che deve poter approvare, tramite /approve o tramite reazioni, a allowFrom.Note per l’operatore:- L’associazione della reazione viene memorizzata sia in memoria sia nell’archivio persistente con chiavi del Gateway (con TTL corrispondente alla scadenza dell’approvazione); inoltre, il Gateway interroga periodicamente le richieste in sospeso per rilevare i tapback, pertanto un tapback ricevuto poco dopo il riavvio del Gateway risolve comunque l’approvazione.
- Il tapback
is_from_me=truedell’operatore stesso (ad esempio da un dispositivo Apple abbinato) risolve l’approvazione quando tale identificativo è configurato esplicitamente come approvatore. - Le richieste di approvazione vengono instradate in una conversazione di gruppo solo quando sono configurati approvatori espliciti; altrimenti qualsiasi membro del gruppo potrebbe approvare.
- I tapback legacy in formato testuale (
Liked "…"testo normale proveniente da client Apple molto datati) non possono risolvere le approvazioni perché non contengono alcun GUID del messaggio; la risoluzione tramite reazione richiede i metadati strutturati del tapback emessi dagli attuali client macOS/iOS.
Scritture della configurazione
Per impostazione predefinita, iMessage consente scritture della configurazione avviate dal canale (per/config set|unset quando commands.config: true).
Per disabilitarle:
Aggregazione dei DM con invio suddiviso (comando + URL in un’unica composizione)
Quando un utente digita insieme un comando e un URL, ad esempioDump https://example.com/article, l’app Messaggi di Apple suddivide l’invio in due righe chat.db distinte:
- Un messaggio di testo (
"Dump"). - Un fumetto di anteprima dell’URL (
"https://...") con le immagini dell’anteprima OG come allegati.
imsg.
channels.imessage.coalesceSameSenderDms abilita per un DM il buffering delle righe consecutive dello stesso mittente. Quando imsg espone il marcatore strutturale dell’anteprima URL balloon_bundle_id: "com.apple.messages.URLBalloonProvider" in una delle righe di origine, OpenClaw unisce soltanto quell’effettivo invio suddiviso e mantiene tutte le altre righe nel buffer come turni distinti. Nelle build imsg meno recenti, che non emettono alcun metadato del fumetto, OpenClaw non può distinguere un invio suddiviso da invii separati, quindi ripiega sull’unione del gruppo. In questo modo viene mantenuto il comportamento precedente all’introduzione dei metadati, anziché trasformare gli invii suddivisi Dump <url> in due turni. Le chat di gruppo continuano a distribuire ogni messaggio separatamente, preservando la struttura dei turni tra più utenti.
- Quando abilitarla
- Abilitazione
- Compromessi
- Si distribuiscono Skills che prevedono
command + payloadin un unico messaggio (dump, incolla, salva, accoda e così via). - Gli utenti incollano URL insieme ai comandi.
- È accettabile la latenza aggiuntiva dei turni nei DM (vedere sotto).
- È necessaria la latenza minima dei comandi per gli attivatori DM costituiti da una sola parola.
- Tutti i flussi sono comandi singoli senza payload successivi.
Scenari e contenuto ricevuto dall’agente
La colonna «Flag attivo» mostra il comportamento su una buildimsg che emette balloon_bundle_id. Nelle build imsg meno recenti che non emettono alcun metadato del fumetto, le righe indicate di seguito come «Due turni»/«N turni» ricadono invece in un’unione legacy (un solo turno): OpenClaw non può distinguere strutturalmente un invio suddiviso da invii separati, quindi mantiene l’unione precedente all’introduzione dei metadati. La separazione precisa si attiva quando la build emette i metadati del fumetto.
Ripristino dei messaggi in ingresso dopo il riavvio di un bridge o del Gateway
iMessage recupera i messaggi persi mentre il Gateway era inattivo e, allo stesso tempo, elimina la vecchia «raffica di arretrati» che Apple può riversare dopo un ripristino Push. Il comportamento predefinito è sempre attivo e si basa sulla deduplicazione dei messaggi in ingresso.- Deduplicazione della riproduzione. Ogni messaggio in ingresso distribuito viene registrato tramite il relativo GUID Apple nello stato persistente del Plugin (
imessage.inbound-dedupe), acquisito durante l’ingestione e confermato dopo la gestione (rilasciato in caso di errore transitorio, affinché possa essere riprovato). Tutto ciò che è già stato gestito viene eliminato anziché essere distribuito due volte. Questo consente al ripristino di riprodurre in modo aggressivo senza una contabilità per singolo messaggio. - Ripristino dopo l’inattività. All’avvio, il monitor memorizza l’ultimo rowid
chat.dbdistribuito (un cursore persistente per account) e lo passa aimsg watch.subscribecomesince_rowid, affinché imsg riproduca le righe arrivate mentre il Gateway era inattivo e poi prosegua con quelle in tempo reale. La riproduzione è limitata alle 500 righe più recenti e ai messaggi risalenti al massimo a circa 2 ore prima; la deduplicazione elimina tutto ciò che è già stato gestito. - Limite temporale per gli arretrati obsoleti. Le righe oltre il limite di avvio sono effettivamente in tempo reale; una riga la cui data di invio precede di oltre circa 15 minuti quella di arrivo appartiene agli arretrati riversati da Push e viene eliminata. Le righe riprodotte (in corrispondenza o al di sotto del limite) utilizzano invece la finestra di ripristino più ampia, così un messaggio perso di recente viene consegnato, mentre la cronologia remota non lo è.
cliPath locali sia con quelle remote, perché la riproduzione since_rowid viene eseguita tramite la stessa connessione RPC imsg. La differenza risiede nella finestra: quando il Gateway può leggere chat.db (in locale), fissa il limite del rowid di avvio, limita l’intervallo di riproduzione e consegna i messaggi persi risalenti al massimo a un paio d’ore prima. Tramite una connessione SSH cliPath remota, non può leggere il database, quindi la riproduzione non è limitata e ogni riga utilizza il limite temporale in tempo reale: recupera comunque i messaggi persi di recente ed elimina comunque gli arretrati obsoleti, ma con la finestra in tempo reale più ristretta. Per usufruire della finestra di ripristino più ampia, eseguire il Gateway sul Mac che ospita Messaggi.
Segnale visibile all’operatore
Gli arretrati eliminati vengono registrati al livello predefinito e non vengono mai ignorati silenziosamente (il flagrecovery indica quale finestra è stata applicata):
Migrazione
channels.imessage.catchup.* è deprecato: il ripristino dopo l’inattività è automatico e non richiede alcuna configurazione per le nuove installazioni. Le configurazioni esistenti con catchup.enabled: true continuano a essere rispettate come profilo di compatibilità per la finestra di riproduzione del ripristino. I blocchi di recupero disabilitati (enabled: false o senza enabled: true) sono stati ritirati; openclaw doctor --fix li rimuove.
Risoluzione dei problemi
imsg non trovato o RPC non supportato
imsg non trovato o RPC non supportato
imsg. Se le azioni dell’API privata non sono disponibili, eseguire imsg launch nella sessione dell’utente macOS connesso ed effettuare nuovamente il sondaggio. Se il Gateway non è in esecuzione su macOS, utilizzare la configurazione Mac remoto tramite SSH descritta sopra anziché il percorso locale predefinito imsg.I messaggi vengono inviati, ma gli iMessage in ingresso non arrivano
I messaggi vengono inviati, ma gli iMessage in ingresso non arrivano
chat.db non cambia, OpenClaw non può ricevere il messaggio anche quando imsg status --json segnala un bridge integro.chat.db o di un evento imsg watch prima di eseguire il debug delle sessioni OpenClaw. Non eseguire questa operazione come ciclo periodico di riavvio del bridge; ripetuti imsg launch insieme a riavvii del Gateway durante attività in corso possono interrompere le consegne e lasciare bloccate le esecuzioni del canale in corso.Il Gateway non è in esecuzione su macOS
Il Gateway non è in esecuzione su macOS
cliPath: "imsg" deve essere eseguito sul Mac connesso a Messaggi. Su Linux o Windows, impostare channels.imessage.cliPath su uno script wrapper che si connetta tramite SSH a quel Mac ed esegua imsg "$@".I messaggi diretti vengono ignorati
I messaggi diretti vengono ignorati
channels.imessage.dmPolicychannels.imessage.allowFrom- approvazioni dell’associazione (
openclaw pairing list imessage)
I messaggi di gruppo vengono ignorati
I messaggi di gruppo vengono ignorati
channels.imessage.groupPolicychannels.imessage.groupAllowFromchannels.imessage.groupscomportamento dell’elenco consentiti- configurazione del modello di menzione (
agents.list[].groupChat.mentionPatterns)
Gli allegati remoti non funzionano
Gli allegati remoti non funzionano
channels.imessage.remoteHostchannels.imessage.remoteAttachmentRoots- autenticazione con chiave SSH/SCP dall’host del Gateway
- la chiave dell’host esiste in
~/.ssh/known_hostssull’host del Gateway - il percorso remoto è leggibile sul Mac che esegue Messaggi
Le richieste di autorizzazione di macOS non sono state confermate
Le richieste di autorizzazione di macOS non sono state confermate
imsg.Riferimenti per la configurazione
Contenuti correlati
- Panoramica dei canali — tutti i canali supportati
- Rimozione di BlueBubbles e percorso iMessage con imsg — annuncio e riepilogo della migrazione
- Migrazione da BlueBubbles — tabella di conversione della configurazione e passaggio graduale
- Associazione — autenticazione dei messaggi diretti e flusso di associazione
- Gruppi — comportamento delle chat di gruppo e controllo tramite menzione
- Instradamento dei canali — instradamento delle sessioni per i messaggi
- Sicurezza — modello di accesso e rafforzamento della sicurezza