Summary

• Problem: WhatsApp Web outbound echo events could update channel inbound activity before the message was filtered out as an outbound echo.
• Why it matters: openclaw channels status --probe could report fresh inbound activity after a Gateway-originated self-send even though no real inbound WhatsApp message was handled.
• What changed: WhatsApp now records inbound channel activity only after the message survives normalization, append-history filtering, enrichment, and recent-inbound dedupe, immediately before enqueueing the inbound message.
• What did NOT change: Outbound activity recording, WhatsApp send behavior, self-chat filtering, group handling, and auto-reply dispatch are otherwise unchanged.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes [Bug]: WhatsApp outbound self-sends make channels status report fresh inbound activity #79056
• This PR fixes a bug or regression

Real behavior proof (required for external PRs)

• Behavior or issue addressed: WhatsApp self-sends should advance outbound activity but should not make channel status look like a fresh inbound message arrived.
• Real environment tested: Ubuntu VPS, Node 22, managed systemd user Gateway, live linked WhatsApp Web account.
• Exact steps or command run after this patch: rebuilt the local checkout, restarted the managed Gateway, captured openclaw channels status --json, sent one WhatsApp message to the linked account's own E.164 number through openclaw message send --channel whatsapp --account default, waited, then captured channels status --json and redacted Gateway logs.
• Evidence after fix:

{
  "sendMessageId": "3EB0FE70141FB96653FA7A",
  "before": {
    "lastInboundAt": null,
    "lastOutboundAt": null,
    "connected": true,
    "healthState": "healthy"
  },
  "after": {
    "lastInboundAt": null,
    "lastOutboundAt": "2026-05-07T17:55:58.765Z",
    "connected": true,
    "healthState": "healthy"
  },
  "inboundAdvanced": false,
  "outboundAdvanced": true
}

Redacted matching logs after fix only showed the outbound send:

[whatsapp] Sending message -> sha256:<redacted>
[whatsapp] Sent message 3EB0FE70141FB96653FA7A -> sha256:<redacted> (138ms)
[ws] res send channel=whatsapp

• Observed result after fix: outbound activity advanced and inbound activity did not advance.
• What was not tested: every WhatsApp deployment mode, multi-account WhatsApp, and full repository test suite.
• Before evidence: current main advanced both status timestamps for the same Gateway-originated self-send path:

{
  "sendMessageId": "3EB03B031C04B624AAEA9B",
  "before": {
    "lastInboundAt": "2026-05-07T17:18:40.619Z",
    "lastOutboundAt": "2026-05-07T17:18:40.517Z"
  },
  "after": {
    "lastInboundAt": "2026-05-07T17:41:18.191Z",
    "lastOutboundAt": "2026-05-07T17:41:18.145Z"
  },
  "inboundAdvanced": true,
  "outboundAdvanced": true
}

Root Cause (if applicable)

• Root cause: attachWebInboxToSocket recorded inbound channel activity at the top of each WhatsApp messages.upsert item, before normalizeInboundMessage could reject Gateway-originated outbound echoes via the recent outbound-message filter.
• Missing detection / guardrail: Existing outbound echo tests asserted no inbound message was delivered, but did not assert that inbound channel activity was not recorded.
• Contributing context (if known): channels status uses channel activity as fallback status metadata, so pre-filter raw WhatsApp Web events can leak into user-visible status even when the inbound message is later dropped.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: extensions/whatsapp/src/monitor-inbox.behavior.test.ts
• Scenario the test should lock in: Gateway-originated WhatsApp fromMe echoes are filtered without recording inbound channel activity.
• Why this is the smallest reliable guardrail: The bug is local to the WhatsApp inbox monitor's ordering around echo filtering and enqueueing.
• Existing test that already covers this (if any): Existing echo-filter tests covered no inbound delivery; this PR extends them to cover channel activity accounting.
• If no new test is added, why not: N/A.

User-visible / Behavior Changes

openclaw channels status --probe no longer reports fresh WhatsApp inbound activity from a Gateway-originated outbound echo/self-send.

Diagram (if applicable)

Before:
WhatsApp Web upsert -> record inbound activity -> echo filter drops message -> status still shows inbound activity

After:
WhatsApp Web upsert -> echo/history/enrichment/dedupe filters -> record inbound activity only for accepted inbound -> enqueue

Security Impact (required)

• 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
• If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

• OS: Ubuntu 24.04
• Runtime/container: Node 22, systemd user Gateway
• Model/provider: N/A
• Integration/channel (if any): WhatsApp Web, account default
• Relevant config (redacted): live linked WhatsApp account, loopback Gateway

Steps

1. Start a linked WhatsApp Gateway account.
2. Capture openclaw channels status --json.
3. Send a Gateway-originated WhatsApp message to the linked account's own E.164 number.
4. Capture openclaw channels status --json again.
5. Compare lastInboundAt and lastOutboundAt.

Expected

• lastOutboundAt advances.
• lastInboundAt does not advance unless a real inbound WhatsApp message is handled.

Actual

• Before this patch, both lastInboundAt and lastOutboundAt advanced for the self-send echo.
• After this patch, only lastOutboundAt advances.

Evidence

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

• Verified scenarios: outbound self-send status accounting on a live linked WhatsApp Gateway; focused WhatsApp inbox echo tests; broader WhatsApp send/inbound/status/session tests.
• Edge cases checked: outbound DM echo, self-chat DM echo, append history filtering, inbound dedupe, media/status/session neighboring tests.
• What you did not verify: full repository suite, every WhatsApp account topology, and long-lived multi-day runtime behavior.

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? Yes
• Config/env changes? No
• Migration needed? No
• If yes, exact upgrade steps: N/A

Risks and Mitigations

• Risk: Moving activity accounting later could miss activity for messages that are normalized but intentionally skipped before enqueueing.
• Mitigation: That is the intended boundary for user-visible inbound activity; skipped echoes, stale append history, failed enrichment, and duplicate redeliveries should not make status report fresh inbound handling.