Перейти до основного вмісту

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.

Для розгортань OpenClaw iMessage використовуйте imsg на хості macOS Messages із виконаним входом. Якщо ваш Gateway працює на Linux або Windows, вкажіть channels.imessage.cliPath на SSH-обгортку, яка запускає imsg на Mac.Надолуження після простою Gateway вмикається явно. Коли ввімкнено (channels.imessage.catchup.enabled: true), gateway під час наступного запуску відтворює вхідні повідомлення, що потрапили до chat.db, поки він був офлайн (збій, перезапуск, сон Mac). Типово вимкнено — див. Надолуження після простою gateway. Закриває openclaw#78649.
Підтримку BlueBubbles було вилучено. Перенесіть конфігурації channels.bluebubbles до channels.imessage; OpenClaw підтримує iMessage лише через imsg. Почніть із Вилучення BlueBubbles і шлях imsg для iMessage для короткого оголошення або Перехід із BlueBubbles для повної таблиці міграції.
Стан: нативна інтеграція із зовнішнім CLI. Gateway запускає imsg rpc і взаємодіє через JSON-RPC у stdio (без окремого демона/порту). Розширені дії потребують imsg launch і успішної перевірки приватного API.

Дії приватного API

Відповіді, tapback-реакції, ефекти, вкладення та керування групами.

Сполучення

Особисті повідомлення iMessage типово використовують режим сполучення.

Віддалений Mac

Використовуйте SSH-обгортку, коли Gateway не запущено на Mac із Messages.

Довідник конфігурації

Повний довідник полів iMessage.

Швидке налаштування

1

Установіть і перевірте imsg

brew install steipete/tap/imsg
imsg rpc --help
imsg launch
openclaw channels status --probe
2

Налаштуйте OpenClaw

{
  channels: {
    imessage: {
      enabled: true,
      cliPath: "/usr/local/bin/imsg",
      dbPath: "/Users/user/Library/Messages/chat.db",
    },
  },
}
3

Запустіть gateway

openclaw gateway
4

Підтвердьте перше сполучення DM (типовий dmPolicy)

openclaw pairing list imessage
openclaw pairing approve imessage <CODE>
Запити на сполучення спливають через 1 годину.

Вимоги та дозволи (macOS)

  • На Mac, де запускається imsg, має бути виконано вхід у Messages.
  • Для контексту процесу, що запускає OpenClaw/imsg, потрібен повний доступ до диска (доступ до БД Messages).
  • Для надсилання повідомлень через Messages.app потрібен дозвіл на автоматизацію.
  • Для розширених дій (реакція / редагування / скасування надсилання / відповідь у треді / ефекти / групові операції) потрібно вимкнути System Integrity Protection — див. Увімкнення приватного API imsg нижче. Базове надсилання й отримання тексту та медіа працює без цього.
Дозволи надаються для кожного контексту процесу. Якщо gateway працює без інтерфейсу (LaunchAgent/SSH), виконайте одноразову інтерактивну команду в тому самому контексті, щоб викликати запити дозволів:
imsg chats --limit 1
# or
imsg send <handle> "test"

Увімкнення приватного API imsg

imsg постачається у двох робочих режимах:
  • Базовий режим (типовий, зміни SIP не потрібні): вихідні текст і медіа через send, вхідне спостереження/історія, список чатів. Це те, що ви отримуєте одразу після свіжого brew install steipete/tap/imsg плюс стандартні дозволи macOS, наведені вище.
  • Режим приватного API: imsg інжектує допоміжну dylib у Messages.app, щоб викликати внутрішні функції IMCore. Саме це розблоковує react, edit, unsend, reply (у треді), sendWithEffect, renameGroup, setGroupIcon, addParticipant, removeParticipant, leaveGroup, а також індикатори введення та сповіщення про прочитання.
