PR #75890: fix(signal): support Note-to-Self in linked-device mode

• Repository: openclaw/openclaw
• Author: jeffhu1
• State: open | merged: False
• Link: https://github.com/openclaw/openclaw/pull/75890

Description (problem / solution / changelog)

Summary

• Problem: When signal-cli runs as a linked device on the operator's personal Signal account, the existing loop-protection in event-handler.ts blanket-drops all messages from the bot's own account AND all syncMessages. Note-to-Self chat is therefore impossible.
• Why it matters: Note-to-Self is the natural chat surface for users running OpenClaw as a personal agent on their existing Signal account. Without this, users must acquire a dedicated bot number to chat with their own agent — significant friction for personal-use deployments.
• What changed: Added a Note-to-Self carve-out: syncMessages where destination === source are promoted to dataMessage so downstream allowFrom/dmPolicy/agent processing treats them as normal inbound. Both phone-number and UUID identification paths are handled.
• What did NOT change (scope boundary): Loop protection is preserved. Other syncMessages (sentTranscripts to third parties, read receipts, etc.) and direct own-account messages are still dropped.

Change Type

• Bug fix

Scope

• Integrations

Linked Issue/PR

• Closes #75870
• Related: #5722 (original feature request with equivalent patch, closed via maintainer triage without review)
• This PR fixes a bug or regression

Root Cause

• Root cause: Loop-protection was implemented as "drop anything from own account; drop anything that's a syncMessage" — correct for preventing outbound replies from re-triggering the agent, but blanket-blocks legitimate Note-to-Self conversations on a linked-device personal-account setup.
• Missing detection / guardrail: Implementation didn't distinguish syncMessages-to-self (legitimate inbound) from syncMessages-to-others (true outbound replays). Treating them the same is the bug.
• Contributing context: This carve-out is the canonical pattern other Signal-cli bots use (signal-ai-chat-bot, signalbot, Hermes Agent). Requested by multiple users since Feb 2026.

Regression Test Plan

• Coverage level that should have caught this:
  • Unit test
• Target test or file: extensions/signal/src/monitor/event-handler.test.ts (or equivalent)
• Scenario the test should lock in: syncMessage with destination === source (Note-to-Self) is promoted to dataMessage; destination !== source (third-party transcript) is still dropped; direct own-account non-sync messages still dropped.
• If no new test is added, why not: Author doesn't have local pnpm/CI set up for this repo. Happy to add a unit test in a follow-up or per maintainer guidance.

User-visible / Behavior Changes

• Linked-device deployments where signal-cli is paired to the operator's personal Signal account can now chat with the agent via Note-to-Self.
• No new config flag; behavior is automatic when destination === source.
• No change for dedicated-bot-number deployments (the typical pattern).

Diagram

Before:
phone -> Note-to-Self -> Signal server -> linked signal-cli -> envelope
   -> "syncMessage" in envelope -> RETURN (dropped)
   -> agent never sees it

After:
phone -> Note-to-Self -> Signal server -> linked signal-cli -> envelope
   -> envelope.syncMessage.sentMessage exists
   -> destination === source ? YES
   -> envelope.dataMessage = sentMessage; fall through
   -> agent processes as normal inbound (subject to allowFrom/dmPolicy)

Security Impact

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No
• Command/tool execution surface changed? No (existing dmPolicy/allowFrom gates still apply)
• Data access scope changed? No — only routing decision changes.

The patch only changes which messages get routed inbound. Existing access-control machinery still gates whether the agent processes them.

Repro + Verification

Environment

• OS: macOS 15 (Apple Silicon M2 Max)
• Runtime: [email protected] globally installed; daemon as launchd LaunchAgent
• Model/provider: anthropic/claude-opus-4-7 (direct API)
• Channel: Signal (signal-cli 0.14.3 linked as device)
• Config: channels.signal.dmPolicy=allowlist, allowFrom=["+1xxxxx"] (operator's own number), groupPolicy=disabled

Steps

1. Pair signal-cli as a linked device of operator's personal Signal account (signal-cli link -n "OpenClaw" + scan QR)
2. Configure OpenClaw signal channel for the linked account
3. From operator's phone, send a message to the "Note to Self" thread

Expected

• Agent receives the message and responds in the same thread.

Actual (before patch)

• Message silently dropped; no agent response in Note-to-Self.

Actual (after patch)

• Agent processes Note-to-Self message and replies in the same thread.

Evidence

• Trace/log snippets

Manually verified end-to-end against a working OpenClaw 2026.4.29 install with the equivalent patch applied to the bundled dist/monitor-D141zc1R.js (same logic). Note-to-Self bidirectional chat works; non-Note-to-Self syncMessages and direct own-account outbound are still correctly dropped (no spurious replies, no infinite loops over a multi-hour test session).

Human Verification

• Verified scenarios:
  • Note-to-Self message from primary device (phone) → agent responds correctly ✅
  • Outbound message from agent to Note-to-Self → not re-processed (no loop) ✅
  • sentTranscript syncMessages to third parties → dropped (destination !== source) ✅
  • Other inbound (third-party DMs to operator) → unaffected by this change ✅
• Edge cases checked:
  • UUID identification path (destinationUuid === sourceUuid)
  • Phone-number identification path (destinationNumber === sourceNumber)
  • Envelope with only one of phone/UUID populated — falsy guards handle gracefully
• What I did not verify:
  • Did NOT run pnpm build && pnpm check && pnpm test locally (no local pnpm setup for this monorepo)
  • Did NOT add a new unit test
  • Did NOT run codex review --base origin/main locally

Compatibility / Migration

• Backward compatible? Yes — behavior only changes for syncMessages with destination === source, which were previously dropped. No config or migration required.
• Config/env changes? No
• Migration needed? No

Risks and Mitigations

• Risk: Future Signal/signal-cli protocol changes could rename destinationNumber/destinationUuid fields.
  • Mitigation: Falsy-guarded checks (!!destNum && !!srcNum); missing fields cause the syncMessage to fall through to the existing "syncMessage" in envelope → return branch (preserves loop protection).

AI-assisted PR

• Marked as AI-assisted (this section)
• Degree of testing: lightly tested — manual end-to-end against a running daemon; no pnpm test suite run.
• Confirm I understand what the code does: Yes. The patch promotes self-addressed syncMessage.sentMessage envelopes to dataMessage to allow Note-to-Self routing through the existing inbound pipeline.
• Codex review: Did NOT run codex review --base origin/main locally (no local codex CLI setup); flagging for first-push CI review.
• Bot review conversations: Will resolve any addressed bot conversations after first push.

Changed files

• CHANGELOG.md (modified, +1/-0)
• docs/channels/signal.md (modified, +6/-2)
• extensions/signal/src/monitor/event-handler.ts (modified, +64/-11)