hermes - 💡(How to fix) Fix [Bug]: send_message silently delivers to home channel and reports success when target resolution fails (WhatsApp LID format) [1 pull requests]

Bug Description

When send_message is called with a valid LID-format WhatsApp target from inside a user session, the tool silently delivers the message to the current session's chat (treated as the "home channel") instead of the requested target. It then returns a "success" string naming the wrong chat_id, leaving the agent with no signal that the message went to the wrong place.

This appears to be the WhatsApp manifestation of #5472 (send_message target resolution ignores session context), with an added twist: the failure mode is silent — no error is raised, and the tool's own success message reveals the misdelivery only on close reading.

Steps to Reproduce

1. Configure the WhatsApp gateway with two allowed users — call them B (the operator chatting with the agent) and C (a separate contact, both confirmed as distinct LIDs in ~/.hermes/whatsapp/session/lid-mapping-*_reverse.json).

2. From B's chat, ask the agent to send a message to C with an explicit LID target: Call send_message(target="whatsapp:<C-LID>@lid", message="hello")

3. The agent issues the correct tool call with the correct arguments (verified in the agent log).

4. The tool returns: The message was successfully sent to the WhatsApp home channel (chat_id: <B-LID>@lid). where <B-LID> is the current session's LID, not C's.

5. The message lands in B's chat with the bot, not in C's.

Expected Behavior

Either deliver to <C-LID>@lid, or — if the target cannot be resolved — return an explicit error (as the tool already does for some other failures, e.g. "Could not resolve '<phone>@s.whatsapp.net' on whatsapp"). Never silently reroute to the session chat, and never report a fallback as success.

Confirming the bridge is healthy

Posting directly to the local Baileys bridge delivers correctly to C:

curl -sS -X POST http://127.0.0.1:3000/send \
  -H 'Content-Type: application/json' \
  -d '{"chatId":"<C-LID>@lid","message":"test"}'

So the bug is isolated to send_message's target resolution / fallback logic — not the bridge, not the LID, not the contact directory (which correctly distinguishes the two contacts on disk).

Actual Behavior

tool returns "The message was successfully sent to the WhatsApp home channel (chat_id: <session-chat-LID>)." — message lands in the current session's chat, not the target

Agent log excerpt (failing turn, identifiers redacted)

inbound message: user=B chat=<B-LID>@lid msg='Call send_message(target="whatsapp:<C-LID>@l...' tool send_message completed (0.44s, 205 chars) response ready: chat=<B-LID>@lid response=277 chars [Whatsapp] Sending response (277 chars) to <B-LID>@lid

No outbound to <C-LID>@lid was logged. The 205-char tool output was the false success string, which the agent then summarised back to B.

Related issues

• #5472 — send_message target resolution doesn't read HERMES_SESSION_CHAT_ID
• #14486 — LID format migration broke phone-number JID resolution
• #1945 — label-format targets (whatsapp:<name>) fail with Baileys jidDecode error

Affected Component

Tools (terminal, file ops, web, code execution, etc.)

Messaging Platform (if gateway-related)

WhatsApp

Debug Report

NaN

Operating System

Ubuntu 24.04

Python Version

No response

Hermes Version

No response

Additional Logs / Traceback (optional)

Root Cause Analysis (optional)

No response

Proposed Fix (optional)

No response

Are you willing to submit a PR for this?

• I'd like to fix this myself and submit a PR