OpenClaw 移除 BlueBubbles 频道迁移到 imsg 驱动的官方 iMessage 插件【免费下载链接】openclawThe AI that really does things. Any OS. Any Platform. The lobster way. 项目地址: https://gitcode.com/GitHub_Trending/cl/openclawOpenClaw 已不再内置 BlueBubbles 频道iMessage 支持统一走官方openclaw/imessage插件Gateway 以子进程方式拉起imsg本地直连或经 SSH wrapper通过 stdin/stdout 以 JSON-RPC 通信不再需要任何 HTTP 服务器、webhook 路由或端口。本文说明这次移除的背景、channels.bluebubbles到channels.imessage的完整配置翻译表、群组注册表的迁移陷阱、动作能力对等关系以及插件底层的探测与超时机制帮助存量 BlueBubbles 用户与新建 iMessage 用户一次性完成无风险切换。发生了什么一个 CLI 二进制替代整套 BlueBubbles 架构BlueBubbles 是典型的服务器 客户端 App webhook 管道三件套它需要运行一个 HTTP 服务器、暴露 webhook 路由、配置 REST 密码还要在 Messages Mac 上装配套客户端 App。OpenClaw 决定彻底移除这条路径channels.bluebubbles在当前的 OpenClaw 运行时中已经没有任何代码读取它——残留的配置块是惰性的inert不会报错也不会生效。替代方案只有一个官方openclaw/imessage插件 steipete/imsg这个 macOS 本地 CLI。OpenClaw 以子进程方式启动imsg rpc双方在 stdin/stdout 上按行分隔的 JSON-RPC 协议通信协议细节见 RPC 适配器能够触达 BlueBubbles 当年依赖的同一套私有 API 面react、edit、unsend、reply、sendWithEffect、原生投票、群组管理、附件等。没有 REST 端点、没有 webhook 鉴权、没有守护进程、没有需要暴露的端口。从源码结构看插件在 channel.ts 中通过createChatChannelPlugin注册频道消息适配器声明了text、media、replyTo、messageSendingHooks四项能力channel.ts出站投递模式为deliveryMode: direct文本分块采用chunkMarkdownText且textChunkLimit: 4000channel.ts——这些默认值直接决定了迁移后行为的基线。imsg 的分工读、看、发、注入imsg在 Messages Mac 上承担四种截然不同的工作理解这四层对排查迁移问题至关重要读取历史直接以只读 SQLite 句柄访问~/Library/Messages/chat.db实时入站来自imsg watch/watch.subscribe它跟踪chat.db的文件系统事件并带轮询兜底普通发送通过 Messages.app 自动化Automation 权限发送普通文本和文件高级动作imsg launch把 imsg 辅助代码注入 Messages.app解锁已读回执、输入指示器、富文本发送、编辑、撤回、线程回复、tapback、投票和群组管理。其中imsg launch需要关闭 SIP且在较新的 macOS 上还要放宽 library validation这是私人 API 桥的硬前提。基本发送、历史和 watch 不依赖它但 OpenClaw iMessage 的完整动作面依赖它。注意imsg的 Linux 构建只能检查复制过来的chat.db既不能发送也不能实时监视 Mac 上的数据库更不能驱动 Messages.app。因此 OpenClaw iMessage 必须让imsg跑在已登录 Messages.app 的那台 Mac 上或通过 SSH wrapper 指向该 Mac。迁移检查清单最短安全路径原 BlueBubbles 移除公告 给出 6 步操作Coming from BlueBubbles 把它扩展为 8 步完整检查清单合并如下安装官方插件并重启 Gatewayopenclaw plugins install openclaw/imessage openclaw gateway restart在 Messages Mac 上安装并验证imsgbrew install steipete/tap/imsg brew update brew upgrade imsg imsg --version imsg chats --limit 3 imsg rpc --help在改 OpenClaw 配置前最好先完整验证读、看、发、RPC 四个面imsg chats --limit 10 --json | jq -s imsg history --chat-id 42 --limit 10 --attachments --json | jq -s imsg watch --chat-id 42 --reactions --json imsg send --chat-id 42 --text OpenClaw imsg test如果imsg chats报unable to open database file、空输出或authorization denied说明缺少 Full Disk Access——需要把启动imsg的终端、编辑器、Node 进程、Gateway 服务或 SSH 父进程加入完全磁盘访问然后重新打开该父进程。如果读取正常但发送报 AppleEvents-1743请检查 Automation 权限是否落在了/usr/libexec/sshd-keygen-wrapper上SSH wrapper 场景的典型问题。开启私人 API 桥强烈建议回复、tapback、效果、投票、附件回复、群组动作都依赖它imsg launch imsg status --json把旧 BlueBubbles 的行为键复制到channels.imessagedmPolicy、allowFrom、groupPolicy、groupAllowFrom、groups、includeAttachments、attachmentRoots、mediaMaxMb、textChunkLimit、actions。丢弃不再存在的传输键serverUrl、password、webhook URL 和 BlueBubbles 服务器部署全部删除。如果 Gateway 不在 Messages Mac 上把channels.imessage.cliPath设为 Gateway 本机绝对路径下的 SSH wrapperdbPath保持为该 Mac 上的绝对路径并把remoteHost设为 Messages Mac复杂 wrapper 必须显式配置简单透明 wrapper 形状 OpenClaw 会按进程自动检测。典型 wrapper 就是一行#!/usr/bin/env bash exec ssh -T messages-mac imsg $SCP 走严格主机密钥校验确保 Messages Mac 的主机密钥已存在于~/.ssh/known_hosts。启用channels.imessage、重启 Gateway 并探测openclaw channels status --probe --channel imessage期望 iMessage 账号报告works加--json时探测负载里应有privateApi.available: true。探测需要 Gateway 可达否则 CLI 退回仅配置输出且只探测已配置、已启用的账号。逐项测试后删除旧服务器测试一个 DM、一个允许的群、附件若启用、以及 agent 会使用的每个私人 API 动作全部验证通过后再删除 BlueBubbles 服务器和channels.bluebubbles配置块。另外迁移前先备份配置cp ~/.openclaw/openclaw.json ~/.openclaw/openclaw.json.bak配置翻译逐键对照表iMessage 与 BlueBubbles 共享绝大多数频道级行为键变化集中在传输层REST 服务器 vs 本地 CLI和群组注册表键格式GUID/identifier vs 数字chat_id。完整对照如下来自 Coming from BlueBubbles 的翻译表BlueBubblesiMessage 插件说明channels.bluebubbles.enabledchannels.imessage.enabled语义相同配置块存在时默认truechannels.bluebubbles.serverUrl移除无 REST 服务器——插件通过 stdio 拉起imsg rpcchannels.bluebubbles.password移除无需 webhook 鉴权隐式channels.imessage.cliPathimsg路径默认imsgSSH 场景用 Gateway 主机上的 wrapper 绝对路径隐式channels.imessage.dbPath可选的 Messageschat.db覆盖SSH 场景是该 Mac 上的绝对路径绝不在 Gateway 家目录下展开隐式channels.imessage.remoteHostMessages Mac 的host或userhost显式配置优先简单透明 SSH wrapper 按进程自动检测。启用后支持入站附件抓取和仅属主可见的出站暂存清理尽力而为channels.bluebubbles.dmPolicychannels.imessage.dmPolicy取值相同pairing/allowlist/open/disabled默认pairingchannels.bluebubbles.allowFromchannels.imessage.allowFrom句柄格式相同15555550123、userexample.com。配对存储的审批不转移channels.bluebubbles.groupPolicychannels.imessage.groupPolicy取值相同allowlist/open/disabled默认allowlistchannels.bluebubbles.groupAllowFromchannels.imessage.groupAllowFrom未设置时回退到allowFrom显式空数组[]在allowlist下拦截所有群消息channels.bluebubbles.groupschannels.imessage.groups*通配条目原样复制按条目标目必须改用数字 iMessagechat_id重新键控见下文群组注册表陷阱。requireMention、tools、toolsBySender、systemPrompt原样继承channels.bluebubbles.sendReadReceiptschannels.imessage.sendReadReceipts默认true仅在私人 API 探测通过后生效channels.bluebubbles.includeAttachmentschannels.imessage.includeAttachments形状相同同为默认关闭。BlueBubbles 时代附件能进来就必须显式打开否则入站照片/媒体被静默丢弃连Inbound message日志都没有channels.bluebubbles.attachmentRootschannels.imessage.attachmentRoots本地根目录通配规则相同N/Achannels.imessage.remoteAttachmentRoots仅在设置remoteHost后用于 SCP 抓取channels.bluebubbles.mediaMaxMbchannels.imessage.mediaMaxMbiMessage 默认 16 MBBlueBubbles 默认 8 MB想保持低上限就显式设置channels.bluebubbles.textChunkLimitchannels.imessage.textChunkLimit两者默认都是 4000channels.bluebubbles.coalesceSameSenderDms移除不要迁移。imsg0.13.1 及更新版本会在 OpenClaw 收到前合并 Apple 链接预览的拆分发送openclaw doctor --fix会清理过期的 iMessage 键channels.bluebubbles.enrichGroupParticipantsFromContactsN/Aimsg已直接从chat.db带出发送者显示名channels.bluebubbles.actions.*channels.imessage.actions.*逐动作开关相同reactions、edit、unsend、reply、sendWithEffect、renameGroup、setGroupIcon、addParticipant、removeParticipant、leaveGroup、sendAttachment另新增polls。全部默认启用但私人 API 动作仍需桥接多账号配置channels.bluebubbles.accounts.*一对一翻译为channels.imessage.accounts.*。迁移后目标配置的一个完整示例来自 个人消息频道配置参考{ channels: { imessage: { enabled: true, cliPath: /home/openclaw/.openclaw/scripts/imsg-ssh, dbPath: /Users/user/Library/Messages/chat.db, remoteHost: usermessages-mac, dmPolicy: pairing, allowFrom: [15555550123, userexample.com, chat_id:123], historyLimit: 50, includeAttachments: false, attachmentRoots: [/Users/*/Library/Messages/Attachments], remoteAttachmentRoots: [/Users/*/Library/Messages/Attachments], mediaMaxMb: 16, service: auto, sendTransport: auto, region: US, actions: { reactions: true, edit: true, unsend: true, reply: true, sendWithEffect: true, sendAttachment: true, }, }, }, }其中sendTransport的取值值得单独说明auto默认在桥运行时优先走 IMCore 桥发送到已存在的会话失败再回退 AppleScriptbridge强制走私人 API 投递applescript强制走公开的 Messages 自动化路径。选型时需要在能力与稳定性之间权衡。群组注册表陷阱两个门都要过iMessage 插件对群消息执行背靠背的两道门禁群消息必须同时通过才能到达 agent详见 Coming from BlueBubbles 的 Group registry footgun 一节实现上由 group-policy.ts 通过buildChannelGroupsScopeTree解析requireMention与工具策略发送者 / 会话目标白名单channels.imessage.groupAllowFrom匹配发送者句柄或会话目标chat_id:、chat_guid:、chat_identifier:条目。未设置时回退allowFrom显式groupAllowFrom: []会关闭回退并在allowlist策略下丢弃所有群消息。群组注册表channels.imessage.groups按数字 iMessagechat_id键控无groups块或为空只要门 1 有非空的有效发送者白名单群消息就放行不触发启动警告有groups条目但没有*只有列出的chat_id键能过——列出任何群都会把注册表变成白名单即使在groupPolicy: open下也一样groups: { *: { ... } }所有群都过这道门。迁移陷阱就在这里BlueBubbles 用聊天 GUID/identifier 键控groups而 iMessage 注册表用数字chat_id键控。按条目录目直接复制的条目会形成一个键永远匹配不上的非空注册表于是每条群消息都在门 2 被丢弃。正确做法是*通配条目原样复制具体群条目用imsg chats输出的chat_id重新键控。两条丢消息路径在默认日志级别下都能看到warn行启动时每个账号一次当groupPolicy: allowlist且有效群发送者白名单为空时imessage: groupPolicyallowlist for account id but no group sender allowlist is configured ...——只加groups条目满足不了发送者这道门运行时每个chat_id一次当注册表丢弃群消息时imessage: dropping group message from chat_idid ... not in channels.imessage.groups allowlist——日志会直接给出该补的键名。注意DM 正常不代表群组正常——DM 走的是完全不同的代码路径。验证群组必须单独发消息测试。满足groupPolicy: allowlist的最小发送者级配置{ channels: { imessage: { groupPolicy: allowlist, groupAllowFrom: [15555550123, chat_guid:any;-;...], }, }, }动作能力对等迁移没有能力损失动作旧 BlueBubblesiMessage 插件发送文本 / SMS 回退✅✅发送媒体照片、视频、文件、语音✅✅线程回复reply_to_guid✅✅Tapbackreact✅✅编辑 / 撤回macOS 13 接收方✅✅带屏幕效果发送✅✅富文本加粗 / 斜体 / 下划线 / 删除线✅✅经 attributedBody 的类型化 run 格式化原生 Messages 投票创建与投票❌✅actions.polls接收方需 iOS/macOS 26 才能原生渲染重命名群 / 设置群图标✅✅加人 / 移人 / 退群✅✅已读回执与输入指示器✅✅受私人 API 探测门控Apple 链接预览拆分发送合并✅✅由imsg0.13.1 上游处理无 OpenClaw 设置项重启后的入站恢复✅✅自动since_rowid重放 GUID 去重本地窗口更宽其中原生投票是相对 BlueBubbles 的净新增能力BlueBubbles 时代不可用。而重启后入站恢复是 iMessage 路径的隐藏亮点Gateway 宕机期间错过的消息会在启动时从上次分发的 rowid 重放imsg watch.subscribe的since_rowid按 GUID 去重并用陈旧积压年龄围栏抑制 Apple 在 Push 恢复后可能冲刷的积压炸弹——无需任何配置由于走imsgRPC 连接对远程 SSHcliPath部署同样生效本地部署因能直接读chat.db而恢复窗口更宽。配对、会话与 ACP 绑定白名单按句柄携带channels.imessage.allowFrom识别与 BlueBubbles 相同的15555550123/userexample.com字符串逐字复制即可。配对存储审批不转移配对存储按频道隔离没有任何机制迁移旧的 BlueBubbles 存储。只靠配对审批通过的发送者需要在 iMessage 下重新配对一次或者你把句柄加进allowFrom。会话按 agent 会话作用域默认session.dmScopemain下 DM 归并到 agent 主会话默认session.groupScopeper-group下群会话按chat_id隔离会话键形如agent:agentId:imessage:group:chat_id该键形状在 channel.ts 的出站路由代码中直接生成。旧 BlueBubbles 会话键下的聊天历史不会带入 iMessage 会话。ACP 绑定凡match.channel: bluebubbles的绑定必须改为imessagematch.peer.id的形状chat_id:、chat_guid:、chat_identifier:、裸句柄完全一致。验证、回滚与收尾验证顺序先openclaw channels status --probe --channel imessage确认works与privateApi.available: true然后分别验证 DM 与群组两者代码路径不同最后在配对 DM 里让 agent 依次执行 react、edit、unsend、reply、发照片并在群组里重命名或加减成员。若某动作报iMessage action requires the imsg private API bridge重新执行imsg launch再刷新探测。没有回滚通道不存在可切回的受支持的 BlueBubbles 运行时。若 iMessage 验证失败把channels.imessage.enabled置为false、重启 Gateway、修好imsg的阻塞点再重试切换。回复缓存位于 SQLite 插件状态中openclaw doctor --fix会在存在时导入并归档旧的imessage/reply-cache.jsonl边车文件。远程部署的两个已知限制远程imsgv0.13.4投票必须用pollOptionId而非下标或选项文本附件回复不能针对非零消息部分索引。本地imsg行为不受影响。底层原理插件如何探测与自愈从源码看插件的健康探测probe.ts是一条精心设计的证据链迁移时可用它精确判定瓶颈RPC 支持探测执行imsg rpc --help若输出含unknown commandrpc则判定fatal直接提示升级命令brew upgrade imsg。结果带 5 分钟 TTL 缓存让进程内发生的brew upgrade imsg无需重启 Gateway 也能生效probe.ts。私人 API 探测执行imsg status --json解析 JSONL 负载中的advanced_features与v2_ready标志位决定privateApi.available同时把桥不可用的原因SIP、library validation、macOS 26 AMFI 门带进状态消息。不可用时还有 10 秒负向 TTL 缓存避免桥故障期间的动作风暴串行打探 RPCprobe.ts。CLI 能力探测通过imsg send-rich --help是否含--file、imsg poll send --help是否含--no-comment无副作用地确认回复附件合并发送无评论投票两条能力避免发送时静默降级。连通性终检建立 RPC client 后执行chats.listlimit 1确认整条链路可用。超时基线探测/普通 RPC 默认超时 10 秒DEFAULT_IMESSAGE_PROBE_TIMEOUT_MS发送超时 180 秒DEFAULT_IMESSAGE_SEND_TIMEOUT_MS——后者必须覆盖 imsg 的 150 秒桥发送等待期加最多 8 秒的 AppleScript 回退验证期否则成功的回退发送会被误判为超时引发重试见 constants.ts。非 Mac 守卫默认imsg路径在非 darwin 平台直接返回致命错误提示要么在已登录 Messages 的 Mac 上跑 OpenClaw要么设置 SSH wrapper 的cliPathprobe.ts。进一步阅读BlueBubbles 移除公告——本文对应的短版公告与运维摘要Coming from BlueBubbles——完整配置翻译表、群组门禁、动作对等表与分步切换iMessage——iMessage 频道总览含imsg launch设置与能力检测入口个人消息频道配置参考——iMessage 全部字段的权威参考与 SSH wrapper 示例插件实现channel.ts、probe.ts、group-policy.ts、cli-path.ts。【免费下载链接】openclawThe AI that really does things. Any OS. Any Platform. The lobster way. 项目地址: https://gitcode.com/GitHub_Trending/cl/openclaw创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 OpenClaw 移除 BlueBubbles 频道：迁移到 imsg 驱动的官方 iMessage 插件
OpenClaw 移除 BlueBubbles 频道迁移到 imsg 驱动的官方 iMessage 插件【免费下载链接】openclawThe AI that really does things. Any OS. Any Platform. The lobster way. 项目地址: https://gitcode.com/GitHub_Trending/cl/openclawOpenClaw 已不再内置 BlueBubbles 频道iMessage 支持统一走官方openclaw/imessage插件Gateway 以子进程方式拉起imsg本地直连或经 SSH wrapper通过 stdin/stdout 以 JSON-RPC 通信不再需要任何 HTTP 服务器、webhook 路由或端口。本文说明这次移除的背景、channels.bluebubbles到channels.imessage的完整配置翻译表、群组注册表的迁移陷阱、动作能力对等关系以及插件底层的探测与超时机制帮助存量 BlueBubbles 用户与新建 iMessage 用户一次性完成无风险切换。发生了什么一个 CLI 二进制替代整套 BlueBubbles 架构BlueBubbles 是典型的服务器 客户端 App webhook 管道三件套它需要运行一个 HTTP 服务器、暴露 webhook 路由、配置 REST 密码还要在 Messages Mac 上装配套客户端 App。OpenClaw 决定彻底移除这条路径channels.bluebubbles在当前的 OpenClaw 运行时中已经没有任何代码读取它——残留的配置块是惰性的inert不会报错也不会生效。替代方案只有一个官方openclaw/imessage插件 steipete/imsg这个 macOS 本地 CLI。OpenClaw 以子进程方式启动imsg rpc双方在 stdin/stdout 上按行分隔的 JSON-RPC 协议通信协议细节见 RPC 适配器能够触达 BlueBubbles 当年依赖的同一套私有 API 面react、edit、unsend、reply、sendWithEffect、原生投票、群组管理、附件等。没有 REST 端点、没有 webhook 鉴权、没有守护进程、没有需要暴露的端口。从源码结构看插件在 channel.ts 中通过createChatChannelPlugin注册频道消息适配器声明了text、media、replyTo、messageSendingHooks四项能力channel.ts出站投递模式为deliveryMode: direct文本分块采用chunkMarkdownText且textChunkLimit: 4000channel.ts——这些默认值直接决定了迁移后行为的基线。imsg 的分工读、看、发、注入imsg在 Messages Mac 上承担四种截然不同的工作理解这四层对排查迁移问题至关重要读取历史直接以只读 SQLite 句柄访问~/Library/Messages/chat.db实时入站来自imsg watch/watch.subscribe它跟踪chat.db的文件系统事件并带轮询兜底普通发送通过 Messages.app 自动化Automation 权限发送普通文本和文件高级动作imsg launch把 imsg 辅助代码注入 Messages.app解锁已读回执、输入指示器、富文本发送、编辑、撤回、线程回复、tapback、投票和群组管理。其中imsg launch需要关闭 SIP且在较新的 macOS 上还要放宽 library validation这是私人 API 桥的硬前提。基本发送、历史和 watch 不依赖它但 OpenClaw iMessage 的完整动作面依赖它。注意imsg的 Linux 构建只能检查复制过来的chat.db既不能发送也不能实时监视 Mac 上的数据库更不能驱动 Messages.app。因此 OpenClaw iMessage 必须让imsg跑在已登录 Messages.app 的那台 Mac 上或通过 SSH wrapper 指向该 Mac。迁移检查清单最短安全路径原 BlueBubbles 移除公告 给出 6 步操作Coming from BlueBubbles 把它扩展为 8 步完整检查清单合并如下安装官方插件并重启 Gatewayopenclaw plugins install openclaw/imessage openclaw gateway restart在 Messages Mac 上安装并验证imsgbrew install steipete/tap/imsg brew update brew upgrade imsg imsg --version imsg chats --limit 3 imsg rpc --help在改 OpenClaw 配置前最好先完整验证读、看、发、RPC 四个面imsg chats --limit 10 --json | jq -s imsg history --chat-id 42 --limit 10 --attachments --json | jq -s imsg watch --chat-id 42 --reactions --json imsg send --chat-id 42 --text OpenClaw imsg test如果imsg chats报unable to open database file、空输出或authorization denied说明缺少 Full Disk Access——需要把启动imsg的终端、编辑器、Node 进程、Gateway 服务或 SSH 父进程加入完全磁盘访问然后重新打开该父进程。如果读取正常但发送报 AppleEvents-1743请检查 Automation 权限是否落在了/usr/libexec/sshd-keygen-wrapper上SSH wrapper 场景的典型问题。开启私人 API 桥强烈建议回复、tapback、效果、投票、附件回复、群组动作都依赖它imsg launch imsg status --json把旧 BlueBubbles 的行为键复制到channels.imessagedmPolicy、allowFrom、groupPolicy、groupAllowFrom、groups、includeAttachments、attachmentRoots、mediaMaxMb、textChunkLimit、actions。丢弃不再存在的传输键serverUrl、password、webhook URL 和 BlueBubbles 服务器部署全部删除。如果 Gateway 不在 Messages Mac 上把channels.imessage.cliPath设为 Gateway 本机绝对路径下的 SSH wrapperdbPath保持为该 Mac 上的绝对路径并把remoteHost设为 Messages Mac复杂 wrapper 必须显式配置简单透明 wrapper 形状 OpenClaw 会按进程自动检测。典型 wrapper 就是一行#!/usr/bin/env bash exec ssh -T messages-mac imsg $SCP 走严格主机密钥校验确保 Messages Mac 的主机密钥已存在于~/.ssh/known_hosts。启用channels.imessage、重启 Gateway 并探测openclaw channels status --probe --channel imessage期望 iMessage 账号报告works加--json时探测负载里应有privateApi.available: true。探测需要 Gateway 可达否则 CLI 退回仅配置输出且只探测已配置、已启用的账号。逐项测试后删除旧服务器测试一个 DM、一个允许的群、附件若启用、以及 agent 会使用的每个私人 API 动作全部验证通过后再删除 BlueBubbles 服务器和channels.bluebubbles配置块。另外迁移前先备份配置cp ~/.openclaw/openclaw.json ~/.openclaw/openclaw.json.bak配置翻译逐键对照表iMessage 与 BlueBubbles 共享绝大多数频道级行为键变化集中在传输层REST 服务器 vs 本地 CLI和群组注册表键格式GUID/identifier vs 数字chat_id。完整对照如下来自 Coming from BlueBubbles 的翻译表BlueBubblesiMessage 插件说明channels.bluebubbles.enabledchannels.imessage.enabled语义相同配置块存在时默认truechannels.bluebubbles.serverUrl移除无 REST 服务器——插件通过 stdio 拉起imsg rpcchannels.bluebubbles.password移除无需 webhook 鉴权隐式channels.imessage.cliPathimsg路径默认imsgSSH 场景用 Gateway 主机上的 wrapper 绝对路径隐式channels.imessage.dbPath可选的 Messageschat.db覆盖SSH 场景是该 Mac 上的绝对路径绝不在 Gateway 家目录下展开隐式channels.imessage.remoteHostMessages Mac 的host或userhost显式配置优先简单透明 SSH wrapper 按进程自动检测。启用后支持入站附件抓取和仅属主可见的出站暂存清理尽力而为channels.bluebubbles.dmPolicychannels.imessage.dmPolicy取值相同pairing/allowlist/open/disabled默认pairingchannels.bluebubbles.allowFromchannels.imessage.allowFrom句柄格式相同15555550123、userexample.com。配对存储的审批不转移channels.bluebubbles.groupPolicychannels.imessage.groupPolicy取值相同allowlist/open/disabled默认allowlistchannels.bluebubbles.groupAllowFromchannels.imessage.groupAllowFrom未设置时回退到allowFrom显式空数组[]在allowlist下拦截所有群消息channels.bluebubbles.groupschannels.imessage.groups*通配条目原样复制按条目标目必须改用数字 iMessagechat_id重新键控见下文群组注册表陷阱。requireMention、tools、toolsBySender、systemPrompt原样继承channels.bluebubbles.sendReadReceiptschannels.imessage.sendReadReceipts默认true仅在私人 API 探测通过后生效channels.bluebubbles.includeAttachmentschannels.imessage.includeAttachments形状相同同为默认关闭。BlueBubbles 时代附件能进来就必须显式打开否则入站照片/媒体被静默丢弃连Inbound message日志都没有channels.bluebubbles.attachmentRootschannels.imessage.attachmentRoots本地根目录通配规则相同N/Achannels.imessage.remoteAttachmentRoots仅在设置remoteHost后用于 SCP 抓取channels.bluebubbles.mediaMaxMbchannels.imessage.mediaMaxMbiMessage 默认 16 MBBlueBubbles 默认 8 MB想保持低上限就显式设置channels.bluebubbles.textChunkLimitchannels.imessage.textChunkLimit两者默认都是 4000channels.bluebubbles.coalesceSameSenderDms移除不要迁移。imsg0.13.1 及更新版本会在 OpenClaw 收到前合并 Apple 链接预览的拆分发送openclaw doctor --fix会清理过期的 iMessage 键channels.bluebubbles.enrichGroupParticipantsFromContactsN/Aimsg已直接从chat.db带出发送者显示名channels.bluebubbles.actions.*channels.imessage.actions.*逐动作开关相同reactions、edit、unsend、reply、sendWithEffect、renameGroup、setGroupIcon、addParticipant、removeParticipant、leaveGroup、sendAttachment另新增polls。全部默认启用但私人 API 动作仍需桥接多账号配置channels.bluebubbles.accounts.*一对一翻译为channels.imessage.accounts.*。迁移后目标配置的一个完整示例来自 个人消息频道配置参考{ channels: { imessage: { enabled: true, cliPath: /home/openclaw/.openclaw/scripts/imsg-ssh, dbPath: /Users/user/Library/Messages/chat.db, remoteHost: usermessages-mac, dmPolicy: pairing, allowFrom: [15555550123, userexample.com, chat_id:123], historyLimit: 50, includeAttachments: false, attachmentRoots: [/Users/*/Library/Messages/Attachments], remoteAttachmentRoots: [/Users/*/Library/Messages/Attachments], mediaMaxMb: 16, service: auto, sendTransport: auto, region: US, actions: { reactions: true, edit: true, unsend: true, reply: true, sendWithEffect: true, sendAttachment: true, }, }, }, }其中sendTransport的取值值得单独说明auto默认在桥运行时优先走 IMCore 桥发送到已存在的会话失败再回退 AppleScriptbridge强制走私人 API 投递applescript强制走公开的 Messages 自动化路径。选型时需要在能力与稳定性之间权衡。群组注册表陷阱两个门都要过iMessage 插件对群消息执行背靠背的两道门禁群消息必须同时通过才能到达 agent详见 Coming from BlueBubbles 的 Group registry footgun 一节实现上由 group-policy.ts 通过buildChannelGroupsScopeTree解析requireMention与工具策略发送者 / 会话目标白名单channels.imessage.groupAllowFrom匹配发送者句柄或会话目标chat_id:、chat_guid:、chat_identifier:条目。未设置时回退allowFrom显式groupAllowFrom: []会关闭回退并在allowlist策略下丢弃所有群消息。群组注册表channels.imessage.groups按数字 iMessagechat_id键控无groups块或为空只要门 1 有非空的有效发送者白名单群消息就放行不触发启动警告有groups条目但没有*只有列出的chat_id键能过——列出任何群都会把注册表变成白名单即使在groupPolicy: open下也一样groups: { *: { ... } }所有群都过这道门。迁移陷阱就在这里BlueBubbles 用聊天 GUID/identifier 键控groups而 iMessage 注册表用数字chat_id键控。按条目录目直接复制的条目会形成一个键永远匹配不上的非空注册表于是每条群消息都在门 2 被丢弃。正确做法是*通配条目原样复制具体群条目用imsg chats输出的chat_id重新键控。两条丢消息路径在默认日志级别下都能看到warn行启动时每个账号一次当groupPolicy: allowlist且有效群发送者白名单为空时imessage: groupPolicyallowlist for account id but no group sender allowlist is configured ...——只加groups条目满足不了发送者这道门运行时每个chat_id一次当注册表丢弃群消息时imessage: dropping group message from chat_idid ... not in channels.imessage.groups allowlist——日志会直接给出该补的键名。注意DM 正常不代表群组正常——DM 走的是完全不同的代码路径。验证群组必须单独发消息测试。满足groupPolicy: allowlist的最小发送者级配置{ channels: { imessage: { groupPolicy: allowlist, groupAllowFrom: [15555550123, chat_guid:any;-;...], }, }, }动作能力对等迁移没有能力损失动作旧 BlueBubblesiMessage 插件发送文本 / SMS 回退✅✅发送媒体照片、视频、文件、语音✅✅线程回复reply_to_guid✅✅Tapbackreact✅✅编辑 / 撤回macOS 13 接收方✅✅带屏幕效果发送✅✅富文本加粗 / 斜体 / 下划线 / 删除线✅✅经 attributedBody 的类型化 run 格式化原生 Messages 投票创建与投票❌✅actions.polls接收方需 iOS/macOS 26 才能原生渲染重命名群 / 设置群图标✅✅加人 / 移人 / 退群✅✅已读回执与输入指示器✅✅受私人 API 探测门控Apple 链接预览拆分发送合并✅✅由imsg0.13.1 上游处理无 OpenClaw 设置项重启后的入站恢复✅✅自动since_rowid重放 GUID 去重本地窗口更宽其中原生投票是相对 BlueBubbles 的净新增能力BlueBubbles 时代不可用。而重启后入站恢复是 iMessage 路径的隐藏亮点Gateway 宕机期间错过的消息会在启动时从上次分发的 rowid 重放imsg watch.subscribe的since_rowid按 GUID 去重并用陈旧积压年龄围栏抑制 Apple 在 Push 恢复后可能冲刷的积压炸弹——无需任何配置由于走imsgRPC 连接对远程 SSHcliPath部署同样生效本地部署因能直接读chat.db而恢复窗口更宽。配对、会话与 ACP 绑定白名单按句柄携带channels.imessage.allowFrom识别与 BlueBubbles 相同的15555550123/userexample.com字符串逐字复制即可。配对存储审批不转移配对存储按频道隔离没有任何机制迁移旧的 BlueBubbles 存储。只靠配对审批通过的发送者需要在 iMessage 下重新配对一次或者你把句柄加进allowFrom。会话按 agent 会话作用域默认session.dmScopemain下 DM 归并到 agent 主会话默认session.groupScopeper-group下群会话按chat_id隔离会话键形如agent:agentId:imessage:group:chat_id该键形状在 channel.ts 的出站路由代码中直接生成。旧 BlueBubbles 会话键下的聊天历史不会带入 iMessage 会话。ACP 绑定凡match.channel: bluebubbles的绑定必须改为imessagematch.peer.id的形状chat_id:、chat_guid:、chat_identifier:、裸句柄完全一致。验证、回滚与收尾验证顺序先openclaw channels status --probe --channel imessage确认works与privateApi.available: true然后分别验证 DM 与群组两者代码路径不同最后在配对 DM 里让 agent 依次执行 react、edit、unsend、reply、发照片并在群组里重命名或加减成员。若某动作报iMessage action requires the imsg private API bridge重新执行imsg launch再刷新探测。没有回滚通道不存在可切回的受支持的 BlueBubbles 运行时。若 iMessage 验证失败把channels.imessage.enabled置为false、重启 Gateway、修好imsg的阻塞点再重试切换。回复缓存位于 SQLite 插件状态中openclaw doctor --fix会在存在时导入并归档旧的imessage/reply-cache.jsonl边车文件。远程部署的两个已知限制远程imsgv0.13.4投票必须用pollOptionId而非下标或选项文本附件回复不能针对非零消息部分索引。本地imsg行为不受影响。底层原理插件如何探测与自愈从源码看插件的健康探测probe.ts是一条精心设计的证据链迁移时可用它精确判定瓶颈RPC 支持探测执行imsg rpc --help若输出含unknown commandrpc则判定fatal直接提示升级命令brew upgrade imsg。结果带 5 分钟 TTL 缓存让进程内发生的brew upgrade imsg无需重启 Gateway 也能生效probe.ts。私人 API 探测执行imsg status --json解析 JSONL 负载中的advanced_features与v2_ready标志位决定privateApi.available同时把桥不可用的原因SIP、library validation、macOS 26 AMFI 门带进状态消息。不可用时还有 10 秒负向 TTL 缓存避免桥故障期间的动作风暴串行打探 RPCprobe.ts。CLI 能力探测通过imsg send-rich --help是否含--file、imsg poll send --help是否含--no-comment无副作用地确认回复附件合并发送无评论投票两条能力避免发送时静默降级。连通性终检建立 RPC client 后执行chats.listlimit 1确认整条链路可用。超时基线探测/普通 RPC 默认超时 10 秒DEFAULT_IMESSAGE_PROBE_TIMEOUT_MS发送超时 180 秒DEFAULT_IMESSAGE_SEND_TIMEOUT_MS——后者必须覆盖 imsg 的 150 秒桥发送等待期加最多 8 秒的 AppleScript 回退验证期否则成功的回退发送会被误判为超时引发重试见 constants.ts。非 Mac 守卫默认imsg路径在非 darwin 平台直接返回致命错误提示要么在已登录 Messages 的 Mac 上跑 OpenClaw要么设置 SSH wrapper 的cliPathprobe.ts。进一步阅读BlueBubbles 移除公告——本文对应的短版公告与运维摘要Coming from BlueBubbles——完整配置翻译表、群组门禁、动作对等表与分步切换iMessage——iMessage 频道总览含imsg launch设置与能力检测入口个人消息频道配置参考——iMessage 全部字段的权威参考与 SSH wrapper 示例插件实现channel.ts、probe.ts、group-policy.ts、cli-path.ts。【免费下载链接】openclawThe AI that really does things. Any OS. Any Platform. The lobster way. 项目地址: https://gitcode.com/GitHub_Trending/cl/openclaw创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考