Щоб отримати поверхню розширених дій, описану на цій сторінці каналу, потрібен режим приватного API. README imsg прямо вказує на цю вимогу:
Розширені можливості, як-от read, typing, launch, розширене надсилання через міст, зміна повідомлень і керування чатами, вмикаються явно. Вони потребують вимкненого SIP і допоміжної dylib, інжектованої в Messages.app. imsg launch відмовляється виконувати інжекцію, коли SIP увімкнено.
Техніка інжекції helper використовує власну dylib imsg, щоб отримати доступ до приватних API Messages. У шляху OpenClaw iMessage немає стороннього сервера чи середовища виконання BlueBubbles.
Вимкнення SIP є реальним компромісом безпеки. SIP є одним із ключових захистів macOS від запуску зміненого системного коду; його загальносистемне вимкнення відкриває додаткову площу атаки та побічні ефекти. Зокрема, вимкнення SIP на Mac з Apple Silicon також вимикає можливість установлювати й запускати iOS-застосунки на вашому Mac.Ставтеся до цього як до свідомого операційного вибору, а не як до типового режиму. Якщо ваша модель загроз не допускає вимкнення SIP, вбудований iMessage обмежується базовим режимом — лише надсилання й отримання тексту та медіа, без реакцій / редагування / скасування надсилання / ефектів / групових операцій.

Налаштування

  1. Установіть (або оновіть) imsg на Mac, де працює Messages.app:
    brew install steipete/tap/imsg
    imsg --version
    imsg status --json
    
    Вивід imsg status --json повідомляє bridge_version, rpc_methods і selectors для кожного методу, щоб ви могли побачити, що підтримує поточна збірка, перш ніж почати.
  2. Вимкніть System Integrity Protection. Це залежить від версії macOS, бо базова вимога Apple залежить від ОС і обладнання:
    • macOS 10.13–10.15 (Sierra–Catalina): вимкніть Library Validation через Terminal, перезавантажтеся в Recovery Mode, виконайте csrutil disable, перезапустіть.
    • macOS 11+ (Big Sur і новіші), Intel: Recovery Mode (або Internet Recovery), csrutil disable, перезапустіть.
    • macOS 11+, Apple Silicon: послідовність запуску з кнопкою живлення для входу в Recovery; у новіших версіях macOS утримуйте клавішу Left Shift, коли натискаєте Continue, потім csrutil disable. Налаштування віртуальних машин мають окремий процес — спочатку зробіть знімок VM.
    • macOS 26 / Tahoe: політики library-validation і перевірки приватних entitlement для imagent стали ще суворішими; imsg може потребувати оновленої збірки, щоб не відставати. Якщо інжекція imsg launch або конкретні selectors починають повертати false після великого оновлення macOS, перевірте примітки до випуску imsg, перш ніж вважати, що крок SIP успішно виконано.
    Дотримуйтеся процесу Apple Recovery-mode для вашого Mac, щоб вимкнути SIP перед запуском imsg launch.
  3. Інжектуйте helper. Коли SIP вимкнено і в Messages.app виконано вхід:
    imsg launch
    
    imsg launch відмовляється виконувати інжекцію, коли SIP досі увімкнено, тож це також слугує підтвердженням, що крок 2 спрацював.
  4. Перевірте міст з OpenClaw:
    openclaw channels status --probe
    
    Запис iMessage має повідомляти works, а imsg status --json | jq '.selectors' має показувати retractMessagePart: true плюс ті селектори редагування / введення / прочитання, які надає ваша збірка macOS. Поштучне gating методів у Plugin OpenClaw в actions.ts рекламує лише дії, базовий селектор яких дорівнює true, тож поверхня дій, яку ви бачите в списку інструментів агента, відображає те, що міст реально може виконати на цьому хості.
Якщо openclaw channels status --probe повідомляє, що канал має стан works, але конкретні дії під час dispatch викидають “iMessage <action> requires the imsg private API bridge”, запустіть imsg launch ще раз — helper може зникнути (перезапуск Messages.app, оновлення ОС тощо), а кешований статус available: true продовжуватиме рекламувати дії до наступного оновлення probe.

Коли ви не можете вимкнути SIP

Якщо вимкнений SIP неприйнятний для вашої моделі загроз:
  • imsg повертається до базового режиму — лише текст + медіа + отримання.
  • Plugin OpenClaw усе ще рекламує надсилання тексту/медіа та моніторинг вхідних повідомлень; він просто приховує react, edit, unsend, reply, sendWithEffect і групові операції з поверхні дій (відповідно до gate можливостей для кожного методу).
  • Ви можете запустити окремий Mac без Apple Silicon (або виділений bot Mac) з вимкненим SIP для навантаження iMessage, залишивши SIP увімкненим на основних пристроях. Див. Виділений користувач macOS для бота (окрема ідентичність iMessage) нижче.

