OpenClaw iMessage デプロイでは、サインイン済みの macOS Messages ホスト上で
imsg を使用します。Gateway が Linux または Windows で動作している場合は、Mac 上で imsg を実行する SSH ラッパーを channels.imessage.cliPath に指定します。インバウンド復旧は自動です。 ブリッジまたは Gateway の再起動後、iMessage は停止中に取りこぼしたメッセージを再生し、Push 復旧後に Apple がフラッシュする可能性がある古い「backlog bomb」を抑制し、重複排除によって同じものが二度ディスパッチされないようにします。有効化する設定はありません。ブリッジまたは Gateway 再起動後のインバウンド復旧を参照してください。imsg rpc を起動し、stdio 経由で JSON-RPC をやり取りします。別個のデーモンやポートはありません。高度なアクションには imsg launch と、private API プローブの成功が必要です。
Private API アクション
返信、tapback、エフェクト、投票、添付ファイル、グループ管理。
ペアリング
iMessage DM はデフォルトでペアリングモードになります。
SSH 経由のリモート Mac
Gateway が Messages Mac 上で動作していない場合は SSH ラッパーを使用します。
設定リファレンス
iMessage フィールドの完全なリファレンス。
クイックセットアップ
- ローカル Mac(高速パス)
- SSH 経由のリモート Mac
要件と権限(macOS)
imsgを実行する Mac で Messages にサインインしている必要があります。- OpenClaw/
imsgを実行するプロセスコンテキストには Full Disk Access が必要です(Messages DB アクセス)。 - Messages.app 経由でメッセージを送信するには Automation 権限が必要です。
- 高度なアクション(react / edit / unsend / スレッド返信 / エフェクト / 投票 / グループ操作)には System Integrity Protection を無効にする必要があります。imsg private API の有効化を参照してください。基本的なテキストとメディアの送受信は、それなしで動作します。
SSH ラッパーの送信が AppleEvents -1743 で失敗する
SSH ラッパーの送信が AppleEvents -1743 で失敗する
リモート SSH セットアップでは、チャットの読み取り、サインイン済みの Mac ユーザーの TCC データベース、または System Settings > Privacy & Security > Automation を確認してください。Automation エントリが その状態では、
channels status --probe の通過、インバウンドメッセージの処理はできても、アウトバウンド送信が AppleEvents 認可エラーで失敗する場合があります。imsg やローカルシェルプロセスではなく /usr/libexec/sshd-keygen-wrapper に記録されている場合、macOS はその SSH サーバー側クライアントに対して使用可能な Messages トグルを表示しないことがあります。tccutil reset AppleEvents を繰り返したり、同じ SSH ラッパー経由で imsg send を再実行したりしても失敗し続ける可能性があります。Messages Automation を必要とするプロセスコンテキストが、UI で許可できるアプリではなく SSH ラッパーだからです。代わりに、サポートされている imsg プロセスコンテキストのいずれかを使用します。- Gateway、または少なくとも
imsgブリッジを、ログイン済み Messages ユーザーのローカルセッションで実行します。 - 同じセッションから Full Disk Access と Automation を付与した後、そのユーザーの LaunchAgent で Gateway を起動します。
- 2 ユーザー SSH トポロジを維持する場合は、チャネルを有効にする前に、実際のアウトバウンド
imsg sendが正確なラッパー経由で成功することを確認します。Automation を付与できない場合は、送信を SSH ラッパーに依存するのではなく、単一ユーザーのimsgセットアップに再設定してください。
imsg private API の有効化
imsg は 2 つの運用モードで提供されます。
- 基本モード(デフォルト、SIP 変更不要):
sendによるアウトバウンドのテキストとメディア、インバウンドの監視/履歴、チャット一覧。これは、新しいbrew install steipete/tap/imsgと上記の標準 macOS 権限だけで利用できるものです。 - Private API モード:
imsgは helper dylib をMessages.appに注入し、内部IMCore関数を呼び出します。これにより、react、edit、unsend、reply(スレッド)、sendWithEffect、pollとpoll-vote(ネイティブ Messages 投票)、renameGroup、setGroupIcon、addParticipant、removeParticipant、leaveGroupに加え、入力インジケーターと既読通知が利用可能になります。
imsg README は、この要件を明示しています。
helper 注入の手法では、read、typing、launch、ブリッジ支援のリッチ送信、メッセージ変更、チャット管理などの高度な機能はオプトインです。SIP を無効にし、helper dylib をMessages.appに注入する必要があります。SIP が有効な場合、imsg launchは注入を拒否します。
imsg 独自の dylib を使用して Messages private API に到達します。OpenClaw iMessage パスには、サードパーティサーバーや BlueBubbles ランタイムはありません。
セットアップ
-
Messages.app を実行する Mac に
imsgをインストール(またはアップグレード) します。imsg status --json出力はbridge_version、rpc_methods、およびメソッドごとのselectorsを報告するため、開始前に現在のビルドが何をサポートしているかを確認できます。 -
System Integrity Protection と、(現代の macOS では)Library Validation を無効にします。 Apple 署名済みの
Messages.appに非 Apple の helper dylib を注入するには、SIP をオフにし、かつ library validation を緩和する必要があります。Recovery モードでの SIP 手順は macOS バージョンによって異なります。- macOS 10.13-10.15(Sierra-Catalina): Terminal で Library Validation を無効化し、Recovery Mode へ再起動して
csrutil disableを実行し、再起動します。 - macOS 11+(Big Sur 以降)、Intel: Recovery Mode(または Internet Recovery)、
csrutil disable、再起動。 - macOS 11+、Apple Silicon: 電源ボタン起動シーケンスで Recovery に入ります。最近の macOS バージョンでは Continue をクリックするときに Left Shift キーを押し、その後
csrutil disableを実行します。仮想マシンのセットアップは別のフローに従うため、先に VM スナップショットを取得してください。
csrutil disableだけでは不十分です。 Apple はMessages.appをプラットフォームバイナリとして library validation の対象にし続けるため、SIP がオフでも adhoc 署名された helper は拒否されます(Library Validation failed: ... platform binary, but mapped file is not)。SIP を無効にした後、library validation も無効にして再起動します。macOS 26(Tahoe)、26.5.1 で検証済み: SIP オフに加えて上記のDisableLibraryValidationコマンドを実行すれば、26.0 から 26.5.x まで helper を注入するには十分です。boot-args は不要です。 plist が決定的な要因であり、Tahoe で注入が失敗する場合に最もよく不足している手順です。- plist あり:
imsg launchが注入し、imsg statusはadvanced_features: trueを報告します。 - plist なし(SIP がオフでも):
imsg launchはFailed to launch: Timeout waiting for Messages.app to initializeで失敗します。AMFI が読み込み時に adhoc helper を拒否するため、ブリッジは準備完了にならず、起動がタイムアウトします。このタイムアウトは Tahoe で多くの人が遭遇する症状です。修正は上記の plist であり、より抜本的な対応ではありません。
imsg launchの注入や特定のselectorsが false を返し始めた場合、このゲートが通常の原因です。SIP と library-validation の状態を確認してから、SIP 手順自体が失敗したと判断してください。これらの設定が正しくてもブリッジがまだ注入できない場合は、追加のシステム全体のセキュリティ制御を弱めるのではなく、imsg status --jsonとimsg launchの出力を収集してimsgプロジェクトに報告してください。 - macOS 10.13-10.15(Sierra-Catalina): Terminal で Library Validation を無効化し、Recovery Mode へ再起動して
-
ヘルパーを注入します。 SIP を無効にし、Messages.app にサインインした状態で:
SIP がまだ有効な場合、
imsg launchは注入を拒否するため、これは手順 2 が反映されたことの確認にもなります。 -
OpenClaw からブリッジを検証します:
iMessage の項目は
worksを報告するはずです。また、imsg status --json | jq '{rpc_methods, selectors}'は、使用している macOS ビルドが公開している機能を表示するはずです。投票作成にはselectors.pollPayloadMessageが必要です。投票にはselectors.pollVoteMessageとpoll.voteRPC メソッドの両方が必要です。OpenClaw Plugin は、キャッシュされたプローブでサポートされているアクションだけを公開します。一方、空のキャッシュは楽観的に扱われ、最初のディスパッチ時にプローブします。
openclaw channels status --probe がチャネルを works と報告しているのに、特定のアクションがディスパッチ時に「iMessage <action> requires the imsg private API bridge」を投げる場合は、imsg launch をもう一度実行してください。ヘルパーは外れることがあり (Messages.app の再起動、OS 更新など)、キャッシュされた available: true ステータスは次のプローブが更新されるまでアクションを公開し続けます。
SIP を有効のままにする場合
SIP の無効化が脅威モデル上許容できない場合:imsgは基本モードにフォールバックします — テキスト + メディア + 受信のみ。- OpenClaw Plugin は引き続きテキスト/メディア送信と受信監視を公開します。アクションサーフェスからは、メソッドごとの機能ゲートに従って
react、edit、unsend、reply、sendWithEffect、グループ操作を非表示にします。 - iMessage ワークロード用に、SIP をオフにした別の Apple-Silicon 以外の Mac (または専用ボット Mac) を実行し、主要デバイスでは SIP を有効のままにできます。下記の 専用ボット macOS ユーザー (別の iMessage ID) を参照してください。
アクセス制御とルーティング
- DM policy
- Group policy + mentions
- Sessions and deterministic replies
channels.imessage.dmPolicy はダイレクトメッセージを制御します:pairing(デフォルト)allowlist(少なくとも 1 つのallowFromエントリが必要)open(allowFromに"*"を含める必要あり)disabled
channels.imessage.allowFrom。Allowlist エントリは送信者を識別する必要があります: ハンドル、または静的送信者アクセスグループ (accessGroup:<name>)。chat_id:*、chat_guid:*、chat_identifier:* などのチャットターゲットには channels.imessage.groupAllowFrom を使用します。数値の chat_id レジストリキーには channels.imessage.groups を使用します。ACP 会話バインディング
iMessage チャットは ACP セッションにバインドできます。 高速なオペレーターフロー:- DM または許可されたグループチャット内で
/acp spawn codex --bind hereを実行します。 - 同じ iMessage 会話内の今後のメッセージは、生成された ACP セッションにルーティングされます。
/newと/resetは、同じバインド済み ACP セッションをその場でリセットします。/acp closeは ACP セッションを閉じ、バインディングを削除します。
type: "acp" と match.channel: "imessage" を持つトップレベルの bindings[] エントリを使用します。
match.peer.id には次を使用できます:
+15555550123やuser@example.comなどの正規化済み DM ハンドルchat_id:<id>(安定したグループバインディングに推奨)chat_guid:<guid>chat_identifier:<identifier>
デプロイパターン
Dedicated bot macOS user (separate iMessage identity)
Dedicated bot macOS user (separate iMessage identity)
ボットトラフィックを個人の Messages プロファイルから分離するために、専用の Apple ID と macOS ユーザーを使用します。一般的なフロー:
- 専用の macOS ユーザーを作成/サインインします。
- そのユーザーで、ボット用 Apple ID を使って Messages にサインインします。
- そのユーザーに
imsgをインストールします。 - OpenClaw がそのユーザーコンテキストで
imsgを実行できるように SSH ラッパーを作成します。 channels.imessage.accounts.<id>.cliPathと.dbPathをそのユーザープロファイルに向けます。
Remote Mac over Tailscale (example)
Remote Mac over Tailscale (example)
一般的なトポロジー:SSH と SCP の両方が非対話になるように SSH キーを使用します。
最初にホストキーを信頼済みにし (例:
- gateway は Linux/VM 上で実行されます
- iMessage +
imsgは tailnet 内の Mac 上で実行されます cliPathラッパーは SSH を使ってimsgを実行しますremoteHostは SCP 添付ファイル取得を有効にします
ssh bot@mac-mini.tailnet-1234.ts.net)、known_hosts が設定されていることを確認します。Multi-account pattern
Multi-account pattern
iMessage は
channels.imessage.accounts の下でアカウントごとの構成をサポートします。各アカウントは、cliPath、dbPath、allowFrom、groupPolicy、mediaMaxMb、履歴設定、添付ファイルルート allowlist などのフィールドを上書きできます。Direct-message history
Direct-message history
channels.imessage.dmHistoryLimit を設定すると、新しいダイレクトメッセージセッションに、その会話の最近デコードされた imsg 履歴をシードします。送信者ごとの上書きには channels.imessage.dms["<sender>"].historyLimit を使用します。送信者の履歴を無効にするには 0 を指定します。iMessage DM 履歴は、必要に応じて imsg から取得されます。dmHistoryLimit を未設定のままにすると、グローバルな DM 履歴シードは無効になりますが、送信者ごとの正の channels.imessage.dms["<sender>"].historyLimit は、その送信者のシードを引き続き有効にします。メディア、チャンク分割、配信ターゲット
添付ファイルとメディア
添付ファイルとメディア
- インバウンド添付ファイルの取り込みはデフォルトでオフです — 写真、ボイスメモ、動画、その他の添付ファイルをエージェントに転送するには、
channels.imessage.includeAttachments: trueを設定します。無効の場合、添付ファイルのみの iMessage はエージェントに届く前に破棄され、Inbound messageログ行がまったく生成されないことがあります。 remoteHostが設定されている場合、リモート添付ファイルパスは SCP 経由で取得できます- 添付ファイルパスは許可されたルートと一致する必要があります:
channels.imessage.attachmentRoots(ローカル)channels.imessage.remoteAttachmentRoots(リモート SCP モード)- 設定されたルートは、デフォルトのルートパターン
/Users/*/Library/Messages/Attachmentsを拡張します (置き換えではなくマージ)
- SCP は厳格なホストキー確認 (
StrictHostKeyChecking=yes) を使用します - アウトバウンドメディアサイズは
channels.imessage.mediaMaxMbを使用します (デフォルト 16 MB)
アウトバウンドテキストとチャンク分割
アウトバウンドテキストとチャンク分割
- テキストチャンク制限:
channels.imessage.textChunkLimit(デフォルト 4000) - チャンクモード:
channels.imessage.chunkModelength(デフォルト)newline(段落優先の分割)
- アウトバウンドの markdown 太字/斜体/下線/取り消し線はネイティブのスタイル付きテキストに変換されます (macOS 15+ の受信者はスタイルを表示し、古い受信者にはマーカーなしのプレーンテキストが表示されます)。markdown テーブルはチャンネルの markdown テーブルモードに従って変換されます
channels.imessage.sendTransport(autoデフォルト、bridge、applescript) はimsgが送信を配信する方法を選択します
アドレス指定形式
アドレス指定形式
推奨される明示的なターゲット:
chat_id:123(安定したルーティングに推奨)chat_guid:...chat_identifier:...
imessage:+1555...sms:+1555...user@example.com
プライベート API アクション
imsg launch が実行中で、openclaw channels status --probe が privateApi.available: true を報告する場合、メッセージツールは通常のテキスト送信に加えて iMessage ネイティブのアクションを使用できます。
すべてのアクションはデフォルトで有効です。個別のアクションをオフにするには channels.imessage.actions を使用します:
利用可能なアクション
利用可能なアクション
- react: iMessage tapback を追加/削除します (
messageId、emoji、remove)。サポートされる tapback は love、like、dislike、laugh、emphasize、question にマップされます。絵文字なしで削除すると、設定されていた tapback がクリアされます。 - reply: 既存メッセージへのスレッド返信を送信します (
messageId、textまたはmessage、およびchatGuid、chatId、chatIdentifier、またはto)。添付ファイル付き返信には、さらにsend-richが--fileをサポートするimsgビルドが必要です。 - sendWithEffect: iMessage エフェクト付きでテキストを送信します (
textまたはmessage、effectまたはeffectId)。短い名前: slam、loud、gentle、invisibleink、confetti、lasers、fireworks、balloon、heart、echo、happybirthday、shootingstar、sparkles、spotlight。 - edit: サポートされる macOS/プライベート API バージョンで送信済みメッセージを編集します (
messageId、textまたはnewText)。Gateway 自身が送信したメッセージのみ編集できます。 - unsend: サポートされる macOS/プライベート API バージョンで送信済みメッセージを取り消します (
messageId)。Gateway 自身が送信したメッセージのみ送信取り消しできます。 - upload-file: メディア/ファイルを送信します (
bufferは base64、またはハイドレート済みのmedia/path/filePath、filename、任意のasVoice)。レガシーエイリアス:sendAttachment。 - renameGroup、setGroupIcon、addParticipant、removeParticipant、leaveGroup: 現在のターゲットがグループ会話の場合にグループチャットを管理します。これらはホストの Messages アイデンティティを変更するため、オーナー送信者または
operator.adminGateway クライアントが必要です。 - poll: ネイティブの Apple Messages 投票を作成します (
pollQuestion、2 から 12 回繰り返すpollOption、およびchatGuid、chatId、chatIdentifier、またはto)。iOS/iPadOS/macOS 26+ の受信者はネイティブに表示して投票できます。古い OS バージョンでは「Sent a poll」というテキストフォールバックを受け取ります。selectors.pollPayloadMessageが必要です。 - poll-vote: 既存の投票に投票します (
pollIdまたはmessageId、およびpollOptionIndex、pollOptionId、pollOptionTextの正確に 1 つ)。selectors.pollVoteMessageとpoll.voteRPC メソッドが必要です。
poll-vote に必要な投票メッセージ ID とともにエージェント向けにレンダリングされます。メッセージ ID
メッセージ ID
インバウンド iMessage コンテキストには、利用可能な場合、短い
MessageSid 値と完全なメッセージ GUID (MessageSidFull) の両方が含まれます。短い ID は最近の SQLite バックの返信キャッシュにスコープされ、使用前に現在のチャットと照合されます。短い ID の有効期限が切れているか別のチャットに属する場合は、完全な MessageSidFull で再試行してください。機能検出
機能検出
OpenClaw は、キャッシュされたプローブステータスが bridge を利用不可と示す場合にのみ、プライベート API アクションを非表示にします。ステータスが不明な場合、アクションは表示されたままで、ディスパッチ時に遅延プローブを行うため、
imsg launch 後に別途手動でステータスを更新しなくても最初のアクションが成功できます。開封確認と入力中表示
開封確認と入力中表示
プライベート API bridge が起動している場合、受け入れられたインバウンドチャットは既読としてマークされ、ダイレクトチャットではターンが受け入れられるとすぐに、エージェントがコンテキストを準備して生成している間に入力中バブルが表示されます。既読マークを無効にするには:メソッド別の機能リストより前の古い
imsg ビルドでは、入力中/既読が黙って無効化されます。OpenClaw は再起動ごとに 1 回だけ警告をログに出すため、確認が欠落している原因を特定できます。インバウンド tapback
インバウンド tapback
OpenClaw は iMessage tapback を購読し、受け入れられたリアクションを通常のメッセージテキストではなくシステムイベントとしてルーティングします。そのため、ユーザーの tapback が通常の返信ループをトリガーすることはありません。通知モードは
channels.imessage.reactionNotifications で制御されます:"own"(デフォルト): ユーザーがボット作成メッセージにリアクションした場合のみ通知します。"all": 承認済み送信者からのすべてのインバウンド tapback を通知します。"off": インバウンド tapback を無視します。
channels.imessage.accounts.<id>.reactionNotifications を使用します。承認リアクション (👍 / 👎)
承認リアクション (👍 / 👎)
approvals.exec.enabled または approvals.plugin.enabled が true でリクエストが iMessage にルーティングされる場合、Gateway は承認プロンプトをネイティブに配信し、tapback を受け入れて解決します:👍(Like tapback) →allow-once👎(Dislike tapback) →denyallow-alwaysは手動フォールバックのままです: 通常の返信として/approve <id> allow-alwaysを送信します。
channels.imessage.allowFrom (または channels.imessage.accounts.<id>.allowFrom) から読み取られます。ユーザーの電話番号を E.164 形式で、または Apple ID メールを追加してください (chat_id:* のようなチャットターゲットは有効な承認者エントリではありません)。ワイルドカードエントリ "*" は尊重されますが、任意の送信者の承認を許可します。空の承認者リストはリアクションショートカットを完全に無効にします。リアクションショートカットは意図的に reactionNotifications、dmPolicy、groupAllowFrom をバイパスします。承認解決で重要なのは明示的な承認者許可リストだけだからです。/approve テキストコマンドの認可は同じリストに従います。channels.imessage.allowFrom が空でない場合、/approve <id> <decision> はその承認者リストに対して認可されます (より広い DM 許可リストではありません)。DM 許可リストでは許可されているが allowFrom に含まれない送信者は、明示的な拒否を受け取ります。allowFrom が空の場合、同一チャットフォールバックが有効なままで、/approve は DM 許可リストが許可する任意のユーザーを認可します。承認すべきすべてのオペレーターを、/approve 経由でもリアクション経由でも、allowFrom に追加してください。オペレーターノート:- リアクションバインディングはメモリと Gateway の永続的なキー付きストアの両方に保存され (TTL は承認の有効期限に合わせられます)、Gateway は保留中のプロンプトについて tapback もポーリングするため、Gateway の再起動直後に届いた tapback でも承認を解決できます。
- オペレーター自身の
is_from_me=truetapback (たとえばペアリング済み Apple デバイスからのもの) は、そのハンドルが明示的な承認者である場合に承認を解決します。 - 承認プロンプトは、明示的な承認者が設定されている場合にのみグループ会話にルーティングされます。そうでない場合、任意のグループメンバーが承認できてしまいます。
- レガシーのテキスト形式 tapback (非常に古い Apple クライアントからの
Liked "…"プレーンテキスト) は、メッセージ GUID を持たないため承認を解決できません。リアクション解決には、現在の macOS / iOS クライアントが発行する構造化 tapback メタデータが必要です。
設定書き込み
iMessage は、デフォルトでチャンネル開始の設定書き込みを許可します (commands.config: true の場合の /config set|unset 用)。
無効化:
分割送信 DM の結合 (1 つの構成内のコマンド + URL)
ユーザーがコマンドと URL を一緒に入力すると (例:Dump https://example.com/article)、Apple の Messages アプリは送信を2 つの別々の chat.db 行に分割します:
- テキストメッセージ (
"Dump")。 - OG プレビュー画像を添付ファイルとして持つ URL プレビューバルーン (
"https://...")。
imsg が導入しているものではありません。
channels.imessage.coalesceSameSenderDms は、DM で同じ送信者から連続して届く行のバッファリングを有効にします。imsg がソース行の 1 つに構造的な URL プレビューマーカー balloon_bundle_id: "com.apple.messages.URLBalloonProvider" を公開する場合、OpenClaw はその実際の分割送信だけをマージし、その他のバッファ済み行は別々のターンとして保持します。バルーンメタデータをまったく出力しない古い imsg ビルドでは、OpenClaw は分割送信と別々の送信を区別できないため、バケットのマージにフォールバックします。これにより、Dump <url> の分割送信が 2 つのターンに回帰するのではなく、メタデータ以前の動作が維持されます。グループチャットでは、複数ユーザーのターン構造を維持するため、引き続きメッセージごとにディスパッチされます。
- 有効化する場合
- 有効化
- Trade-offs
次の場合に有効化します:
- 1 つのメッセージ内の
command + payloadを想定するスキル (dump、paste、save、queue など) を提供している。 - ユーザーがコマンドと一緒に URL を貼り付ける。
- 追加される DM ターン遅延を許容できる (以下を参照)。
- 単語 1 つの DM トリガーで最小のコマンド遅延が必要。
- すべてのフローがペイロードのフォローアップなしのワンショットコマンドである。
シナリオとエージェントに見える内容
「フラグオン」列は、balloon_bundle_id を出力する imsg ビルドでの動作を示します。バルーンメタデータをまったく出力しない古い imsg ビルドでは、下記で「2 ターン」/「N ターン」と示されている行は、代わりにレガシーマージ(1 ターン)にフォールバックします。OpenClaw は分割送信と個別送信を構造的に判別できないため、メタデータ導入前のマージを保持します。ビルドがバルーンメタデータを出力するようになると、正確な分離が有効になります。
| ユーザーの作成内容 | chat.db の生成内容 | フラグオフ(デフォルト) | フラグオン + ウィンドウ(imsg がバルーンメタデータを出力) |
|---|---|---|---|
Dump https://example.com(1 回の送信) | 約 1 秒間隔で 2 行 | 2 つのエージェントターン: 「Dump」のみ、その後 URL | 1 ターン: マージされたテキスト Dump https://example.com |
Save this 📎image.jpg caption(添付ファイル + テキスト) | URL バルーンメタデータなしで 2 行 | 2 ターン | メタデータが観測された後は 2 ターン。古い/ラッチ前のメタデータなしセッションでは 1 つのマージターン |
/status(単独コマンド) | 1 行 | 即時ディスパッチ | 最大でウィンドウまで待機し、その後ディスパッチ |
| URL のみを貼り付け | 1 行 | 即時ディスパッチ | 最大でウィンドウまで待機し、その後ディスパッチ |
| テキスト + URL を数分空けて意図的に 2 つの別メッセージとして送信 | ウィンドウ外で 2 行 | 2 ターン | 2 ターン(その間にウィンドウが期限切れ) |
| 高速大量送信(ウィンドウ内に 10 件超の短い DM) | URL バルーンメタデータなしで N 行 | N ターン | メタデータが観測された後は N ターン。古い/ラッチ前のメタデータなしセッションでは上限付きの 1 つのマージターン |
| グループチャットで 2 人が入力 | M 人の送信者から N 行 | M+ ターン(送信者バケットごとに 1 つ) | M+ ターン — グループチャットは結合されません |
ブリッジまたは Gateway 再起動後のインバウンド復旧
iMessage は Gateway の停止中に取り逃したメッセージを復旧し、同時に Push 復旧後に Apple が吐き出すことがある古い「バックログ爆弾」を抑制します。デフォルトの動作は常に有効で、インバウンド重複排除の上に構築されています。- リプレイ重複排除。 ディスパッチされたすべてのインバウンドメッセージは、その Apple GUID によって永続 Plugin 状態(
imessage.inbound-dedupe)に記録され、取り込み時に確保され、処理後にコミットされます(一時的な失敗時はリトライできるよう解放されます)。すでに処理済みのものは、二重にディスパッチされる代わりに破棄されます。これにより、メッセージ単位の帳簿管理なしで復旧リプレイを積極的に行えます。 - ダウンタイム復旧。 起動時にモニターは最後にディスパッチした
chat.dbrowid(アカウントごとに永続化されたカーソル)を記憶し、それをsince_rowidとしてimsg watch.subscribeに渡します。これにより、Gateway が停止している間に到着した行を imsg がリプレイし、その後ライブで追尾します。リプレイは直近 500 行まで、かつ約 2 時間前までのメッセージに制限され、重複排除によって処理済みのものは破棄されます。 - 古いバックログの年齢フェンス。 起動境界より上の行は本当にライブです。送信日時が到着時刻より約 15 分以上古いものは Push フラッシュのバックログであり、抑制されます。リプレイされた行(境界以下)は代わりにより広い復旧ウィンドウを使用するため、最近取り逃したメッセージは配信され、古い履歴は配信されません。
cliPath セットアップで機能します。since_rowid リプレイは同じ imsg RPC 接続上で実行されるためです。違いはウィンドウです。Gateway が chat.db を読み取れる場合(ローカル)、起動時 rowid 境界を固定し、リプレイ範囲に上限を設け、最大で数時間前までの取り逃したメッセージを配信します。リモート SSH cliPath 経由ではデータベースを読み取れないため、リプレイに上限はなく、すべての行がライブ年齢フェンスを使用します。それでも最近取り逃したメッセージは復旧し、古いバックログも抑制しますが、より狭いライブウィンドウになります。より広い復旧ウィンドウを使うには、Messages の Mac 上で Gateway を実行してください。
オペレーターに見えるシグナル
抑制されたバックログはデフォルトレベルでログに記録され、黙って破棄されることはありません(recovery フラグはどのウィンドウが適用されたかを示します)。
移行
channels.imessage.catchup.* は非推奨です。ダウンタイム復旧は自動であり、新しいセットアップでは設定不要です。catchup.enabled: true を含む既存設定は、復旧リプレイウィンドウの互換プロファイルとして引き続き尊重されます。無効な catchup ブロック(enabled: false または enabled: true なし)は廃止され、openclaw doctor --fix がそれらを削除します。
トラブルシューティング
imsg not found or RPC unsupported
imsg not found or RPC unsupported
バイナリと RPC サポートを検証します。プローブで RPC 非対応と報告される場合は、
imsg を更新してください。private API アクションを利用できない場合は、ログイン済み macOS ユーザーセッションで imsg launch を実行し、再度プローブしてください。Gateway が macOS 上で実行されていない場合は、デフォルトのローカル imsg パスではなく、上記の SSH 経由のリモート Mac セットアップを使用してください。Messages send but inbound iMessages do not arrive
Messages send but inbound iMessages do not arrive
まず、メッセージがローカル Mac に到達したかどうかを確認します。電話から送信したメッセージで新しい行が作成されない場合は、OpenClaw 設定を変更する前に macOS Messages と Apple Push レイヤーを修復してください。多くの場合、1 回限りのサービス更新で十分です。OpenClaw セッションをデバッグする前に、電話から新しい iMessage を送信し、新しい
chat.db が変化しない場合、imsg status --json が正常なブリッジを報告していても、OpenClaw はそのメッセージを受信できません。chat.db 行または imsg watch イベントを確認してください。これを定期的なブリッジ再起動ループとして実行しないでください。作業中に imsg launch と Gateway 再起動を繰り返すと、配信が中断され、進行中のチャンネル実行が取り残される可能性があります。Gateway is not running on macOS
Gateway is not running on macOS
デフォルトの 次に実行します。
cliPath: "imsg" は、Messages にサインインしている Mac 上で実行する必要があります。Linux または Windows では、channels.imessage.cliPath を、その Mac に SSH して imsg "$@" を実行するラッパースクリプトに設定してください。DMs are ignored
DMs are ignored
次を確認してください。
channels.imessage.dmPolicychannels.imessage.allowFrom- ペアリング承認(
openclaw pairing list imessage)
Group messages are ignored
Group messages are ignored
次を確認してください。
channels.imessage.groupPolicychannels.imessage.groupAllowFromchannels.imessage.groups許可リストの動作- メンションパターン設定(
agents.list[].groupChat.mentionPatterns)
Remote attachments fail
Remote attachments fail
次を確認してください。
channels.imessage.remoteHostchannels.imessage.remoteAttachmentRoots- Gateway ホストからの SSH/SCP キー認証
- Gateway ホスト上の
~/.ssh/known_hostsにホストキーが存在すること - Messages を実行している Mac 上でリモートパスを読み取れること
macOS permission prompts were missed
macOS permission prompts were missed
同じユーザー/セッションコンテキストの対話型 GUI ターミナルで再実行し、プロンプトを承認します。OpenClaw/
imsg を実行するプロセスコンテキストに、フルディスクアクセス + オートメーションが付与されていることを確認してください。設定リファレンスへのポインター
関連
- チャンネル概要 — サポートされているすべてのチャンネル
- BlueBubbles の削除と imsg iMessage パス — 告知と移行の概要
- BlueBubbles からの移行 — 設定変換表と段階的な切り替え
- ペアリング — DM 認証とペアリングフロー
- グループ — グループチャットの動作とメンションゲート
- チャンネルルーティング — メッセージのセッションルーティング
- セキュリティ — アクセスモデルと強化