openclaw - 💡(How to fix) Fix iMessage duplicate delivery: gateway retries send every ~17s when imsg CLI slow to ack on long turns [1 participants]

Summary

iMessage replies are being delivered multiple times (doubles, triples) at regular ~17-second intervals when the turn involves multiple tool calls or takes longer than ~15 seconds to complete.

Environment

• OpenClaw: 2026.4.7 (5050017)
• imsg CLI: 0.5.0
• macOS: Darwin 25.3.0 (arm64)
• Channel: iMessage (direct DM)
• Config: dmHistoryLimit: 0, maxConcurrent: 1, blockStreaming: false

Observed Behavior

Gateway log shows multiple delivered reply events for the same turn at ~17-second intervals:

11:16:55.875 [imessage] delivered reply to imessage:+16023000493
11:17:12.261 [imessage] delivered reply to imessage:+16023000493  (17s later)
11:17:33.294 [imessage] delivered reply to imessage:+16023000493  (21s later)

The user receives 2-3 identical messages per turn.

Pattern

• Duplicates occur: on turns with multiple tool calls (exec, config.patch, schema.lookup, etc.) that take >15s to complete
• No duplicates: on short single-reply turns that complete in <5s
• Interval: consistently ~17 seconds between duplicate deliveries
• Stops: after some number of retries (message is eventually acked)

Hypothesis

The gateway appears to retry imsg send on a ~17s timer when it doesn't receive a prompt acknowledgment from the CLI. On short turns, the CLI acks before the timer fires. On long turns (multi-tool), the CLI takes longer and the retry fires 1-3 times before ack arrives.

Attempted Config Changes (none resolved the issue)

• Set dmHistoryLimit: 0 — no change
• Set blockStreaming: true with coalesce — made worse (stacked queued messages)
• Set maxConcurrent: 1 — no change
• Disabled/removed fabric-sync hook — no change
• Reverted blockStreaming: false — no change

Expected Behavior

Each turn should deliver exactly one reply to the user, regardless of turn duration.

Possible Fix

Consider adding send deduplication with a message ID / content hash check before retrying, or increasing the ack timeout on the imsg delivery path so short-lived retry storms don't fire on normal multi-tool turns.