同梱の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.
imessage Plugin は、JSON-RPC 経由で steipete/imsg を駆動することで、BlueBubbles と同じ private API サーフェス(react、edit、unsend、reply、sendWithEffect、グループ管理、添付ファイル)に到達できるようになりました。imsg をインストール済みの Mac をすでに運用している場合は、BlueBubbles サーバーを外し、Plugin から Messages.app に直接通信させることができます。
BlueBubbles サポートは削除されました。OpenClaw は imsg のみを通じて iMessage をサポートします。このガイドは古い channels.bluebubbles 設定を channels.imessage に移行するためのものです。それ以外のサポート対象の移行パスはありません。
この移行が適している場合
- Messages.app にサインイン済みの同じ Mac(または SSH で到達可能な Mac)で、すでに
imsgを実行している。 - 可動部分を 1 つ減らしたい。別個の BlueBubbles サーバーも、認証する REST エンドポイントも、Webhook 配線も不要です。サーバー + クライアントアプリ + ヘルパーではなく、単一の CLI バイナリになります。
- private API プローブが
available: trueを報告する、サポート対象の macOS /imsgビルドを使用している。
imsg の機能
imsg は Messages 用のローカル macOS CLI です。OpenClaw は imsg rpc を子プロセスとして起動し、stdin/stdout 経由で JSON-RPC を使って通信します。HTTP サーバー、Webhook URL、バックグラウンドデーモン、launch agent、公開するポートはありません。
- 読み取りは、読み取り専用 SQLite ハンドルを使用して
~/Library/Messages/chat.dbから行われます。 - ライブ受信メッセージは
imsg watch/watch.subscribeから来ます。これはポーリングのフォールバック付きでchat.dbのファイルシステムイベントを追跡します。 - 通常のテキスト送信とファイル送信には Messages.app の自動化を使用します。
- 高度なアクションでは、
imsg launchを使ってimsgヘルパーを Messages.app に注入します。これにより、開封確認、入力インジケーター、リッチ送信、編集、送信取り消し、スレッド返信、タップバック、グループ管理が有効になります。 - Linux ビルドではコピーされた
chat.dbを検査できますが、送信、ライブ Mac データベースの監視、Messages.app の駆動はできません。OpenClaw iMessage では、サインイン済みの Mac 上でimsgを実行するか、その Mac への SSH ラッパー経由で実行してください。
始める前に
-
Messages.app を実行する Mac に
imsgをインストールします。imsg chatsがunable to open database file、空の出力、またはauthorization deniedで失敗する場合は、imsgを起動するターミナル、エディター、Node プロセス、Gateway サービス、または SSH 親プロセスにフルディスクアクセスを付与し、その親プロセスを再度開いてください。 -
OpenClaw 設定を変更する前に、読み取り、監視、送信、RPC サーフェスを検証します。
42はimsg chatsから取得した実際のチャット ID に置き換えてください。送信には Messages.app の Automation 権限が必要です。OpenClaw を SSH 経由で実行する場合は、OpenClaw が使用するのと同じ SSH ラッパーまたはユーザーコンテキストでこれらのコマンドを実行してください。 -
高度なアクションが必要な場合は、private API ブリッジを有効にします。
imsg launchには SIP を無効にする必要があります。基本的な送信、履歴、監視はimsg launchなしで動作しますが、高度なアクションは動作しません。 -
OpenClaw 経由でブリッジを検証します。
imessage.privateApi.available: trueになっている必要があります。falseと報告される場合は、まずそれを修正してください。機能検出を参照してください。 -
設定のスナップショットを作成します。
設定の変換
iMessage と BlueBubbles は、多くのチャネルレベル設定を共有しています。変更されるキーのほとんどはトランスポート(REST サーバーかローカル CLI か)です。動作キー(dmPolicy、groupPolicy、allowFrom など)は同じ意味を保ちます。
| BlueBubbles | 同梱 iMessage | 注記 |
|---|---|---|
channels.bluebubbles.enabled | channels.imessage.enabled | 意味は同じです。 |
channels.bluebubbles.serverUrl | (削除済み) | REST サーバーはありません — Plugin が stdio 経由で imsg rpc を起動します。 |
channels.bluebubbles.password | (削除済み) | Webhook 認証は不要です。 |
| (暗黙) | channels.imessage.cliPath | imsg へのパス(デフォルトは imsg)。SSH にはラッパースクリプトを使用します。 |
| (暗黙) | channels.imessage.dbPath | 任意の Messages.app chat.db オーバーライド。省略時は自動検出されます。 |
| (暗黙) | channels.imessage.remoteHost | host または user@host — cliPath が SSH ラッパーで、SCP による添付ファイル取得を使いたい場合にのみ必要です。 |
channels.bluebubbles.dmPolicy | channels.imessage.dmPolicy | 同じ値(pairing / allowlist / open / disabled)。 |
channels.bluebubbles.allowFrom | channels.imessage.allowFrom | ペアリング承認は token ではなく handle で引き継がれます。 |
channels.bluebubbles.groupPolicy | channels.imessage.groupPolicy | 同じ値(allowlist / open / disabled)。 |
channels.bluebubbles.groupAllowFrom | channels.imessage.groupAllowFrom | 同じです。 |
channels.bluebubbles.groups | channels.imessage.groups | groups: { "*": { ... } } ワイルドカードエントリを含め、これをそのままコピーしてください。 グループごとの requireMention、tools、toolsBySender は引き継がれます。groupPolicy: "allowlist" では、groups ブロックが空または欠落していると、すべてのグループメッセージが黙って破棄されます — 下の「グループレジストリの落とし穴」を参照してください。 |
channels.bluebubbles.sendReadReceipts | channels.imessage.sendReadReceipts | デフォルトは true。同梱 Plugin では、これは private API プローブが稼働している場合にのみ実行されます。 |
channels.bluebubbles.includeAttachments | channels.imessage.includeAttachments | 同じ形で、同じくデフォルトはオフ。BlueBubbles で添付ファイルを流していた場合は、iMessage ブロックでこれを明示的に再設定する必要があります — 暗黙には引き継がれず、設定するまで受信写真/メディアは Inbound message ログ行なしで黙って破棄されます。 |
channels.bluebubbles.attachmentRoots | channels.imessage.attachmentRoots | ローカルルート。同じワイルドカードルールです。 |
| (該当なし) | channels.imessage.remoteAttachmentRoots | remoteHost が SCP 取得用に設定されている場合にのみ使用されます。 |
channels.bluebubbles.mediaMaxMb | channels.imessage.mediaMaxMb | iMessage ではデフォルト 16 MB(BlueBubbles のデフォルトは 8 MB)。低い上限を維持したい場合は明示的に設定してください。 |
channels.bluebubbles.textChunkLimit | channels.imessage.textChunkLimit | どちらもデフォルトは 4000 です。 |
channels.bluebubbles.coalesceSameSenderDms | channels.imessage.coalesceSameSenderDms | 同じオプトインです。DM のみ — グループチャットでは、どちらのチャンネルでもメッセージごとの即時ディスパッチを維持します。明示的な messages.inbound.byChannel.imessage なしで有効にした場合、デフォルトの受信デバウンスが 2500 ms に広がります。iMessage ドキュメント § 分割送信 DM の結合 を参照してください。 |
channels.bluebubbles.enrichGroupParticipantsFromContacts | (該当なし) | iMessage はすでに chat.db から送信者の表示名を読み取ります。 |
channels.bluebubbles.actions.* | channels.imessage.actions.* | アクションごとのトグル: reactions、edit、unsend、reply、sendWithEffect、renameGroup、setGroupIcon、addParticipant、removeParticipant、leaveGroup、sendAttachment。 |
channels.bluebubbles.accounts.*)は、channels.imessage.accounts.* に一対一で変換されます。
グループレジストリの落とし穴
同梱 iMessage Plugin は、2 つの別々のグループ allowlist ゲートを連続して実行します。グループメッセージがエージェントに届くには、両方を通過する必要があります。- 送信者 / チャットターゲット allowlist(
channels.imessage.groupAllowFrom)—isAllowedIMessageSenderによってチェックされます。受信メッセージを送信者 handle、chat_guid、chat_identifier、またはchat_idで照合します。形は BlueBubbles と同じです。 - グループレジストリ(
channels.imessage.groups)—inbound-processing.ts:199のresolveChannelGroupPolicyによってチェックされます。groupPolicy: "allowlist"では、このゲートは次のいずれかを要求します:groups: { "*": { ... } }ワイルドカードエントリ(allowAll = trueを設定)、またはgroupsの下にある明示的なchat_idごとのエントリ。
warn レベルのシグナルを出すため、これはデフォルトのログレベルでも沈黙しなくなりました。
groupPolicy: "allowlist"が設定されているがchannels.imessage.groupsが空("*"ワイルドカードもchat_idごとのエントリもない)の場合、アカウントごとに起動時に一度だけ出るwarn— メッセージが届く前に発火します。- 特定のグループが実行時に初めて破棄されたときに、
chat_idごとに一度だけ出るwarn。chat_id と、それを許可するためにgroupsに追加すべき正確なキーを示します。
groupAllowFrom と groupPolicy はコピーしますが、groups ブロックを省略します。BlueBubbles の groups: { "*": { "requireMention": true } } が無関係なメンション設定に見えるためです。実際には、レジストリゲートにとって不可欠です。
groupPolicy: "allowlist" の後もグループメッセージを流し続けるための最小設定:
* の下にある requireMention: true は、メンションパターンが設定されていない場合は無害です。ランタイムは canDetectMention = false を設定し、inbound-processing.ts:512 でメンションによるドロップを短絡します。メンションパターンが設定されている場合(agents.list[].groupChat.mentionPatterns)、期待どおりに動作します。
Gateway ログに imessage: dropping group message from chat_id=<id>、または起動時の行 imessage: groupPolicy="allowlist" but channels.imessage.groups is empty が出る場合、ゲート 2 でドロップされています。groups ブロックを追加してください。
手順
-
既存の BlueBubbles ブロックの横に iMessage ブロックを追加します。新しいパスが検証されるまでは、古いブロックはコピー元としてのみ残します。
-
ドライランのプローブ — Gateway を起動し、iMessage が正常と報告されることを確認します。
imessage.enabledはまだfalseのため、インバウンドの iMessage トラフィックはまだルーティングされません。ただし--probeはブリッジを実行するため、切り替え前に権限やインストールの問題を検出できます。 -
切り替えます。 1 回の設定編集で BlueBubbles 設定を削除し、iMessage を有効にします。
Gateway を再起動します。インバウンドの iMessage トラフィックは、同梱 Plugin を通るようになります。
- DM を検証します。 エージェントにダイレクトメッセージを送信し、返信が届くことを確認します。
-
グループを別途検証します。 DM とグループは異なるコードパスを通ります。DM の成功は、グループがルーティングされている証明にはなりません。ペアリング済みのグループチャットでエージェントにメッセージを送信し、返信が届くことを確認します。グループが無反応になる場合(エージェントの返信なし、エラーなし)、Gateway ログに
imessage: dropping group message from chat_id=<id>、または起動時のimessage: groupPolicy="allowlist" but channels.imessage.groups is empty行がないか確認します。どちらもデフォルトのログレベルで出力されます。どちらかが表示される場合、groupsブロックがないか空です。上記の「グループレジストリの落とし穴」を参照してください。 -
アクションサーフェスを検証します — ペアリング済み DM から、リアクション、編集、送信取り消し、返信、写真送信、(グループ内での)グループ名変更 / 参加者の追加または削除をエージェントに依頼します。各アクションは Messages.app にネイティブに反映される必要があります。いずれかが「iMessage
<action>requires the imsg private API bridge」をスローする場合は、imsg launchを再度実行し、channels status --probeを更新してください。 -
iMessage の DM、グループ、アクションが検証されたら、BlueBubbles サーバーと設定を削除します。OpenClaw は
channels.bluebubblesを使用しません。
アクションの対応状況の概要
| アクション | 従来の BlueBubbles | 同梱 iMessage |
|---|---|---|
| テキスト送信 / SMS フォールバック | ✅ | ✅ |
| メディア送信(写真、動画、ファイル、音声) | ✅ | ✅ |
スレッド返信(reply_to_guid) | ✅ | ✅(#51892 をクローズ) |
Tapback(react) | ✅ | ✅ |
| 編集 / 送信取り消し(macOS 13+ の受信者) | ✅ | ✅ |
| 画面エフェクト付き送信 | ✅ | ✅(#9394 の一部をクローズ) |
| リッチテキストの太字 / 斜体 / 下線 / 取り消し線 | ✅ | ✅(attributedBody による typed-run フォーマット) |
| グループ名変更 / グループアイコン設定 | ✅ | ✅ |
| 参加者の追加 / 削除、グループ退出 | ✅ | ✅ |
| 開封確認と入力中インジケーター | ✅ | ✅(private API プローブで制御) |
| 同一送信者の DM 結合 | ✅ | ✅(DM のみ。channels.imessage.coalesceSameSenderDms でオプトイン) |
| Gateway 停止中に受信したインバウンドメッセージのキャッチアップ | ✅(webhook 再生 + 履歴取得) | ✅(channels.imessage.catchup.enabled でオプトイン。#78649 をクローズ) |
channels.imessage.catchup.enabled が true の場合、Gateway は imsg watch と同じ JSON-RPC クライアントに対して chats.list と各チャットの messages.history パスを 1 回実行し、取りこぼした各インバウンド行をライブディスパッチパス(allowlist、グループポリシー、デバウンサー、エコーキャッシュ)で再生し、アカウントごとのカーソルを永続化します。そのため、以降の起動では中断した位置から再開します。調整については Gateway ダウンタイム後のキャッチアップ を参照してください。
ペアリング、セッション、ACP バインディング
- ペアリング承認 はハンドルごとに引き継がれます。既知の送信者を再承認する必要はありません。
channels.imessage.allowFromは、BlueBubbles が使用していた同じ+15555550123/user@example.com文字列を認識します。 - セッション はエージェント + チャットごとにスコープされます。DM はデフォルトの
session.dmScope=mainの下でエージェントのメインセッションにまとめられます。グループセッションはchat_idごとに分離されます。セッションキーは異なります(agent:<id>:imessage:group:<chat_id>と BlueBubbles の同等のキー)。BlueBubbles セッションキーの下にある古い会話履歴は iMessage セッションに引き継がれません。 match.channel: "bluebubbles"を参照する ACP バインディング は"imessage"に更新する必要があります。match.peer.idの形(chat_id:、chat_guid:、chat_identifier:、裸のハンドル)は同一です。
ロールバック用チャンネルはありません
戻すためのサポート済み BlueBubbles ランタイムはありません。iMessage の検証が失敗する場合は、channels.imessage.enabled: false を設定し、Gateway を再起動し、imsg の阻害要因を修正してから、切り替えを再試行してください。
返信キャッシュは ~/.openclaw/state/imessage/reply-cache.jsonl(モード 0600、親ディレクトリ 0700)にあります。クリーンスレートにしたい場合は削除しても安全です。
関連
- iMessage —
imsg launchのセットアップと機能検出を含む、完全な iMessage チャンネルリファレンス。 /channels/bluebubbles— この移行ガイドにリダイレクトする従来の URL。- ペアリング — DM 認証とペアリングフロー。
- チャンネルルーティング — Gateway がアウトバウンド返信のチャンネルを選択する方法。