Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix [Bug]: iMessage echo loop — agent replies re-ingested as inbound messages (reproduces on 2026.4.5 and 2026.4.8) [1 comments, 2 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#63405•Fetched 2026-04-09 07:54:07
View on GitHub
Comments
1
Participants
2
Timeline
4
Reactions
0
Author
BChertoffBChertoff
Participants
BChertoffBChertoffCriisyCCriisyC
Timeline (top)
labeled ×2commented ×1renamed ×1

After upgrading to 2026.4.5, the iMessage channel re-ingests the agent's own outbound replies as new inbound user messages, creating an infinite echo loop. Confirmed still present in 2026.4.8.

Root Cause

Hypothesis: msg.fromMe is undefined at filter time because is_from_me → fromMe normalization happens after the filter runs. imsg sends is_from_me (snake_case) but filter checks msg.fromMe (camelCase).

Fix Action

Fix / Workaround

Last known good version: NOT_ENOUGH_INFO (was working before 2026.4.5) First known bad version: 2026.4.5 (3e72c03) Still present in: 2026.4.8 (9ece252) Workaround: disable iMessage channel entirely Root cause hypothesis: is_from_me (snake_case from imsg) not mapped to fromMe (camelCase) before filter check in channel.runtime

Code Example

imsg watch stream output showing is_from_me correctly set:
{"is_from_me":false,"text":"Another test","sender":"+19143659652",...}
{"is_from_me":true,"text":"Still here.","sender":"+19143659652",...}

Filter in channel.runtime-C62UARRz.js:
if (msg.fromMe) return false;

Hypothesis: msg.fromMe is undefined at filter time because is_from_me → fromMe 
normalization happens after the filter runs. imsg sends is_from_me (snake_case) 
but filter checks msg.fromMe (camelCase).

imsg version: 0.5.0
RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

After upgrading to 2026.4.5, the iMessage channel re-ingests the agent's own outbound replies as new inbound user messages, creating an infinite echo loop. Confirmed still present in 2026.4.8.

Steps to reproduce

  1. Configure iMessage channel with dmPolicy: pairing and your own number in allowFrom
  2. Start gateway on macOS with imsg 0.5.0
  3. Send a message to the agent via iMessage
  4. Agent replies — the reply is immediately re-ingested as a new inbound message
  5. Agent replies again — infinite loop

Expected behavior

Agent replies once and stops. Messages with is_from_me:true should be filtered out.

Actual behavior

Agent replies are re-ingested as new inbound messages, triggering another agent reply, creating an infinite echo loop. iMessage channel must be disabled to stop it.

OpenClaw version

2026.4.8 (9ece252) — also reproduced on 2026.4.5 (3e72c03)

Operating system

macOS 26.3.1 (arm64) — Mac mini

Install method

Homebrew (brew install openclaw) + pnpm global

Model

anthropic/claude-sonnet-4-6

Provider / routing chain

openclaw -> anthropic/claude-sonnet-4-6

Additional provider/model setup details

NOT_ENOUGH_INFO

Logs, screenshots, and evidence

imsg watch stream output showing is_from_me correctly set:
{"is_from_me":false,"text":"Another test","sender":"+19143659652",...}
{"is_from_me":true,"text":"Still here.","sender":"+19143659652",...}

Filter in channel.runtime-C62UARRz.js:
if (msg.fromMe) return false;

Hypothesis: msg.fromMe is undefined at filter time because is_from_me → fromMe 
normalization happens after the filter runs. imsg sends is_from_me (snake_case) 
but filter checks msg.fromMe (camelCase).

imsg version: 0.5.0

Impact and severity

Affected: All iMessage users on macOS using imsg with dmPolicy: pairing Severity: Critical — iMessage channel must be fully disabled to prevent runaway API costs and infinite loops Frequency: 100% reproducible, every message triggers the loop Consequence: iMessage unusable as a channel, significant unexpected API spend

Additional information

Last known good version: NOT_ENOUGH_INFO (was working before 2026.4.5) First known bad version: 2026.4.5 (3e72c03) Still present in: 2026.4.8 (9ece252) Workaround: disable iMessage channel entirely Root cause hypothesis: is_from_me (snake_case from imsg) not mapped to fromMe (camelCase) before filter check in channel.runtime

extent analysis

TL;DR

  • The infinite echo loop in the iMessage channel can likely be fixed by ensuring that the is_from_me field from imsg is properly normalized to fromMe before the filter checks for outgoing messages.

Guidance

  • Verify that the is_from_me to fromMe normalization is indeed the cause by checking the filter logic in channel.runtime-C62UARRz.js and the imsg version (0.5.0) output.
  • Update the filter logic to correctly handle the is_from_me field from imsg, possibly by changing if (msg.fromMe) return false; to if (msg.is_from_me) return false; to match the snake_case naming convention used by imsg.
  • Consider adding a normalization step before the filter to ensure consistency in naming conventions, mapping is_from_me to fromMe if necessary.
  • Test the updated filter logic with the imsg version 0.5.0 to confirm that the infinite loop is resolved.

Example

// Potential normalization step before the filter
if (msg.is_from_me !== undefined) {
  msg.fromMe = msg.is_from_me;
}

// Updated filter logic
if (msg.fromMe) return false;

Notes

  • The exact fix may depend on the specifics of the imsg library and how it interacts with the filter logic in channel.runtime-C62UARRz.js.
  • Ensuring that the normalization and filter logic are correctly implemented is crucial to preventing the infinite echo loop.

Recommendation

  • Apply the workaround by updating the filter logic to correctly handle the is_from_me field, as this directly addresses the hypothesized root cause of the issue.

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

Agent replies once and stops. Messages with is_from_me:true should be filtered out.

#api#tensor shape#autograd error#model save/load#optimization

Still need to ship something?

×6

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

Back to top recommendations

TRENDING