openclaw - 💡(How to fix) Fix iMessage outbound sends should prefer configurable IMCore transport when available [1 comments, 2 participants]

Summary

OpenClaw's normal iMessage outbound reply path currently sends through JSON-RPC send without choosing a transport. On one macOS deployment, that path stalled because AppleScript delivery timed out, while the IMCore/private-API path was healthy and imsg send-rich queued immediately.

It would be safer if OpenClaw either defaulted normal outbound iMessage sends to transport: "auto" when supported by imsg, or exposed a config option so operators can force auto, bridge, or applescript.

Environment

• OpenClaw: 2026.5.18
• imsg: 0.9.0
• macOS: 26.5
• iMessage channel configured through a custom cliPath wrapper running in a signed-in Messages user context
• imsg launch had succeeded; imsg status --json reported advanced/private API support

Observed Behavior

• Gateway/channel health could show iMessage as OK.
• Normal OpenClaw outbound iMessage replies could still fail or time out.
• Direct AppleScript-backed sends stalled in Messages/AppleEvent delivery.
• Direct IMCore/private API sends with imsg send-rich --chat ... --text ... --json returned quickly with a queued message.

Expected Behavior

When the imsg private API bridge is available, normal OpenClaw iMessage sends should be able to avoid the AppleScript path, or operators should be able to configure that explicitly.

Code Pointers

• extensions/imessage/src/send.ts builds the JSON-RPC send params and calls client.request("send", params, ...).
• extensions/imessage/src/actions.runtime.ts already routes richer message actions through imsg send-rich.
• imsg RPC send supports a transport option (auto, bridge, applescript), so OpenClaw could pass a preferred transport without requiring a local wrapper workaround.

Possible Fix

• Add a config setting such as channels.imessage.sendTransport / account-level equivalent with values like auto, bridge, and applescript.
• Default to auto when the installed imsg supports it.
• Pass the selected transport into the normal JSON-RPC send params.
• Keep a compatibility fallback for older imsg builds that do not accept the option.

I can follow up with a PR if this direction sounds acceptable.