Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix iMessage channel: self-sent messages (is_from_me=true) echoed back as inbound [3 comments, 3 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#58794•Fetched 2026-04-08 02:32:34
View on GitHub
Comments
3
Participants
3
Timeline
6
Reactions
0
Author
wangyaomindewangyaominde
Participants
akeyblakeyblhondaya06hondaya06wangyaomindewangyaominde
Timeline (top)
commented ×3closed ×1reopened ×1subscribed ×1

When the agent sends a reply via iMessage, the sent message is picked up by imsg watch and fed back to the agent as a new inbound message from the remote party. This creates echo loops where the agent sees its own replies as user messages.

Root Cause

imsg watch correctly sets is_from_me: true on outbound messages, but OpenClaw's iMessage channel handler does not filter these out. Evidence from imsg history:

{"text":"(agent reply text)","sender":"+86XXXXXXXXXXX","is_from_me":true}
{"text":"(user message)","sender":"+86XXXXXXXXXXX","is_from_me":false}

Note: sender is the same for both (the remote party's number), so sender alone cannot distinguish them. The is_from_me field is the only reliable discriminator.

Fix Action

Workaround

Agent-level detection of echo messages (content matching), but this is fragile.

Code Example

{"text":"(agent reply text)","sender":"+86XXXXXXXXXXX","is_from_me":true}
{"text":"(user message)","sender":"+86XXXXXXXXXXX","is_from_me":false}
RAW_BUFFERClick to expand / collapse

Bug: iMessage self-sent messages are echoed back as inbound

Environment

  • OpenClaw: 2026.3.31 (213a704)
  • imsg: 0.5.0 (also reproduced on 0.4.0)
  • macOS (Apple Silicon, macOS 15)
  • Channel: iMessage (direct DM)

Description

When the agent sends a reply via iMessage, the sent message is picked up by imsg watch and fed back to the agent as a new inbound message from the remote party. This creates echo loops where the agent sees its own replies as user messages.

Root cause

imsg watch correctly sets is_from_me: true on outbound messages, but OpenClaw's iMessage channel handler does not filter these out. Evidence from imsg history:

{"text":"(agent reply text)","sender":"+86XXXXXXXXXXX","is_from_me":true}
{"text":"(user message)","sender":"+86XXXXXXXXXXX","is_from_me":false}

Note: sender is the same for both (the remote party's number), so sender alone cannot distinguish them. The is_from_me field is the only reliable discriminator.

Expected behavior

OpenClaw's iMessage channel should check is_from_me in watch events and skip messages where is_from_me === true.

Actual behavior

Every outbound reply is re-ingested as an inbound message, causing:

  1. The agent receives its own messages as user input
  2. The agent replies with NO_REPLY (or worse, responds to itself)
  3. The user sees duplicate/confusing messages

Workaround

Agent-level detection of echo messages (content matching), but this is fragile.

extent analysis

TL;DR

Modify OpenClaw's iMessage channel handler to filter out messages with is_from_me: true to prevent echo loops.

Guidance

  • Check the is_from_me field in imsg watch events and skip processing messages where is_from_me === true.
  • Verify the fix by sending a reply via iMessage and checking if the agent receives its own message as a new inbound message.
  • Consider adding a test case to ensure the is_from_me field is correctly handled in the iMessage channel handler.
  • Review the agent-level detection of echo messages (content matching) workaround and consider replacing it with the proposed fix.

Example

// Example event from imsg watch
{
  "text": "(agent reply text)",
  "sender": "+86XXXXXXXXXXX",
  "is_from_me": true
}

// Proposed fix in OpenClaw's iMessage channel handler
if (event.is_from_me === true) {
  // Skip processing the message
  return;
}

Notes

The proposed fix relies on the is_from_me field being correctly set by imsg watch. If this field is not reliable, alternative solutions may be needed.

Recommendation

Apply workaround: Modify OpenClaw's iMessage channel handler to filter out messages with is_from_me: true, as this directly addresses the root cause of the echo loops.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

OpenClaw's iMessage channel should check is_from_me in watch events and skip messages where is_from_me === true.

#model download#tokenizer error#prompt formatting#chain error#conversation history

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING