Skip to content

iMessage outbound sends should prefer configurable IMCore transport when available #84329

@TurboTheTurtle

Description

@TurboTheTurtle

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.

Metadata

Metadata

Assignees

Labels

P2Normal backlog priority with limited blast radius.clawsweeper:needs-live-reproClawSweeper needs live local, crabbox, or manual validation to confirm this issue.clawsweeper:needs-maintainer-reviewClawSweeper marked this issue as needing maintainer review before automation.clawsweeper:needs-product-decisionClawSweeper marked this issue as needing a product or behavior decision.clawsweeper:no-new-fix-prClawSweeper does not recommend queueing a new automated fix PR for this issue.impact:message-lossChannel message delivery can be lost, duplicated, or misrouted.issue-rating: 🐚 platinum hermitGood issue quality with a plausible reproduction path needing some confirmation.

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions