​

Usunięcie BlueBubbles i obsługa iMessage przez imsg

OpenClaw nie zawiera już kanału BlueBubbles. Obsługa iMessage odbywa się za pośrednictwem dołączonego pluginu imessage: Gateway uruchamia imsg jako proces potomny, lokalnie lub przez skrypt opakowujący SSH, i komunikuje się za pomocą JSON-RPC przez standardowe wejście i wyjście. Bez serwera, bez webhooka, bez portu. Jeśli konfiguracja nadal zawiera channels.bluebubbles, przenieś ją do channels.imessage. Starszy adres dokumentacji /channels/bluebubbles przekierowuje do strony Migracja z BlueBubbles, która zawiera pełną tabelę translacji konfiguracji i listę kontrolną przełączenia.

​

Co się zmieniło

• Obsługiwana ścieżka iMessage nie korzysta z serwera HTTP BlueBubbles, trasy webhooka, hasła REST ani środowiska uruchomieniowego pluginu BlueBubbles.
• OpenClaw odczytuje i monitoruje Wiadomości za pośrednictwem imsg na Macu, na którym użytkownik jest zalogowany w aplikacji Messages.app.
• Podstawowe wysyłanie, odbieranie, historia i multimedia korzystają ze standardowych funkcji imsg oraz uprawnień systemu macOS.
• Zaawansowane działania (odpowiedzi w wątkach, reakcje tapback, edycja, cofanie wysłania, efekty, potwierdzenia odczytu, wskaźniki pisania i zarządzanie grupami) wymagają mostu prywatnego API: uruchom imsg launch, co wymaga wyłączenia SIP.
• Gatewaye działające w systemach Linux i Windows nadal mogą korzystać z iMessage, jeśli channels.imessage.cliPath wskazuje skrypt opakowujący SSH, który uruchamia imsg na zalogowanym Macu.

​

Co zrobić

1. Zainstaluj i zweryfikuj imsg na Macu z aplikacją Wiadomości:
   brew install steipete/tap/imsg
   imsg --version
   imsg chats --limit 3
   imsg rpc --help
   
2. Przyznaj uprawnienia Full Disk Access i Automation kontekstowi procesu, w którym działają imsg i OpenClaw.
3. Przenieś starą konfigurację:
   {
     channels: {
       imessage: {
         enabled: true,
         cliPath: "/opt/homebrew/bin/imsg",
         dmPolicy: "pairing",
         allowFrom: ["+15555550123"],
         groupPolicy: "allowlist",
         groupAllowFrom: ["+15555550123"],
         groups: {
           "*": { requireMention: true },
         },
         includeAttachments: true,
       },
     },
   }
   
4. Uruchom ponownie Gateway i zweryfikuj działanie:
   openclaw channels status --probe
   
5. Przed usunięciem starego serwera BlueBubbles przetestuj wiadomości prywatne, grupy, załączniki oraz wszystkie używane działania prywatnego API.

​

Uwagi dotyczące migracji

• channels.bluebubbles.serverUrl i channels.bluebubbles.password nie mają odpowiedników w iMessage; nie ma serwera, z którym trzeba się łączyć ani uwierzytelniać.
• allowFrom, groupAllowFrom, groups, includeAttachments, attachmentRoots, mediaMaxMb, textChunkLimit i actions.* zachowują swoje znaczenie w channels.imessage.
• Opcja channels.imessage.includeAttachments jest nadal domyślnie wyłączona. Ustaw ją jawnie, jeśli przychodzące zdjęcia, notatki głosowe, filmy lub pliki mają trafiać do agenta.
• W przypadku groupPolicy: "allowlist" skopiuj stary blok groups, w tym ewentualny wpis wieloznaczny "*". Listy dozwolonych nadawców grupowych i rejestr grup stanowią oddzielne mechanizmy kontroli dostępu; blok groups zawierający wpisy, ale bez pasującego chat_id (lub bez "*") powoduje odrzucenie wiadomości podczas działania, a pusty blok groups generuje ostrzeżenie przy uruchamianiu, mimo że filtrowanie nadawców nadal przepuszcza wiadomości.
• Powiązania ACP z match.channel: "bluebubbles" należy zmienić na "imessage".
• Stare klucze sesji BlueBubbles nie stają się kluczami sesji iMessage. Zatwierdzenia parowania są powiązane z identyfikatorami nadawców, więc skopiowane wpisy allowFrom nadal działają, ale historia rozmów zapisana pod kluczami sesji BlueBubbles nie jest przenoszona.

​

Zobacz także

• Migracja z BlueBubbles
• iMessage
• Dokumentacja konfiguracji — iMessage