Summary

Since upgrading to 4.2, outbound delivery messages sent via iMessage are echoing back as inbound messages, causing the main agent to reply with an acknowledgement (e.g., "收到。") after every cron-delivered notification.

Root Cause

normalizeEchoTextKey() in monitor-CkCMHJdv.js uses .trim() but does not strip NUL (\0) characters. When iMessage echoes an outbound message back into chat.db, the text is prefixed with one or more NUL bytes. This causes the echo cache lookup to fail because \0<original text> !== <original text>.

// Current (broken)
function normalizeEchoTextKey(text) {
  const normalized = text.replace(/\r\n?/g, "\n").trim();
  return normalized ? normalized : null;
}

// Suggested fix
function normalizeEchoTextKey(text) {
  const normalized = text.replace(/^\0+/, "").replace(/\r\n?/g, "\n").trim();
  return normalized ? normalized : null;
}

Additionally, the echo text TTL is 4 seconds (SENT_MESSAGE_TEXT_TTL_MS = 4e3). If the echo arrives after 4 seconds, it is not caught regardless of the text match. This may need to be tuned as well.

Reproduction

1. Configure a cron task that sends a delivery notification to a contact via iMessage.
2. After the delivery is sent, observe chat.db — the sent message re-appears as an inbound message with a \0 prefix on the text body.
3. The main agent session receives the echoed message and responds.

Impact

Every iMessage-delivered cron notification (e.g., stock reports, reminders) generates a spurious agent reply to the recipient. Confirmed on macOS 15.7.4 / openclaw 2026.4.9.

Workaround

Routing cron deliveries through imsg directly (bypassing the OpenClaw session layer) avoids the issue, but this is not a sustainable fix.