Контроль доступу та маршрутизація

channels.imessage.dmPolicy керує особистими повідомленнями:
  • pairing (типово)
  • allowlist
  • open (потребує, щоб allowFrom містив "*")
  • disabled
Поле списку дозволених: channels.imessage.allowFrom.Записи списку дозволених мають ідентифікувати відправників: handles або статичні групи доступу відправників (accessGroup:<name>). Використовуйте channels.imessage.groupAllowFrom для цілей чату, як-от chat_id:*, chat_guid:* або chat_identifier:*; використовуйте channels.imessage.groups для числових ключів реєстру chat_id.

Прив’язки розмов ACP

Застарілі чати iMessage також можна прив’язувати до сесій ACP. Швидкий операторський процес:
  • Запустіть /acp spawn codex --bind here у DM або дозволеному груповому чаті.
  • Майбутні повідомлення в тій самій розмові iMessage маршрутизуватимуться до створеної сесії ACP.
  • /new і /reset скидають ту саму прив’язану сесію ACP на місці.
  • /acp close закриває сесію ACP і видаляє прив’язку.
Налаштовані постійні прив’язки підтримуються через записи верхнього рівня bindings[] з type: "acp" і match.channel: "imessage". match.peer.id може використовувати:
  • нормалізований ідентифікатор DM, наприклад +15555550123 або user@example.com
  • chat_id:<id> (рекомендовано для стабільних групових прив’язок)
  • chat_guid:<guid>
  • chat_identifier:<identifier>
Приклад:
{
  agents: {
    list: [
      {
        id: "codex",
        runtime: {
          type: "acp",
          acp: { agent: "codex", backend: "acpx", mode: "persistent" },
        },
      },
    ],
  },
  bindings: [
    {
      type: "acp",
      agentId: "codex",
      match: {
        channel: "imessage",
        accountId: "default",
        peer: { kind: "group", id: "chat_id:123" },
      },
      acp: { label: "codex-group" },
    },
  ],
}
Див. Агенти ACP щодо спільної поведінки прив’язок ACP.

Шаблони розгортання

Використовуйте виділений Apple ID і користувача macOS, щоб трафік бота був ізольований від вашого особистого профілю Messages.Типовий процес:
  1. Створіть/увійдіть у виділеного користувача macOS.
  2. Увійдіть у Messages з Apple ID бота в цьому користувачі.
  3. Установіть imsg у цьому користувачі.
  4. Створіть SSH-обгортку, щоб OpenClaw міг запускати imsg у контексті цього користувача.
  5. Спрямуйте channels.imessage.accounts.<id>.cliPath і .dbPath на профіль цього користувача.
Перший запуск може вимагати схвалень у GUI (Automation + Full Disk Access) у сесії цього користувача бота.
Поширена топологія:
  • gateway працює на Linux/VM
  • iMessage + imsg працює на Mac у вашій tailnet
  • обгортка cliPath використовує SSH для запуску imsg
  • remoteHost вмикає отримання вкладень через SCP
Приклад:
{
  channels: {
    imessage: {
      enabled: true,
      cliPath: "~/.openclaw/scripts/imsg-ssh",
      remoteHost: "bot@mac-mini.tailnet-1234.ts.net",
      includeAttachments: true,
      dbPath: "/Users/bot/Library/Messages/chat.db",
    },
  },
}
#!/usr/bin/env bash
exec ssh -T bot@mac-mini.tailnet-1234.ts.net imsg "$@"
Використовуйте SSH-ключі, щоб і SSH, і SCP були неінтерактивними. Спочатку переконайтеся, що ключ хоста довірений (наприклад, ssh bot@mac-mini.tailnet-1234.ts.net), щоб known_hosts було заповнено.
iMessage підтримує налаштування для окремих облікових записів у channels.imessage.accounts.Кожен обліковий запис може перевизначати поля, як-от cliPath, dbPath, allowFrom, groupPolicy, mediaMaxMb, налаштування історії та allowlist коренів вкладень.

