You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
iMessage: Include reply/thread context in incoming messages
Labels
enhancement, channel:imessage
Body
Problem
When a user replies to a specific message in iMessage (using the inline reply feature), the OpenClaw agent receives only the new message text with no context about which message was being replied to.
This makes conversations confusing — the agent cannot tell which of its prior messages the user is responding to. Every other major channel (Telegram, Discord, Signal, WhatsApp) correctly passes reply context to the agent.
Current Behavior
User replies to a specific agent message in iMessage → Agent sees:
[iMessage from +1555…]
Yes, that one
Expected Behavior
User replies to a specific agent message in iMessage → Agent sees:
[iMessage from +1555…]
Yes, that one
[Replying to +17034055338 id:2320]
Here are two options: A) the blue one or B) the red one
[/Replying]
Technical Analysis
The OpenClaw iMessage integration has three layers: chat.db → imsg CLI → OpenClaw monitor → Agent.
✅ Layer 1: macOS Messages Database — HAS the data
The message table in chat.db has thread_originator_guid (reliable, matches iMessage UI) and reply_to_guid (less reliable). Verified with real data — multiple messages have thread_originator_guid correctly linking to their reply targets.
❌ Layer 2: imsg CLI v0.4.0 — Does NOT expose the data
When reply context is present, it formats it as [Replying to <sender> id:<id>]\n<body>\n[/Replying] and populates ReplyToId, ReplyToBody, and ReplyToSender on the envelope.
The code is ready. The data just never arrives from imsg.
Comparison with Other Channels
Channel
Reply Context
How
Telegram
✅
grammY reply_to_message object
Discord
✅
message.reference → resolved message
Signal
✅
signal-cli quoteMessage
WhatsApp
✅
Baileys quotedMessage
iMessage
❌
imsg v0.4.0 doesn't emit reply fields
Proposed Solution
Option A (preferred — zero OpenClaw code changes):
Upstream: Get imsg to include resolved reply context in its output:
reply_to_id — rowid of the originator message
reply_to_text — text of the originator message
reply_to_sender — sender of the originator message
OpenClaw's existing describeReplyContext() picks these up automatically
Adding a message.get RPC method to imsg and calling it from the monitor
Querying chat.db directly (less ideal, duplicates DB access logic)
Map resolved data into existing reply_to_text/reply_to_id/reply_to_sender fields
Dependencies
steipete/imsg#39 — PR adding thread_originator_guid (needs to be extended with resolved fields, or OpenClaw needs to handle resolution)
Additional Context
The reply_to_guid column in chat.db is unreliable — it often points to the most recent message rather than the actual reply target. thread_originator_guid is the correct field (per feat: add thread_originator_guid to message output imsg#39 analysis).
OpenClaw already supports replyToMode config for outbound replies on Telegram/Discord. Once inbound reply context works for iMessage, outbound replyToMode support could follow.
Full technical analysis: see projects/imessage-reply-context-analysis.md in the workspace.
iMessage: Include reply/thread context in incoming messages
Labels
enhancement,channel:imessageBody
Problem
When a user replies to a specific message in iMessage (using the inline reply feature), the OpenClaw agent receives only the new message text with no context about which message was being replied to.
This makes conversations confusing — the agent cannot tell which of its prior messages the user is responding to. Every other major channel (Telegram, Discord, Signal, WhatsApp) correctly passes reply context to the agent.
Current Behavior
User replies to a specific agent message in iMessage → Agent sees:
Expected Behavior
User replies to a specific agent message in iMessage → Agent sees:
Technical Analysis
The OpenClaw iMessage integration has three layers: chat.db → imsg CLI → OpenClaw monitor → Agent.
✅ Layer 1: macOS Messages Database — HAS the data
The
messagetable inchat.dbhasthread_originator_guid(reliable, matches iMessage UI) andreply_to_guid(less reliable). Verified with real data — multiple messages havethread_originator_guidcorrectly linking to their reply targets.❌ Layer 2:
imsgCLI v0.4.0 — Does NOT expose the dataCurrent
imsgJSON output per message:{ "id": 2329, "text": "...", "guid": "E37CE941-...", "chat_id": 1, "created_at": "2026-02-06T23:16:42.284Z", "is_from_me": true, "sender": "+17034055338", "attachments": [], "reactions": [] }No
thread_originator_guid,reply_to_text,reply_to_sender, orreply_to_idfields.Upstream work exists:
thread_originator_guid(mergeable)✅ Layer 3: OpenClaw Monitor — ALREADY has the code
The monitor (
dist/imessage/monitor/monitor-provider.js) already implements reply context extraction:When reply context is present, it formats it as
[Replying to <sender> id:<id>]\n<body>\n[/Replying]and populatesReplyToId,ReplyToBody, andReplyToSenderon the envelope.The code is ready. The data just never arrives from
imsg.Comparison with Other Channels
reply_to_messageobjectmessage.reference→ resolved messagequoteMessagequotedMessageimsgv0.4.0 doesn't emit reply fieldsProposed Solution
Option A (preferred — zero OpenClaw code changes):
imsgto include resolved reply context in its output:reply_to_id— rowid of the originator messagereply_to_text— text of the originator messagereply_to_sender— sender of the originator messagedescribeReplyContext()picks these up automaticallyimsgversion requirement in docsOption B (if imsg only adds the GUID):
imsgPR Fix CI #39 addsthread_originator_guidmessage.getRPC method toimsgand calling it from the monitorreply_to_text/reply_to_id/reply_to_senderfieldsDependencies
thread_originator_guid(needs to be extended with resolved fields, or OpenClaw needs to handle resolution)Additional Context
reply_to_guidcolumn in chat.db is unreliable — it often points to the most recent message rather than the actual reply target.thread_originator_guidis the correct field (per feat: add thread_originator_guid to message output imsg#39 analysis).replyToModeconfig for outbound replies on Telegram/Discord. Once inbound reply context works for iMessage, outboundreplyToModesupport could follow.projects/imessage-reply-context-analysis.mdin the workspace.