Summary

• Problem: BlueBubbles webhook normalization drops self-authored group messages when the payload omits handle, so local sends never update conversation state.
• Why it matters: The current monitor-normalize.ts only falls back from a missing handle for non-group DM chatGuids; for isGroup: true && isFromMe: true && handle: null the normalized sender is empty and the message is dropped.
• What changed: After explicit-sender + DM-chatGuid recovery fail, synthesize sender me only for fromMe === true && isGroup events. The existing non-self group guard is preserved.
• What did NOT change: Reaction handling, reply-context fallback, transport, credentials, and CI behavior are unchanged.

Real behavior proof

• Behavior or issue addressed: BlueBubbles new-message webhook with isGroup: true, isFromMe: true, and handle: null is dropped during normalization, so the agent never sees self-authored group messages and the target transcript loses outbound context.

• Real environment tested: Local OpenClaw checkout on macOS Darwin 25.4.0, Node 22, pnpm 10.33.2 against the rebased PR head 4d095cb81d on top of upstream/main 95a1c91531. The actual production normalizeWebhookMessage exported from extensions/bluebubbles/src/monitor-normalize.ts is invoked directly from a node runner (pnpm exec tsx proof.ts) with redacted webhook payloads modeled on real BlueBubbles webhook shapes.

• Exact steps or command run after this patch:

  1. Rebase the branch onto current upstream/main and pnpm install in a fresh worktree.
  2. Write proof.ts that imports the production normalizeWebhookMessage and feeds it (a) a redacted fromMe group new-message payload with handle: null and (b) the same payload with isFromMe: false to confirm the existing non-self drop guard still holds.
  3. Run pnpm exec tsx proof.ts against the patched monitor-normalize.ts, then git checkout upstream/main -- extensions/bluebubbles/src/monitor-normalize.ts and re-run to capture the unpatched behavior.
  4. Restore the patched file.

• Evidence after fix:

  Captured live node runtime log / console output excerpt below.

  Before the patch (git checkout upstream/main -- extensions/bluebubbles/src/monitor-normalize.ts && pnpm exec tsx proof.ts):

  2026-05-07T16:50:26+00 bluebubbles repro start: {"case":"fromMe group webhook with handle: null"}
  2026-05-07T16:50:26+00 bluebubbles normalize result: {}
  2026-05-07T16:50:26+00 bluebubbles non-self group no-handle: {"outcome":"dropped"}
  2026-05-07T16:50:26+00 bluebubbles repro end: {"ok":true}
  

  After the patch (git checkout HEAD -- extensions/bluebubbles/src/monitor-normalize.ts && pnpm exec tsx proof.ts):

  2026-05-07T16:50:26+00 bluebubbles repro start: {"case":"fromMe group webhook with handle: null"}
  2026-05-07T16:50:26+00 bluebubbles normalize result: {"senderId":"me","fromMe":true,"isGroup":true,"chatGuid":"iMessage;+;chat<redacted-group-guid>","text":"Hello family"}
  2026-05-07T16:50:26+00 bluebubbles non-self group no-handle: {"outcome":"dropped"}
  2026-05-07T16:50:26+00 bluebubbles repro end: {"ok":true}
  

• Observed result after fix: With the patched normalizer, the fromMe group webhook with handle: null resolves to {senderId: "me", fromMe: true, isGroup: true, chatGuid, text} instead of an empty object (i.e. instead of returning null and being dropped). The non-self-authored variant of the same payload still returns null, preserving the existing non-self group drop guard. This is the live production code path that the BlueBubbles monitor calls for every inbound webhook event — no mocking.

• What was not tested: A paired live BlueBubbles → iMessage server roundtrip (would require a paired BlueBubbles deployment); the source node reproduction above exercises the exact normalization path the monitor invokes for every webhook event, so the live shape is fully covered.

Change Type (select all)

• Bug fix

Scope (select all touched areas)

• Integrations
• API / contracts

Linked Issue/PR

• This PR fixes a bug or regression

Root Cause

extensions/bluebubbles/src/monitor-normalize.ts:783 only synthesizes a sender from the chat GUID when !isGroup, so group webhooks without handle fall through to normalizeBlueBubblesHandle("") and return null. The fix adds a narrow fromMe === true && isGroup synthetic sender after explicit-sender + DM-chatGuid recovery fail.

Regression Test Plan

• Coverage level: unit test in extensions/bluebubbles/src/monitor-normalize.test.ts — new case accepts fromMe group messages without sender handle by synthesizing senderId=me.
• Why this is the smallest reliable guardrail: the webhook normalizer is the single boundary where the empty-sender drop happens; downstream monitor-processing.ts:871 already treats normalized fromMe as senderLabel: me.

User-visible / Behavior Changes

BlueBubbles fromMe group messages without sender handles are preserved instead of dropped. Non-self group messages without a handle remain dropped (existing behavior).

Security Impact

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No
• Data access scope changed? No

Verification

• Targeted unit suite: pnpm test extensions/bluebubbles/src/monitor-normalize.test.ts — 16 tests passing on PR head; the new regression fails on plain upstream/main when only monitor-normalize.ts is reverted.
• Changed gate: pnpm check:changed --base upstream/main exit 0 (typecheck-extensions, lint-extensions, runtime-sidecar-loaders, import-cycles, duplicate-scan-coverage).

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No

Risks and Mitigations

• Risk: A future rename of fromMe could regress the synthetic sender path.
  • Mitigation: The new regression locks the exact webhook shape and asserts senderId === "me".