Медіа, розбиття на частини та цілі доставлення

  • приймання вхідних вкладень вимкнене за замовчуванням — задайте channels.imessage.includeAttachments: true, щоб пересилати фото, голосові нотатки, відео та інші вкладення агенту. Коли це вимкнено, iMessage лише з вкладеннями відкидаються до потрапляння до агента й можуть узагалі не створювати рядок журналу Inbound message.
  • віддалені шляхи вкладень можна отримувати через SCP, коли встановлено remoteHost
  • шляхи вкладень мають відповідати дозволеним кореням:
    • 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.chunkMode
    • length (типово)
    • newline (розділення спочатку за абзацами)
Бажані явні цілі:
  • chat_id:123 (рекомендовано для стабільного маршрутизування)
  • chat_guid:...
  • chat_identifier:...
Цілі-ідентифікатори також підтримуються:
  • imessage:+1555...
  • sms:+1555...
  • user@example.com
imsg chats --limit 20

Дії Private API

Коли imsg launch запущено, а openclaw channels status --probe повідомляє privateApi.available: true, інструмент повідомлень може використовувати нативні для iMessage дії на додачу до звичайного надсилання тексту.
{
  channels: {
    imessage: {
      actions: {
        reactions: true,
        edit: true,
        unsend: true,
        reply: true,
        sendWithEffect: true,
        sendAttachment: true,
        renameGroup: true,
        setGroupIcon: true,
        addParticipant: true,
        removeParticipant: true,
        leaveGroup: true,
      },
    },
  },
}
  • react: додати/видалити tapback iMessage (messageId, emoji, remove). Підтримувані tapback відповідають love, like, dislike, laugh, emphasize і question.
  • reply: надіслати відповідь у потоці на наявне повідомлення (messageId, text або message, плюс chatGuid, chatId, chatIdentifier або to).
  • sendWithEffect: надіслати текст з ефектом iMessage (text або message, effect або effectId).
  • edit: редагувати надіслане повідомлення на підтримуваних версіях macOS/Private API (messageId, text або newText).
  • unsend: відкликати надіслане повідомлення на підтримуваних версіях macOS/Private API (messageId).
  • upload-file: надіслати медіа/файли (buffer як base64 або гідратований media/path/filePath, filename, необов’язково asVoice). Застарілий псевдонім: sendAttachment.
  • renameGroup, setGroupIcon, addParticipant, removeParticipant, leaveGroup: керувати груповими чатами, коли поточна ціль є груповою розмовою.
Контекст вхідного iMessage містить і короткі значення MessageSid, і повні GUID повідомлень, коли вони доступні. Короткі ID обмежені нещодавнім кешем відповідей у пам’яті та перевіряються щодо поточного чату перед використанням. Якщо короткий ID застарів або належить іншому чату, повторіть спробу з повним MessageSidFull.
OpenClaw приховує дії Private API лише тоді, коли кешований стан перевірки вказує, що міст недоступний. Якщо стан невідомий, дії залишаються видимими, а dispatch запускає перевірки ліниво, щоб перша дія могла успішно виконатися після imsg launch без окремого ручного оновлення стану.
Коли міст Private API працює, прийняті вхідні чати позначаються прочитаними перед dispatch, а відправнику показується індикатор набору, поки агент генерує відповідь. Вимкніть позначення прочитання за допомогою:
{
  channels: {
    imessage: {
      sendReadReceipts: false,
    },
  },
}
Старіші збірки imsg, які передують списку можливостей для окремих методів, тихо вимикатимуть індикатор набору/прочитання; OpenClaw записує одноразове попередження за перезапуск, щоб відсутність підтвердження прочитання можна було пояснити.
OpenClaw підписується на tapback iMessage і маршрутизує прийняті реакції як системні події замість звичайного тексту повідомлення, тому tapback користувача не запускає звичайний цикл відповідей.Режим сповіщень контролюється channels.imessage.reactionNotifications:
  • "own" (типово): сповіщати лише коли користувачі реагують на повідомлення, створені ботом.
  • "all": сповіщати про всі вхідні tapback від авторизованих відправників.
  • "off": ігнорувати вхідні tapback.
Перевизначення для окремих облікових записів використовують channels.imessage.accounts.<id>.reactionNotifications.

Записи конфігурації

iMessage за замовчуванням дозволяє ініційовані каналом записи конфігурації (для /config set|unset, коли commands.config: true). Вимкнути:
{
  channels: {
    imessage: {
      configWrites: false,
    },
  },
}

Об’єднання розділених DM (команда + URL в одній композиції)

