WhatsApp gateway connected. Conversation info (untrusted metadata) | Friends of the Crustacean 🦞🤝 | Page 1

marsh igloo Feb 14, 2026, 8:53 AM

#

WhatsApp gateway connected.

Conversation info (untrusted metadata):

{
"conversation_label": "XXXX user id:2988058002020200801"
}

What is this? in the main:main session.

nocturne owlBOT Feb 14, 2026, 8:55 AM

#

That block is not something WhatsApp sent you — it’s OpenClaw’s own “inbound context” wrapper that gets prepended to messages so the agent knows which conversation / thread / sender a message came from.

“Conversation info (untrusted metadata)” = details coming from the chat platform (names, channel titles, thread labels, etc.). OpenClaw marks it untrusted because those strings can be user-controlled (renamed channels, display names, etc.) and shouldn’t be treated as authoritative instructions.
conversation_label: "XXXX user id:2988058002020200801" = a human-friendly label OpenClaw constructs to help you disambiguate chats. On Discord this typically includes the Discord user id (or channel id). It’s mainly for debugging / session routing clarity.
Seeing it in main:main just means this event/message got routed into your default “main” session (common for status-ish events like “gateway connected”, or if there isn’t a more specific session target yet).

If you tell me where you’re seeing it (dashboard session transcript? logs? Discord message?) and whether it’s causing actual unwanted replies, I can point to the exact knob/workaround—but the presence of that JSON block by itself is expected/normal.

marsh igloo Feb 14, 2026, 8:57 AM

#

dashboard session transcript. when I message from discord. but message didnt go to the whatsapp conversation.

nocturne owlBOT Feb 14, 2026, 8:59 AM

#

That’s expected behavior — session transcript ≠ delivery target.

Why your Discord message didn’t show up in WhatsApp

OpenClaw’s routing is deterministic:

Replies go back to the channel where the message came from.
The model/session doesn’t “pick” WhatsApp vs Discord.

So if you message from Discord, the run is a Discord inbound, and the reply routes back to Discord, not WhatsApp.
Docs: https://docs.openclaw.ai/channels/channel-routing

Also, when you chat from the dashboard/Control UI/WebChat, routing is back to WebChat:
Docs: https://docs.openclaw.ai/web/webchat (see “Deterministic routing: replies always go back to WebChat.”)

Why it’s confusing in the dashboard transcript (main:main)

By default, DMs collapse into the agent’s main session (session.dmScope = "main"), so Discord DMs + WhatsApp DMs can share agent:main:main, and you’ll see mixed context in one transcript — but delivery still goes to the originating channel.

#

If you want clearer separation in the dashboard, set:

{
  session: {
    dmScope: "per-channel-peer"
  }
}

Then you’ll get distinct session keys like:

agent:main:discord:direct:<id>
agent:main:whatsapp:direct:<id>

If your goal is “send something to a WhatsApp chat”

You have two options:

Message the bot from WhatsApp (recommended) — then the reply routes to that WhatsApp conversation.

#

Build an explicit “bridge” behavior (custom automation/skill) that sends to WhatsApp on purpose — it won’t happen automatically from a Discord inbound.

If you paste your session.dmScope setting (or your openclaw.json session block), I can tell you exactly what session keys you should expect to see for Discord vs WhatsApp.

marsh igloo Feb 14, 2026, 9:09 AM

#

how about this? "identityLinks: map canonical ids to provider-prefixed peers for cross-channel session sharing."

#

what is "identityLinks"?

nocturne owlBOT Feb 14, 2026, 9:18 AM

#

session.identityLinks is purely a session-key mapping feature.

It lets you tell OpenClaw: “these different peer ids (Discord user id, Telegram id, WhatsApp number, …) are actually the same human → treat them as one canonical identity for session bucketing.”

What the config looks like

{
  session: {
    dmScope: "per-peer", // or per-channel-peer / per-account-channel-peer
    identityLinks: {
      alice: [
        "discord:222222222222222222",
        "telegram:111111111",
        "whatsapp:+15551234567"
      ]
    }

#

}
}

Key (alice) = your canonical id (any string you choose).
Values = provider-prefixed peer ids in the form <channel>:<peerId>.

What it actually changes

When dmScope is not "main", OpenClaw will replace the raw <peerId> in the DM session key with the canonical id if it matches.

With dmScope: "per-peer" this does collapse cross-channel DMs into one session:
- telegram DM from 111111111 → agent:main:direct:alice
- discord DM from 2222... → agent:main:direct:alice
With dmScope: "per-channel-peer" it still keeps separate sessions per channel, but the peer part becomes canonical:
- discord DM → agent:main:discord:direct:alice

#

telegram DM → agent:main:telegram:direct:alice

What it does not do

It doesn’t change delivery/routing.

So it won’t make “a Discord message go out to WhatsApp”. It only affects which transcript/session is used for context when that person messages you on different channels.

Docs worth skimming:

Session management (dmScope + identityLinks): https://docs.openclaw.ai/concepts/session
Config reference snippet: https://docs.openclaw.ai/gateway/configuration-reference

If you tell me which dmScope you’re using (main vs per-peer vs per-channel-peer), I can tell you exactly what session keys you should expect to see in the dashboard for your Discord user id + WhatsApp number.

civic orchid Feb 18, 2026, 3:32 PM

#

nocturne owl - telegram DM → `agent:main:telegram:direct:alice` ### What it does *not* do It...

i don't want to see it, how can i do ?

nocturne owlBOT Feb 18, 2026, 3:39 PM

#

That line is coming from OpenClaw itself: every time the WhatsApp Web socket reconnects, the Gateway enqueues a “WhatsApp gateway connected …” system event into whatever session WhatsApp is routed to. If your WhatsApp route points at the default agent, that ends up in agent:main:main.

Can I disable that message?

Right now: no config switch to turn it off (it’s hardcoded as a system event on connect).

Best workaround (keep `main:main` clean)

Route WhatsApp to a different agent, so the connect noise goes to that agent’s main session instead:

{
agents: {
list: [
{ id: "main", default: true },
{ id: "whatsapp" },
],
},

#

bindings: [
{ agentId: "whatsapp", match: { channel: "whatsapp" } },
],
}

Docs: https://docs.openclaw.ai/gateway/configuration-reference (see bindings + multi-agent patterns)

If you only want to remove the existing entry

You can /reset the session, or delete the session entry/transcript on the gateway host (it’ll be recreated on demand) — but it will still reappear on the next WhatsApp reconnect.

If you tell me where you’re seeing it (Control UI transcript vs session list vs actual chat), I can point you to the least-annoying fix for that exact view.

foggy hinge Feb 19, 2026, 6:11 PM

#

I see it directly in the chat

#

There is also some more, when I click on "new session" this happens:

System: [2026-02-19 19:10:06 GMT+1] Exec completed (neat-gla, code 0) :: src/auto-reply/reply/inbound-meta.ts src/auto-reply/reply/inbound-meta.test.ts

A new session was started via /new or /reset. Greet the user in your configured persona, if one is provided. Be yourself - use your defined voice, mannerisms, and mood. Keep it to 1-3 sentences and ask what they want to do. If the runtime model differs from default_model in the system prompt, mention the default model. Do not mention internal steps, files, tools, or reasoning.

nocturne owlBOT Feb 19, 2026, 6:15 PM

#

That block is generated by OpenClaw, not by WhatsApp/the other person.

Two separate things are happening:

“WhatsApp gateway connected.”
OpenClaw’s WhatsApp Web listener posts a system event internally when it reconnects/logs in, so the next agent turn (often main:main) has the context “hey, WhatsApp is back online”. It’s informational.
“Conversation info (untrusted metadata)”
OpenClaw prepends a small JSON blob describing where the message came from (channel/thread labels, sender label, etc.). It’s marked untrusted on purpose because names/titles/subjects can be attacker-controlled text — the model should treat it as context, not instructions.

So: it’s normal, and it’s not being sent to your WhatsApp contacts—it’s just part of the prompt/context OpenClaw stores/displays for that session.

If you tell me:

your openclaw --version, and
where exactly you’re “seeing it” (Control UI transcript vs Discord vs WhatsApp),

…I can tell you whether this is expected UI behavior or something we should treat as a bug/UX issue.

#

That text is prompt/context that OpenClaw feeds to the model, and you’re seeing it in (at least) two different “wrappers”:

1) `[Queued messages while agent was busy] … Conversation info (untrusted metadata)`

This is OpenClaw’s follow‑up queue. If messages arrive while the agent is still working, OpenClaw batches them into one “collect” prompt and prefixes each queued item with:

Conversation info (untrusted metadata) (channel/thread labels, group subject, etc.)
Sender (untrusted metadata)

It’s marked untrusted because names/titles/subjects can be attacker-controlled strings. This is normal and intended for safety/context.

2) `A new session was started via /new or /reset…`

When you click New session (or send /new//reset) without additional text, OpenClaw replaces the empty input with that internal instruction (BARE_SESSION_RESET_PROMPT) so the model knows to greet you.

You typically only notice this if you’re looking at a prompt/trace view (or if a model is “echoing” the prompt back, which can happen with some misconfigured/weak instruction-following models).

3) `System: Exec completed (…) :: src/auto-reply/reply/inbound-meta.ts …`

That line is a system event emitted when an exec tool run that was backgrounded finishes. By default, OpenClaw posts a short “Exec completed…” summary into the next turn’s context.

#

If you don’t want those, disable it in config:

{
  tools: {
    exec: {
      notifyOnExit: false
    }
  }
}

Docs: https://docs.openclaw.ai/gateway/configuration-reference (see tools.exec)

One key clarification so I can point you to the exact fix:

#

Where exactly are you seeing these strings?

In the Dashboard/Control UI (a “prompt”, “trace”, or “input to model” panel)? → then it’s expected.
Or as an actual message posted by the bot into Discord/WhatsApp? → then it’s not expected, and I’ll want your openclaw --version + which model/provider you’re using (that symptom usually means the model/provider adapter is echoing the prompt).

foggy hinge Feb 21, 2026, 8:14 PM

#

The newest update fixed the issue

#WhatsApp gateway connected. Conversation info (untrusted metadata)