Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix [Bug]: iMessage (imsg) echo loop - outbound messages captured as inbound, causing infinite reply cycles [1 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#61378•Fetched 2026-04-08 02:59:15
View on GitHub
Comments
0
Participants
1
Timeline
3
Reactions
0
Author
liangxinheartliangxinheart
Participants
liangxinheartliangxinheart
Timeline (top)
labeled ×2closed ×1

The iMessage plugin (via imsg rpc) captures the AI assistant's own outbound messages as inbound user input, creating an infinite echo loop. When the agent replies to a child's iMessage and the reply is sent via imsg send, the next chat.db poll picks up that sent message and feeds it back to the agent as if the child typed it, causing the agent to reply to its own message.

Root Cause

The agent's own replies appear as inbound messages in the child's DM session. The senderLabel shows the child's phone number even though the message was sent by the agent, because iMessage associates all messages in the same conversation with the same chat/thread. Session accumulates 32K+ tokens of noise in 10-15 minutes. Manual session reset is required to restore functionality.

RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

The iMessage plugin (via imsg rpc) captures the AI assistant's own outbound messages as inbound user input, creating an infinite echo loop. When the agent replies to a child's iMessage and the reply is sent via imsg send, the next chat.db poll picks up that sent message and feeds it back to the agent as if the child typed it, causing the agent to reply to its own message.

Steps to reproduce

  1. Install imsg via Homebrew (brew install steipete/tap/imsg)
  2. Configure OpenClaw with iMessage channel: cliPath: "/opt/homebrew/bin/imsg", dbPath: "/Users/heart/Library/Messages/chat.db", dmPolicy: "allowlist"
  3. Allow child's phone number in allowFrom
  4. Child sends a message to the bot's iMessage
  5. Agent replies via imsg send
  6. Next poll cycle: the agent's reply (written to chat.db with is_from_me = 1) is captured as new inbound message
  7. The agent replies to its own message → cycle repeats infinitely

Expected behavior

Messages sent by the agent (via imsg send) should be excluded from inbound polling. The chat.db contains an is_from_me field that can distinguish sent vs received messages. Outbound messages should never appear as user input in any session.

Actual behavior

The agent's own replies appear as inbound messages in the child's DM session. The senderLabel shows the child's phone number even though the message was sent by the agent, because iMessage associates all messages in the same conversation with the same chat/thread. Session accumulates 32K+ tokens of noise in 10-15 minutes. Manual session reset is required to restore functionality.

OpenClaw version

2026.4.2

Operating system

macOS 15.4 (M4, arm64

Install method

npm global

Model

openrouter/Qwen/qwen3.6-plus:free (primary), omlx/Qwen3.5-9B-MLX-4bit (local fallback)

Provider / routing chain

openclaw gateway -> imsg plugin (via imsg rpc stdio) -> iMessage chat.db on local Mac

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Impact and severity

Affected: iMessage DM users interacting with OpenClaw agents via imsg plugin Severity: Critical - completely blocks iMessage DM workflow, makes the channel unusable Frequency: 100% reproducible - happens on every agent reply Consequence: Child cannot use the education system at all; agent floods the conversation with self-replies (32K+ tokens of noise in minutes); requires manual session reset to recover

Additional information

No response

extent analysis

TL;DR

Filtering outbound messages based on the is_from_me field in chat.db is likely necessary to prevent the infinite echo loop.

Guidance

  • Verify that the imsg plugin correctly handles the is_from_me field in chat.db to distinguish between sent and received messages.
  • Modify the imsg plugin to exclude messages with is_from_me = 1 from being captured as inbound user input.
  • Check the OpenClaw configuration to ensure that the imsg plugin is properly configured to use the chat.db file and respect the is_from_me field.
  • Consider adding a filter in the OpenClaw agent to ignore messages that are identical to its previous replies, as an additional safeguard against the echo loop.

Example

No code example is provided due to the lack of specific implementation details in the issue.

Notes

The fix may require modifications to the imsg plugin or the OpenClaw agent, and thorough testing is necessary to ensure that the changes do not introduce new issues.

Recommendation

Apply a workaround by modifying the imsg plugin to filter out outbound messages based on the is_from_me field, as this is a critical issue that completely blocks the iMessage DM workflow.

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

Messages sent by the agent (via imsg send) should be excluded from inbound polling. The chat.db contains an is_from_me field that can distinguish sent vs received messages. Outbound messages should never appear as user input in any session.

#inference speed#output truncation#response parsing#generation error#database connection

Still need to ship something?

×6

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

Back to top recommendations

TRENDING