Коли користувач вводить команду й URL разом — наприклад, Dump https://example.com/article — застосунок Messages від Apple розділяє надсилання на два окремі рядки chat.db:
  1. Текстове повідомлення ("Dump").
  2. Кулька попереднього перегляду URL ("https://...") із зображеннями OG-preview як вкладеннями.
Два рядки надходять до OpenClaw з інтервалом приблизно 0,8-2,0 с у більшості налаштувань. Без об’єднання агент отримує саму команду на кроці 1, відповідає (часто «надішліть мені URL») і бачить URL лише на кроці 2 — коли контекст команди вже втрачено. Це конвеєр надсилання Apple, а не щось, що додають OpenClaw або imsg. channels.imessage.coalesceSameSenderDms вмикає для DM об’єднання послідовних рядків від того самого відправника в один крок агента. Групові чати й далі надсилаються повідомлення за повідомленням, щоб зберегти структуру кроків із кількома користувачами.
Увімкніть, коли:
  • Ви постачаєте Skills, які очікують command + payload в одному повідомленні (dump, paste, save, queue тощо).
  • Ваші користувачі вставляють URL, зображення або довгий вміст разом із командами.
  • Ви можете прийняти додану затримку кроку DM (див. нижче).
Залиште вимкненим, коли:
  • Вам потрібна мінімальна затримка команди для однословних тригерів DM.
  • Усі ваші потоки — це одноразові команди без подальших payload.

Сценарії та що бачить агент

Користувач створюєchat.db створюєПрапорець вимкнено (за замовчуванням)Прапорець увімкнено + вікно 2500 мс
Dump https://example.com (одне надсилання)2 рядки з інтервалом ~1 сДва кроки агента: лише “Dump”, потім URLОдин крок: об’єднаний текст Dump https://example.com
Save this 📎image.jpg caption (вкладення + текст)2 рядкиДва кроки (вкладення скинуто під час об’єднання)Один крок: текст + зображення збережено
/status (окрема команда)1 рядокМиттєве надсиланняОчікування до завершення вікна, потім надсилання
URL вставлено окремо1 рядокМиттєве надсиланняМиттєве надсилання (лише один запис у bucket)
Текст + URL надіслано як два навмисно окремі повідомлення з різницею в хвилини2 рядки поза вікномДва крокиДва кроки (вікно спливає між ними)
Швидкий потік (>10 малих DM у межах вікна)N рядківN кроківОдин крок, обмежений вивід (перший + найновіші, застосовано обмеження тексту/вкладень)
Двоє людей друкують у груповому чатіN рядків від M відправниківM+ кроків (по одному на bucket відправника)M+ кроків — групові чати не об’єднуються

Надолуження після простою Gateway

Коли Gateway офлайн (збій, перезапуск, сон Mac, вимкнена машина), imsg watch після повернення Gateway відновлюється з поточного стану chat.db — усе, що надійшло під час прогалини, за замовчуванням ніколи не буде побачено. Catchup відтворює ці повідомлення під час наступного запуску, щоб агент не пропускав вхідний трафік мовчки. Catchup вимкнено за замовчуванням. Увімкніть його для окремого каналу:
channels: {
  imessage: {
    catchup: {
      enabled: true,             // master switch (default: false)
      maxAgeMinutes: 120,        // skip rows older than now - 2h (default: 120, clamp 1..720)
      perRunLimit: 50,           // max rows replayed per startup (default: 50, clamp 1..500)
      firstRunLookbackMinutes: 30, // first run with no cursor: look back 30 min (default: 30)
      maxFailureRetries: 10,     // give up on a wedged guid after 10 dispatch failures (default: 10)
    },
  },
}

Як це виконується

Один прохід на кожен запуск monitorIMessageProvider, послідовність така: готовність imsg launchwatch.subscribeperformIMessageCatchup → цикл live-надсилання. Сам Catchup використовує chats.list + messages.history для кожного чату через той самий JSON-RPC-клієнт, який використовує imsg watch. Усе, що надходить під час проходу Catchup, проходить через live-надсилання у звичайному режимі; наявний кеш inbound-dedupe поглинає будь-яке перекриття з відтвореними рядками. Кожен відтворений рядок подається через live-шлях надсилання (evaluateIMessageInbound + dispatchInboundMessage), тож allowlist, політика груп, debouncer, echo cache і сповіщення про прочитання поводяться однаково для відтворених і live-повідомлень.

Семантика курсора й повторів

Catchup зберігає курсор для кожного облікового запису в <openclawStateDir>/imessage/catchup/<account>__<hash>.json (каталог стану OpenClaw за замовчуванням — ~/.openclaw, можна перевизначити через OPENCLAW_STATE_DIR):
{
  "lastSeenMs": 1717900800000,
  "lastSeenRowid": 482910,
  "updatedAt": 1717900801234,
  "failureRetries": { "<guid>": 1 }
}
  • Курсор просувається після кожного успішного надсилання й утримується, коли надсилання рядка кидає помилку — наступний запуск повторює той самий рядок із утриманого курсора.
  • Після maxFailureRetries послідовних помилок для того самого guid, Catchup записує warn і примусово просуває курсор повз застрягле повідомлення, щоб подальші запуски могли рухатися далі.
  • GUID, щодо яких уже відмовилися, пропускаються відразу (без спроби надсилання) у подальших запусках і враховуються в skippedGivenUp у підсумку запуску.

Сигнали, видимі оператору

imessage catchup: replayed=N skippedFromMe=… skippedGivenUp=… failed=… givenUp=… fetchedCount=…
imessage catchup: giving up on guid=<guid> after <N> failures; advancing cursor past it
imessage catchup: fetched <X> rows across chats, capped to perRunLimit=<Y>
Рядок WARN ... capped to perRunLimit означає, що один запуск не вичерпав увесь backlog. Збільште perRunLimit (макс. 500), якщо ваші прогалини регулярно перевищують стандартний прохід у 50 рядків.

Коли залишити вимкненим

  • Gateway працює безперервно з автоматичним перезапуском через watchdog, а прогалини завжди < кількох секунд — стандартне вимкнене значення підходить.
  • Обсяг DM низький, і пропущені повідомлення не змінять поведінку агента — початкове вікно firstRunLookbackMinutes може надіслати неочікуваний старий контекст під час першого ввімкнення.
Коли ви вмикаєте Catchup, перший запуск без курсора дивиться назад лише на firstRunLookbackMinutes (30 хв за замовчуванням), а не на повне вікно maxAgeMinutes — це запобігає відтворенню довгої історії повідомлень, що передували ввімкненню.

Усунення несправностей

Перевірте бінарний файл і підтримку RPC:
imsg rpc --help
imsg status --json
openclaw channels status --probe
Якщо probe повідомляє, що RPC не підтримується, оновіть imsg. Якщо дії приватного API недоступні, запустіть imsg launch у сеансі користувача macOS, який увійшов у систему, і знову виконайте probe. Якщо Gateway не працює на macOS, використайте налаштування віддаленого Mac через SSH вище замість стандартного локального шляху imsg.
Стандартний cliPath: "imsg" має виконуватися на Mac, який увійшов у Messages. На Linux або Windows встановіть channels.imessage.cliPath на wrapper-скрипт, який підключається до цього Mac через SSH і запускає imsg "$@".
#!/usr/bin/env bash
exec ssh -T messages-mac imsg "$@"
Потім виконайте:
openclaw channels status --probe --channel imessage
Перевірте:
  • channels.imessage.dmPolicy
  • channels.imessage.allowFrom
  • схвалення pairing (openclaw pairing list imessage)
Перевірте:
  • channels.imessage.groupPolicy
  • channels.imessage.groupAllowFrom
  • поведінку allowlist channels.imessage.groups
  • конфігурацію шаблонів згадок (agents.list[].groupChat.mentionPatterns)
Перевірте:
  • channels.imessage.remoteHost
  • channels.imessage.remoteAttachmentRoots
  • автентифікацію SSH/SCP-ключем із хоста Gateway
  • наявність ключа хоста в ~/.ssh/known_hosts на хості Gateway
  • доступність віддаленого шляху для читання на Mac, де працює Messages
Повторно запустіть в інтерактивному GUI-терміналі в тому самому контексті користувача/сеансу й підтвердьте запити:
imsg chats --limit 1
imsg send <handle> "test"
Підтвердьте, що Full Disk Access + Automation надано для контексту процесу, який запускає OpenClaw/imsg.

Вказівники довідника конфігурації

Пов’язане