imsg en un host de Mensajes de macOS con sesión iniciada. Si tu Gateway se ejecuta en Linux o Windows, apunta channels.imessage.cliPath a un contenedor SSH que ejecute imsg en el Mac.La recuperación entrante es automática. Después de reiniciar un puente o gateway, iMessage reproduce los mensajes perdidos mientras estaba inactivo y suprime la “bomba de backlog” obsoleta que Apple puede volcar tras una recuperación Push, deduplicando para que nada se despache dos veces. No hay configuración que habilitar; consulta Recuperación entrante después de reiniciar un puente o gateway.imsg rpc y habla JSON-RPC por stdio, sin daemon ni puerto separados. Las acciones avanzadas requieren imsg launch y una comprobación correcta de API privada.
Acciones de API privada
Emparejamiento
Mac remoto
Referencia de configuración
Configuración rápida
- Mac local (ruta rápida)
- Mac remoto por SSH
Requisitos y permisos (macOS)
- Mensajes debe tener la sesión iniciada en el Mac que ejecuta
imsg. - Se requiere Acceso total al disco para el contexto de proceso que ejecuta OpenClaw/
imsg(acceso a la base de datos de Mensajes). - Se requiere permiso de Automatización para enviar mensajes a través de Messages.app.
- Para acciones avanzadas (reaccionar / editar / anular envío / respuesta en hilo / efectos / encuestas / operaciones de grupo), System Integrity Protection debe estar desactivado; consulta Habilitar la API privada de imsg. El envío y la recepción básicos de texto y medios funcionan sin ello.
Los envíos del contenedor SSH fallan con AppleEvents -1743
Los envíos del contenedor SSH fallan con AppleEvents -1743
channels status --probe y procesar mensajes entrantes mientras los envíos salientes siguen fallando con un error de autorización de AppleEvents:/usr/libexec/sshd-keygen-wrapper en lugar del proceso imsg o shell local, es posible que macOS no exponga un conmutador de Mensajes usable para ese cliente del lado del servidor SSH:tccutil reset AppleEvents o volver a ejecutar imsg send mediante el mismo contenedor SSH puede seguir fallando porque el contexto de proceso que necesita Automatización de Mensajes es el contenedor SSH, no una app a la que la UI pueda concederlo.Usa en su lugar uno de los contextos de proceso de imsg compatibles:- Ejecuta el Gateway, o al menos el puente
imsg, en la sesión local del usuario de Mensajes con sesión iniciada. - Inicia el Gateway con un LaunchAgent para ese usuario después de conceder Acceso total al disco y Automatización desde la misma sesión.
- Si mantienes la topología SSH de dos usuarios, verifica que un
imsg sendsaliente real funcione mediante el contenedor exacto antes de habilitar el canal. Si no se le puede conceder Automatización, reconfigura a una configuraciónimsgde un solo usuario en lugar de depender del contenedor SSH para los envíos.
Habilitar la API privada de imsg
imsg se distribuye en dos modos operativos:
- Modo básico (predeterminado, no requiere cambios en SIP): texto y medios salientes mediante
send, vigilancia/historial entrante, lista de chats. Esto es lo que obtienes de inmediato con una instalación nueva debrew install steipete/tap/imsgmás los permisos estándar de macOS anteriores. - Modo de API privada:
imsginyecta una dylib auxiliar enMessages.apppara llamar a funciones internas deIMCore. Esto habilitareact,edit,unsend,reply(en hilo),sendWithEffect,pollypoll-vote(encuestas nativas de Mensajes),renameGroup,setGroupIcon,addParticipant,removeParticipant,leaveGroup, además de indicadores de escritura y confirmaciones de lectura.
imsg es explícito sobre el requisito:
Las funciones avanzadas comoLa técnica de inyección de auxiliar usa la propia dylib deread,typing,launch, envío enriquecido respaldado por puente, mutación de mensajes y gestión de chats son optativas. Requieren que SIP esté desactivado y que se inyecte una dylib auxiliar enMessages.app.imsg launchse niega a inyectar cuando SIP está activado.
imsg para llegar a las API privadas de Mensajes. No hay servidor de terceros ni runtime de BlueBubbles en la ruta OpenClaw iMessage.
Configuración
-
Instala (o actualiza)
imsgen el Mac que ejecuta Messages.app:La salida deimsg status --jsoninforma debridge_version,rpc_methodsyselectorspor método para que puedas ver qué admite la compilación actual antes de empezar. -
Desactiva System Integrity Protection y (en macOS moderno) Library Validation. Inyectar una dylib auxiliar no Apple en la
Messages.appfirmada por Apple requiere SIP desactivado y validación de bibliotecas relajada. El paso de SIP en modo Recuperación es específico de la versión de macOS:- macOS 10.13-10.15 (Sierra-Catalina): desactiva Library Validation mediante Terminal, reinicia en modo Recuperación, ejecuta
csrutil disable, reinicia. - macOS 11+ (Big Sur y posterior), Intel: modo Recuperación (o Recuperación por Internet),
csrutil disable, reinicia. - macOS 11+, Apple Silicon: secuencia de inicio con botón de encendido para entrar en Recuperación; en versiones recientes de macOS, mantén pulsada la tecla Mayús izquierda al hacer clic en Continuar y luego
csrutil disable. Las configuraciones de máquina virtual siguen un flujo separado, así que toma primero una instantánea de la VM.
csrutil disablepor sí solo normalmente no basta. Apple sigue imponiendo la validación de bibliotecas contraMessages.appcomo binario de plataforma, por lo que se rechaza un auxiliar firmado ad hoc (Library Validation failed: ... platform binary, but mapped file is not) incluso con SIP desactivado. Después de desactivar SIP, desactiva también la validación de bibliotecas y reinicia:macOS 26 (Tahoe), verificado en 26.5.1: SIP desactivado más el comandoDisableLibraryValidationanterior basta para inyectar el auxiliar desde 26.0 hasta 26.5.x. No se requieren boot-args. El plist es el factor decisivo y el paso que falta con más frecuencia cuando la inyección falla en Tahoe:- Con el plist:
imsg launchinyecta yimsg statusinformaadvanced_features: true. - Sin el plist (incluso con SIP desactivado):
imsg launchfalla conFailed to launch: Timeout waiting for Messages.app to initialize. AMFI rechaza el auxiliar ad hoc al cargarlo, por lo que el puente nunca queda listo y el lanzamiento agota el tiempo de espera. Ese tiempo de espera es el síntoma más común en Tahoe; la solución es el plist anterior, no nada más drástico.
imsg launchoselectorsespecíficos empiezan a devolver false después de una actualización de macOS, esta barrera suele ser la causa. Comprueba el estado de SIP y de validación de bibliotecas antes de asumir que el propio paso de SIP falló. Si esos ajustes son correctos y el puente aún no puede inyectarse, recopilaimsg status --jsonjunto con la salida deimsg launchy repórtalo al proyectoimsgen lugar de debilitar controles de seguridad adicionales en todo el sistema. - macOS 10.13-10.15 (Sierra-Catalina): desactiva Library Validation mediante Terminal, reinicia en modo Recuperación, ejecuta
-
Inyecta el asistente. Con SIP desactivado y Messages.app con la sesión iniciada:
imsg launchse niega a inyectar cuando SIP sigue activado, por lo que esto también sirve como confirmación de que el paso 2 surtió efecto. -
Verifica el puente desde OpenClaw:
La entrada de iMessage debería informar
works, yimsg status --json | jq '{rpc_methods, selectors}'debería mostrar las capacidades expuestas por tu compilación de macOS. La creación de encuestas requiereselectors.pollPayloadMessage; votar requiere tantoselectors.pollVoteMessagecomo el método RPCpoll.vote. El Plugin de OpenClaw anuncia solo las acciones admitidas por la prueba almacenada en caché, mientras que una caché vacía se mantiene optimista y prueba en el primer envío.
openclaw channels status --probe informa que el canal está en works, pero acciones específicas lanzan “iMessage <action> requires the imsg private API bridge” en el momento del envío, ejecuta imsg launch de nuevo: el asistente puede desconectarse (reinicio de Messages.app, actualización del SO, etc.) y el estado available: true almacenado en caché seguirá anunciando acciones hasta que la próxima prueba lo actualice.
Cuando SIP permanece activado
Si desactivar SIP no es aceptable para tu modelo de amenazas:imsgvuelve al modo básico: solo texto + medios + recepción.- El Plugin de OpenClaw sigue anunciando envío de texto/medios y supervisión entrante; oculta
react,edit,unsend,reply,sendWithEffecty las operaciones de grupo de la superficie de acciones (según la puerta de capacidad por método). - Puedes ejecutar un Mac independiente que no sea Apple Silicon (o un Mac dedicado para bot) con SIP desactivado para la carga de trabajo de iMessage, mientras mantienes SIP activado en tus dispositivos principales. Consulta Usuario macOS dedicado para bot (identidad de iMessage separada) a continuación.
Control de acceso y enrutamiento
- Política de MD
- Política de grupo + menciones
- Sesiones y respuestas deterministas
channels.imessage.dmPolicy controla los mensajes directos:pairing(predeterminado)allowlist(requiere al menos una entradaallowFrom)open(requiere queallowFromincluya"*")disabled
channels.imessage.allowFrom.Las entradas de la lista de permitidos deben identificar remitentes: identificadores o grupos estáticos de acceso de remitente (accessGroup:<name>). Usa channels.imessage.groupAllowFrom para destinos de chat como chat_id:*, chat_guid:* o chat_identifier:*; usa channels.imessage.groups para claves de registro numéricas chat_id.Vinculaciones de conversaciones ACP
Los chats de iMessage pueden vincularse a sesiones ACP. Flujo rápido para operador:- Ejecuta
/acp spawn codex --bind heredentro del MD o chat de grupo permitido. - Los mensajes futuros en esa misma conversación de iMessage se enrutan a la sesión ACP generada.
/newy/resetrestablecen la misma sesión ACP vinculada en el lugar./acp closecierra la sesión ACP y elimina la vinculación.
bindings[] de nivel superior con type: "acp" y match.channel: "imessage".
match.peer.id puede usar:
- identificador de MD normalizado como
+15555550123ouser@example.com chat_id:<id>(recomendado para vinculaciones de grupo estables)chat_guid:<guid>chat_identifier:<identifier>
Patrones de despliegue
Usuario macOS dedicado para bot (identidad de iMessage separada)
Usuario macOS dedicado para bot (identidad de iMessage separada)
- Crea/inicia sesión con un usuario de macOS dedicado.
- Inicia sesión en Messages con el Apple ID del bot en ese usuario.
- Instala
imsgen ese usuario. - Crea un contenedor SSH para que OpenClaw pueda ejecutar
imsgen el contexto de ese usuario. - Apunta
channels.imessage.accounts.<id>.cliPathy.dbPatha ese perfil de usuario.
Mac remoto mediante Tailscale (ejemplo)
Mac remoto mediante Tailscale (ejemplo)
- Gateway se ejecuta en Linux/VM
- iMessage +
imsgse ejecuta en un Mac de tu tailnet - el contenedor
cliPathusa SSH para ejecutarimsg remoteHosthabilita recuperaciones de adjuntos por SCP
ssh bot@mac-mini.tailnet-1234.ts.net) para que known_hosts quede poblado.Patrón multicuenta
Patrón multicuenta
channels.imessage.accounts.Cada cuenta puede sobrescribir campos como cliPath, dbPath, allowFrom, groupPolicy, mediaMaxMb, opciones de historial y listas de permitidos de raíz de adjuntos.Historial de mensajes directos
Historial de mensajes directos
channels.imessage.dmHistoryLimit para inicializar nuevas sesiones de mensajes directos con historial reciente decodificado de imsg para esa conversación. Usa channels.imessage.dms["<sender>"].historyLimit para sobrescrituras por remitente, incluido 0 para desactivar el historial para un remitente.El historial de MD de iMessage se recupera bajo demanda desde imsg. Dejar dmHistoryLimit sin definir desactiva la inicialización global de historial de MD, pero un channels.imessage.dms["<sender>"].historyLimit positivo por remitente sigue habilitando la inicialización para ese remitente.Medios, fragmentación y destinos de entrega
Archivos adjuntos y medios
Archivos adjuntos y medios
- la ingesta de archivos adjuntos entrantes está desactivada de forma predeterminada — establece
channels.imessage.includeAttachments: truepara reenviar fotos, notas de voz, video y otros archivos adjuntos al agente. Con esta opción desactivada, los iMessages que solo contienen adjuntos se descartan antes de llegar al agente y puede que no produzcan ninguna línea de registroInbound message. - las rutas de archivos adjuntos remotos pueden obtenerse mediante SCP cuando
remoteHostestá establecido - las rutas de archivos adjuntos deben coincidir con raíces permitidas:
channels.imessage.attachmentRoots(local)channels.imessage.remoteAttachmentRoots(modo SCP remoto)- las raíces configuradas amplían el patrón de raíz predeterminado
/Users/*/Library/Messages/Attachments(se fusionan, no se reemplazan)
- SCP usa comprobación estricta de clave de host (
StrictHostKeyChecking=yes) - el tamaño de medios salientes usa
channels.imessage.mediaMaxMb(predeterminado 16 MB)
Texto saliente y fragmentación
Texto saliente y fragmentación
- límite de fragmento de texto:
channels.imessage.textChunkLimit(predeterminado 4000) - modo de fragmentación:
channels.imessage.chunkModelength(predeterminado)newline(división priorizando párrafos)
- la negrita, cursiva, subrayado y tachado de Markdown salientes se convierten en texto con estilo nativo (los destinatarios en macOS 15+ muestran el estilo; los destinatarios más antiguos ven texto sin formato sin los marcadores); las tablas de Markdown se convierten según el modo de tablas Markdown del canal
channels.imessage.sendTransport(autopredeterminado,bridge,applescript) selecciona cómoimsgentrega los envíos
Formatos de direccionamiento
Formatos de direccionamiento
chat_id:123(recomendado para enrutamiento estable)chat_guid:...chat_identifier:...
imessage:+1555...sms:+1555...user@example.com
Acciones de API privada
Cuandoimsg launch está en ejecución y openclaw channels status --probe informa privateApi.available: true, la herramienta de mensajes puede usar acciones nativas de iMessage además de los envíos de texto normales.
Todas las acciones están activadas de forma predeterminada; usa channels.imessage.actions para desactivar acciones individuales:
Acciones disponibles
Acciones disponibles
- react: Añade/elimina tapbacks de iMessage (
messageId,emoji,remove). Los tapbacks admitidos se asignan a me encanta, me gusta, no me gusta, risa, énfasis y pregunta. Eliminar sin un emoji borra cualquier tapback que se haya establecido. - reply: Envía una respuesta en hilo a un mensaje existente (
messageId,textomessage, máschatGuid,chatId,chatIdentifieroto). Responder con adjunto además necesita una compilación deimsgcuyosend-richadmita--file. - sendWithEffect: Envía texto con un efecto de iMessage (
textomessage,effectoeffectId). Nombres cortos: slam, loud, gentle, invisibleink, confetti, lasers, fireworks, balloon, heart, echo, happybirthday, shootingstar, sparkles, spotlight. - edit: Edita un mensaje enviado en versiones compatibles de macOS/API privada (
messageId,textonewText). Solo se pueden editar los mensajes que el propio Gateway envió. - unsend: Retira un mensaje enviado en versiones compatibles de macOS/API privada (
messageId). Solo se pueden anular los mensajes que el propio Gateway envió. - upload-file: Envía medios/archivos (
buffercomo base64 o unmedia/path/filePathhidratado,filename,asVoiceopcional). Alias heredado:sendAttachment. - renameGroup, setGroupIcon, addParticipant, removeParticipant, leaveGroup: Gestiona chats grupales cuando el destino actual es una conversación grupal. Estas acciones modifican la identidad de Mensajes del host, por lo que requieren un remitente propietario o un cliente de Gateway
operator.admin. - poll: Crea una encuesta nativa de Apple Messages (
pollQuestion,pollOptionrepetido de 2 a 12 veces, máschatGuid,chatId,chatIdentifieroto). Los destinatarios en iOS/iPadOS/macOS 26+ la ven y votan de forma nativa; las versiones anteriores del sistema operativo reciben una alternativa de texto “Se envió una encuesta”. Requiereselectors.pollPayloadMessage. - poll-vote: Vota en una encuesta existente (
pollIdomessageId, más exactamente uno depollOptionIndex,pollOptionIdopollOptionText). Requiereselectors.pollVoteMessagey el método RPCpoll.vote.
poll-vote.ID de mensajes
ID de mensajes
MessageSid cortos como GUIDs de mensaje completos (MessageSidFull) cuando están disponibles. Los ID cortos están limitados a la caché reciente de respuestas respaldada por SQLite y se comprueban contra el chat actual antes de usarse. Si un ID corto expiró o pertenece a otro chat, reintenta con el MessageSidFull completo.Detección de capacidades
Detección de capacidades
imsg launch sin una actualización manual de estado aparte.Confirmaciones de lectura e indicador de escritura
Confirmaciones de lectura e indicador de escritura
imsg que son anteriores a la lista de capacidades por método desactivan silenciosamente escritura/lectura; OpenClaw registra una advertencia una sola vez por reinicio para que la confirmación faltante sea atribuible.Tapbacks entrantes
Tapbacks entrantes
channels.imessage.reactionNotifications:"own"(predeterminado): notificar solo cuando los usuarios reaccionen a mensajes escritos por el bot."all": notificar todos los tapbacks entrantes de remitentes autorizados."off": ignorar tapbacks entrantes.
channels.imessage.accounts.<id>.reactionNotifications.Reacciones de aprobación (👍 / 👎)
Reacciones de aprobación (👍 / 👎)
approvals.exec.enabled o approvals.plugin.enabled es true y la solicitud se enruta a iMessage, el Gateway entrega una solicitud de aprobación de forma nativa y acepta un tapback para resolverla:👍(tapback Me gusta) →allow-once👎(tapback No me gusta) →denyallow-alwayssigue siendo una alternativa manual: envía/approve <id> allow-alwayscomo respuesta normal.
channels.imessage.allowFrom (o channels.imessage.accounts.<id>.allowFrom); añade el número de teléfono del usuario en formato E.164 o su correo de Apple ID (los destinos de chat como chat_id:* no son entradas de aprobador válidas). La entrada comodín "*" se respeta, pero permite aprobar a cualquier remitente; una lista de aprobadores vacía desactiva por completo el atajo de reacción. El atajo de reacción omite intencionalmente reactionNotifications, dmPolicy y groupAllowFrom porque la lista de permitidos de aprobadores explícitos es la única puerta que importa para resolver aprobaciones.La autorización del comando de texto /approve sigue la misma lista: cuando channels.imessage.allowFrom no está vacía, /approve <id> <decision> se autoriza contra esa lista de aprobadores (no contra la lista más amplia de permitidos para DM), y los remitentes permitidos en la lista de DM pero no en allowFrom reciben una denegación explícita. Cuando allowFrom está vacía, la alternativa de mismo chat permanece vigente y /approve autoriza a cualquiera que permita la lista de DM. Añade a allowFrom todos los operadores que deban aprobar, mediante /approve o mediante reacciones.Notas para operadores:- El enlace de reacción se almacena tanto en memoria como en el almacén persistente con claves del Gateway (TTL igual al vencimiento de la aprobación), y el Gateway también sondea las solicitudes pendientes en busca de tapbacks, por lo que un tapback que llega poco después de reiniciar el Gateway todavía resuelve la aprobación.
- El tapback propio del operador con
is_from_me=true(por ejemplo, desde un dispositivo Apple emparejado) resuelve la aprobación cuando ese identificador es un aprobador explícito. - Las solicitudes de aprobación se enrutan a una conversación grupal solo cuando hay aprobadores explícitos configurados; de lo contrario, cualquier miembro del grupo podría aprobar.
- Los tapbacks heredados con estilo de texto (
Liked "…"como texto sin formato desde clientes Apple muy antiguos) no pueden resolver aprobaciones porque no llevan GUID de mensaje; la resolución de reacciones requiere los metadatos estructurados de tapback que emiten los clientes actuales de macOS / iOS.
Escrituras de configuración
iMessage permite de forma predeterminada escrituras de configuración iniciadas por el canal (para/config set|unset cuando commands.config: true).
Desactivar:
Fusionar DM de envío dividido (comando + URL en una composición)
Cuando un usuario escribe juntos un comando y una URL — por ejemplo,Dump https://example.com/article — la app Mensajes de Apple divide el envío en dos filas chat.db separadas:
- Un mensaje de texto (
"Dump"). - Un globo de vista previa de URL (
"https://...") con imágenes de vista previa OG como adjuntos.
imsg.
channels.imessage.coalesceSameSenderDms opta un DM en el almacenamiento en búfer de filas consecutivas del mismo remitente. Cuando imsg expone el marcador estructural de vista previa de URL balloon_bundle_id: "com.apple.messages.URLBalloonProvider" en una de las filas de origen, OpenClaw fusiona solo ese envío dividido real y mantiene cualquier otra fila almacenada en búfer como turnos separados. En compilaciones antiguas de imsg que no emiten metadatos de globo en absoluto, OpenClaw no puede distinguir un envío dividido de envíos separados, por lo que recurre a fusionar el grupo. Eso preserva el comportamiento anterior a los metadatos en lugar de hacer que los envíos divididos Dump <url> regresen a dos turnos. Los chats grupales siguen despachándose por mensaje para preservar la estructura de turnos multiusuario.
- Cuándo activar
- Activación
- Compensaciones
- Distribuyas Skills que esperan
command + payloaden un solo mensaje (dump, paste, save, queue, etc.). - Tus usuarios peguen URLs junto con comandos.
- Puedas aceptar la latencia adicional del turno de DM (consulta abajo).
- Necesites latencia mínima de comandos para disparadores de DM de una sola palabra.
- Todos tus flujos sean comandos de una sola ejecución sin seguimientos de carga útil.
Escenarios y lo que ve el agente
La columna “Marca activada” muestra el comportamiento en una compilación deimsg que emite balloon_bundle_id. En compilaciones antiguas de imsg que no emiten metadatos de globo en absoluto, las filas siguientes marcadas como “Dos turnos” / “N turnos” recurren en su lugar a una fusión heredada (un turno): OpenClaw no puede distinguir estructuralmente un envío dividido de envíos separados, por lo que conserva la fusión previa a los metadatos. La separación precisa se activa una vez que la compilación emite metadatos de globo.
| El usuario redacta | chat.db produce | Marca desactivada (predeterminado) | Marca activada + ventana (imsg emite metadatos de globo) |
|---|---|---|---|
Dump https://example.com (un envío) | 2 filas con ~1 s de diferencia | Dos turnos del agente: “Dump” solo, luego URL | Un turno: texto fusionado Dump https://example.com |
Save this 📎image.jpg caption (archivo adjunto + texto) | 2 filas sin metadatos de globo de URL | Dos turnos | Dos turnos después de observar metadatos; un turno fusionado en sesiones antiguas/previas al latch sin metadatos |
/status (comando independiente) | 1 fila | Despacho instantáneo | Espera hasta la ventana y luego despacha |
| URL pegada sola | 1 fila | Despacho instantáneo | Espera hasta la ventana y luego despacha |
| Texto + URL enviados como dos mensajes separados deliberados, minutos aparte | 2 filas fuera de la ventana | Dos turnos | Dos turnos (la ventana expira entre ellos) |
| Inundación rápida (>10 DM pequeños dentro de la ventana) | N filas sin metadatos de globo de URL | N turnos | N turnos después de observar metadatos; un turno fusionado acotado en sesiones antiguas/previas al latch sin metadatos |
| Dos personas escribiendo en un chat grupal | N filas de M remitentes | M+ turnos (uno por bucket de remitente) | M+ turnos — los chats grupales no se fusionan |
Recuperación de entrada después de reiniciar un puente o Gateway
iMessage recupera los mensajes perdidos mientras el Gateway estaba inactivo y, al mismo tiempo, suprime la antigua “bomba de backlog” que Apple puede descargar después de una recuperación Push. El comportamiento predeterminado está siempre activado y se basa en la deduplicación de entrada.- Deduplicación de reproducción. Cada mensaje entrante despachado se registra por su GUID de Apple en el estado persistente del Plugin (
imessage.inbound-dedupe), se reclama durante la ingesta y se confirma después de manejarlo (se libera ante un fallo transitorio para que pueda reintentarse). Todo lo ya manejado se descarta en lugar de despacharse dos veces. Esto permite que la recuperación reproduzca de forma agresiva sin contabilidad por mensaje. - Recuperación de tiempo de inactividad. Al iniciar, el monitor recuerda el último
chat.dbrowid despachado (un cursor persistido por cuenta) y lo pasa aimsg watch.subscribecomosince_rowid, de modo que imsg reproduce las filas que llegaron mientras el Gateway estaba inactivo y luego sigue en vivo. La reproducción se limita a las 500 filas más recientes y a mensajes de hasta ~2 horas de antigüedad, y la deduplicación descarta todo lo ya manejado. - Valla de antigüedad para backlog obsoleto. Las filas por encima del límite de inicio son realmente en vivo; una cuya fecha de envío sea más de ~15 minutos anterior a su llegada es backlog de descarga Push y se suprime. Las filas reproducidas (en el límite o por debajo) usan en cambio la ventana de recuperación más amplia, de modo que se entrega un mensaje perdido recientemente mientras que el historial antiguo no.
cliPath locales como remotas, porque la reproducción since_rowid se ejecuta sobre la misma conexión RPC de imsg. La diferencia es la ventana: cuando el Gateway puede leer chat.db (local), ancla el límite rowid de inicio, limita el intervalo de reproducción y entrega mensajes perdidos de hasta un par de horas de antigüedad. Con un cliPath SSH remoto no puede leer la base de datos, por lo que la reproducción no tiene límite y cada fila usa la valla de antigüedad en vivo: aun así recupera mensajes perdidos recientemente y sigue suprimiendo backlog antiguo, solo que con la ventana en vivo más estrecha. Ejecuta el Gateway en la Mac de Messages para obtener la ventana de recuperación más amplia.
Señal visible para el operador
El backlog suprimido se registra en el nivel predeterminado, nunca se descarta silenciosamente (la marcarecovery muestra qué ventana se aplicó):
Migración
channels.imessage.catchup.* está obsoleto: la recuperación de tiempo de inactividad es automática y no necesita configuración para instalaciones nuevas. Las configuraciones existentes con catchup.enabled: true siguen respetándose como perfil de compatibilidad para la ventana de reproducción de recuperación. Los bloques catchup deshabilitados (enabled: false o sin enabled: true) se retiran; openclaw doctor --fix los elimina.
Solución de problemas
No se encuentra imsg o RPC no compatible
No se encuentra imsg o RPC no compatible
imsg. Si las acciones de API privada no están disponibles, ejecuta imsg launch en la sesión del usuario de macOS que inició sesión y vuelve a sondear. Si el Gateway no se está ejecutando en macOS, usa la configuración de Mac remota por SSH anterior en lugar de la ruta local predeterminada de imsg.Los mensajes se envían, pero los iMessages entrantes no llegan
Los mensajes se envían, pero los iMessages entrantes no llegan
chat.db no cambia, OpenClaw no puede recibir el mensaje incluso cuando imsg status --json informa de un puente saludable.chat.db o un evento de imsg watch antes de depurar sesiones de OpenClaw. No ejecutes esto como un bucle periódico de relanzamiento del puente; imsg launch repetido más reinicios del Gateway durante trabajo activo pueden interrumpir entregas y dejar ejecuciones de canal en curso varadas.Gateway no se está ejecutando en macOS
Gateway no se está ejecutando en macOS
cliPath: "imsg" predeterminado debe ejecutarse en la Mac con sesión iniciada en Messages. En Linux o Windows, establece channels.imessage.cliPath en un script contenedor que haga SSH a esa Mac y ejecute imsg "$@".Los DM se ignoran
Los DM se ignoran
channels.imessage.dmPolicychannels.imessage.allowFrom- aprobaciones de emparejamiento (
openclaw pairing list imessage)
Los mensajes de grupo se ignoran
Los mensajes de grupo se ignoran
channels.imessage.groupPolicychannels.imessage.groupAllowFrom- comportamiento de lista de permitidos de
channels.imessage.groups - configuración de patrones de mención (
agents.list[].groupChat.mentionPatterns)
Los archivos adjuntos remotos fallan
Los archivos adjuntos remotos fallan
channels.imessage.remoteHostchannels.imessage.remoteAttachmentRoots- autenticación con clave SSH/SCP desde el host del Gateway
- que exista la clave de host en
~/.ssh/known_hostsen el host del Gateway - legibilidad de la ruta remota en la Mac que ejecuta Messages
Se omitieron los avisos de permisos de macOS
Se omitieron los avisos de permisos de macOS
imsg.Punteros de referencia de configuración
Relacionado
- Resumen de canales — todos los canales admitidos
- Eliminación de BlueBubbles y la ruta imsg de iMessage — anuncio y resumen de migración
- Migrar desde BlueBubbles — tabla de traducción de configuración y cambio paso a paso
- Emparejamiento — autenticación DM y flujo de emparejamiento
- Grupos — comportamiento de chat grupal y control por mención
- Enrutamiento de canales — enrutamiento de sesión para mensajes
- Seguridad — modelo de acceso y endurecimiento