Summary

• Problem: Proactive WhatsApp sends to phone numbers whose contact internally uses LID end up in a sender-only ghost chat. The message shows ✓✓ but never reaches the recipient (issue [Bug]: WhatsApp outbound messages create ghost chats due to missing LID→PN resolution in createWebSendApi #67378).
• Why it matters: Silent data loss with a positive-success signal — agents report "sent" while users never see the message. Hard to debug for operators because the failure is invisible to the recipient and the gateway logs success.
• What changed: Outbound active-listener send paths (sendMessage / sendPoll / sendComposingTo) now resolve a phone number to {lid}@lid via lid-mapping-{phoneDigits}.json in the account auth dir when present, falling back to {digits}@s.whatsapp.net otherwise. New helpers readLidForwardMapping + toWhatsappJidWithLid are added beside the existing readLidReverseMapping / jidToE164 to keep the LID handling symmetric.
• What did NOT change (scope boundary): outbound-base.ts:131 and send.ts outer entries keep toWhatsappJid because those produce redacted log strings only; the actual delivery flows through active.sendMessage(to, ...). sendReaction's chatJid keeps toWhatsappJid because callers pass already-formed JIDs (group / DM / LID). The companion lid-mapping-{lid}_reverse.json regeneration after re-link, mentioned at the end of [Bug]: WhatsApp outbound messages create ghost chats due to missing LID→PN resolution in createWebSendApi #67378, is left out as a separate fix.

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 messages create ghost chats due to missing LID→PN resolution in createWebSendApi #67378
• This PR fixes a bug or regression

Root Cause

• Root cause: toWhatsappJid in extensions/whatsapp/src/targets-runtime.ts is purely lexical — it maps any phone number to {digits}@s.whatsapp.net with no awareness of LID. The reverse direction (LID JID → PN) was already wired through readLidReverseMapping reading lid-mapping-{lid}_reverse.json, but the forward direction (PN → LID) was missing entirely on the outbound path. When Baileys' contact uses LID internally, sending to s.whatsapp.net creates a separate sender-side thread.
• Missing detection / guardrail: No assertion that proactive sends route to a delivery-confirmable JID. WhatsApp Web does not surface the ghost-chat condition as an error.
• Contributing context (if known): Baileys 7.0 stores both directions under the lid-mapping keyspace — [pnUser]: lidUser and [lidUser_reverse]: pnUser — but only the reverse half had a code path here.

Regression Test Plan

• 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/text-runtime.test.ts — describe("toWhatsappJidWithLid (issue #67378)", ...)
  • extensions/whatsapp/src/inbound/send-api.test.ts — describe("createWebSendApi LID resolution (issue #67378)", ...)
• Scenario the test should lock in: Given a lid-mapping-{phoneDigits}.json containing a LID, outbound sendMessage / sendPoll / sendComposingTo must call sock.sendMessage (or sendPresenceUpdate) with {lid}@lid. With no forward mapping, the legacy {digits}@s.whatsapp.net JID must still be used. Without authDir, behavior must be identical to before this PR.
• Why this is the smallest reliable guardrail: The bug surfaces inside createWebSendApi, which is exactly where the new tests assert. The unit test on toWhatsappJidWithLid pins down the helper contract; the integration test confirms the authDir is threaded all the way through and that all three outbound entry points use it.
• Existing test that already covers this (if any): None — all prior createWebSendApi tests instantiate without authDir, so they never exercised LID resolution.
• If no new test is added, why not: N/A — both layers added.

User-visible / Behavior Changes

• Proactive WhatsApp sends to LID-addressed contacts now actually reach the recipient. No config flag, no migration — behavior changes only for accounts whose Baileys auth dir already contains forward LID mappings (i.e., contacts have been observed at least once on inbound).
• Accounts with no LID mappings see no behavior change.

Diagram (if applicable)

Before:
  message tool ── "+15555550000" ──> toWhatsappJid ──> 15555550000@s.whatsapp.net
                                                       └─> WA Web ──> ghost chat (sender-only) ✗

After (with authDir + forward mapping present):
  message tool ── "+15555550000" ──> toWhatsappJidWithLid ──> reads lid-mapping-15555550000.json
                                                              └─> 987654@lid ──> WA Web ──> recipient ✓

Security Impact (required)

• New permissions/capabilities? No
• Secrets/tokens handling changed? No
• New/changed network calls? No (same Baileys send call, only the JID argument changes)
• Command/tool execution surface changed? No
• Data access scope changed? No (reads files already created and used by Baileys in the same auth dir)

Repro + Verification

Environment

• OS: Windows 11 (also reproducible on Linux/macOS by symptom report in [Bug]: WhatsApp outbound messages create ghost chats due to missing LID→PN resolution in createWebSendApi #67378)
• Runtime/container: Node 22, OpenClaw origin/main
• Model/provider: not relevant (channel-side bug)
• Integration/channel: WhatsApp Web (Baileys 7.0)
• Relevant config: an account with at least one LID-using contact whose mapping is on disk

Steps

1. Start with an OpenClaw account paired to WhatsApp Web; receive any message from a contact so Baileys writes the forward and reverse lid-mapping-*.json for them.
2. Have an agent invoke the message tool to send to that contact's phone number.
3. Observe the outbound JID Baileys is asked to send to and where the message lands.

Expected

• Outbound JID: {lid}@lid. Message arrives in the recipient's existing thread on Android/iOS and on the recipient's WhatsApp.

Actual (before this PR)

• Outbound JID: {digits}@s.whatsapp.net. A ghost chat appears only on the sender's WA Web; recipient never sees the message.

Evidence

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

The new text-runtime.test.ts and send-api.test.ts LID describe blocks fail against main and pass against this branch.

Human Verification (required)

• Verified scenarios: Helper-level (4 cases for toWhatsappJidWithLid) and integration-level (5 cases for createWebSendApi) covering: PN with mapping, PN without mapping, numeric LID values, already-formed JIDs (group, s.whatsapp.net, lid), legacy path with no authDir, and sendPoll / sendComposingTo parity with sendMessage.
• Edge cases checked: Forward file containing numeric vs string LID, whatsapp: prefix, group JIDs passing through unchanged, missing forward file falling back to PN, no-authDir regression guard.
• What you did NOT verify: Multi-device LID ({lid}:N@lid) — Baileys' on-disk format does not store device specificity for the forward direction, so the LID JID emitted is device-less, matching the working pattern the reporter applied to the compiled bundle. @hosted.lid outbound — same pattern would apply but was not in scope here.

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. No API change visible to callers; authDir is opt-in and defaults to legacy PN-only behavior.
• Config/env changes? No
• Migration needed? No — Baileys already writes the required mapping files; this PR only consumes them.

Risks and Mitigations

• Risk: A forward mapping file might exist for a phone number whose LID is no longer the recipient's active LID (e.g., contact migrated devices). Sending to the stale LID could itself create a delivery hole.
  • Mitigation: This is no worse than the inbound behavior, which already trusts the same files for LID→PN. Baileys keeps the mapping in sync via storeLIDPNMappings whenever a fresh pair is observed. No new write path introduced here.
• Risk: Tests can race if multiple cases reuse a single tmp dir.
  • Mitigation: Each withTempDir / beforeEach creates a fresh mkdtempSync and the afterEach removes it.