openclaw - 💡(How to fix) Fix iMessage channel: wire imsg typing/tapback/read into the channel runtime [1 comments, 2 participants]

Summary

imsg launch connects the IMCore bridge and exposes typing indicators, tapback reactions, read receipts, edit, and unsend at the CLI/RPC layer. The OpenClaw imessage channel runtime in 2026.5.7 does not call any of these on the agent's behalf. The bridge is provisioned but unused.

Observed

After imsg launch (bridge v2 confirmed via imsg status), a normal iMessage inbound → agent → outbound cycle produces no:

• typing indicator on the sender's device while the model is composing
• tapback ack on receipt
• read-receipt back to the sender after the message is consumed

Inbound is read fine (basic mode works). Outbound text is sent fine. The advanced surface is just not exercised.

Evidence

Grep across /opt/homebrew/lib/node_modules/openclaw/dist/:

• dist/extensions/imessage/ — zero references to typing, tapback, react, read_receipt, or any imsg send-rich/typing/read/tapback/edit/unsend subcommand invocations
• Typing emission code lives in Telegram path (bot-*.js calls sendChatAction "typing") and Microsoft Teams path (dist-*.js uses TypingActivity)
• channels.imessage.capabilities: ["typing","reactions","unsend","read_receipts"] is schema-valid (capabilities: array<string>) and reload-accepted but appears to be a no-op for these strings — no honoring code found in the imessage runtime

Ask

Wire the imessage channel runtime to call the imsg bridge when available:

1. Typing indicators — invoke imsg typing <chatId> between inbound receipt and outbound send (or on a heartbeat while the model is still composing for long-running turns)
2. Tapback ack on receipt — optional, behind a per-channel actions.ackReactions toggle
3. Read receipts — invoke imsg read <chatId> after a message is consumed by the agent; optional, behind actions.readReceipts
4. Honor channels.imessage.capabilities — surface the existing schema field as the opt-in toggle, or document the canonical config path if it's elsewhere

The bridge already exposes the capabilities; this is purely runtime wiring.

Environment

• OpenClaw: 2026.5.7 (eeef486)
• imsg: 0.8.2 (steipete/tap)
• macOS: 26.4.1, Apple Silicon
• SIP: disabled (advanced features available per imsg status)
• Channel config: standard dmPolicy: allowlist + native imsg path

Related (not duplicate)

#80909 — separate MCP tool-surface regression on the same gateway