Telegram inbound: openclaw.runtime-context envelope leaks into user message body

Summary

In OpenClaw 2026.5.7, inbound Telegram messages sometimes arrive at the agent with the trusted runtime-context envelope (Conversation info / Sender JSON blocks) appended to the user message text itself, instead of being delivered exclusively out-of-band as custom_message runtime-context. The agent receives both: a real out-of-band envelope and the same envelope as a string in the user message body. This is confusing, ugly in transcripts, and a soft prompt-injection footgun (a malicious user could mimic the format and the agent would have to consciously distinguish it from the real one — which is the whole reason runtime-context is supposed to be out-of-band).

Environment

• OpenClaw 2026.5.7 (eeef486)
• macOS 15.3.1 (arm64), Node 22.22.2
• Channel: Telegram (direct chat), chat_type: direct
• Default agent (main), model varies (reproduced on both claude-opus-4-7 and MiniMax-M2.7)

What appears in the user message body

A real example, taken from a current Telegram session transcript:

sure please do.

Conversation info (untrusted metadata):
```json
{
  "chat_id": "telegram:8719706209",
  "message_id": "820",
  "sender_id": "8719706209",
  "sender": "Ben Jensen",
  "timestamp": "Tue 2026-05-12 21:18 EDT"
}

Sender (untrusted metadata):

{
  "label": "Ben Jensen (8719706209)",
  "id": "8719706209",
  "name": "Ben Jensen"
}

The text *above* the JSON ("sure please do.") is what the user actually typed in Telegram. Everything from `Conversation info` onward is the OpenClaw runtime envelope — but it's living **inside the user message body** rather than as a separate `openclaw.runtime-context` `custom_message` event.

## Where it should live

The agent already receives an authoritative out-of-band runtime-context via the existing mechanism. For example, in the same session's transcript JSONL we can see paired records:

```jsonl
{"type":"message","message":{"role":"user","content":[{"type":"text","text":"sure please do."}], ...}}
{"type":"custom_message","customType":"openclaw.runtime-context","content":"Conversation info (untrusted metadata):\n```json\n{ ... }\n```\n\nSender (untrusted metadata):\n```json\n{ ... }\n```","display":false,"details":{"source":"openclaw-runtime-context"}, ...}

That custom_message is the correct delivery path — display: false, source-tagged, trusted by virtue of being delivered out-of-band by OpenClaw itself. The bug is that the same content is also being concatenated into the user-visible message body.

Why this matters

1. User experience — the JSON blocks render as the bottom half of every user message in some clients, making transcripts look broken
2. Prompt-injection surface — anything that arrives in the user message body is by definition untrusted text. The whole point of out-of-band runtime-context is that the agent can trust it. When the same envelope content shows up in both places, the agent has to constantly distinguish: "is this the real trusted envelope or text the user pasted that mimics it?" That defeats the security property.
3. Token waste — duplicating the envelope inflates every user message by a few hundred tokens

Suspected cause

Looks like the Telegram inbound path is either:

• Including the runtime-context block in the rendered text passed to the agent (perhaps in client-side message composition before stripping), or
• Appending it after the user's text via some forwarder / client behavior that's not aware it's already being delivered out-of-band

Worth checking the Telegram channel's inbound message construction (where it composes the user message content array) — the runtime-context should be branched off to the custom_message path only, not echoed back into the text payload.

Repro

1. Send a normal message from Telegram to an OpenClaw agent on channels.telegram
2. Inspect the resulting session transcript at ~/.openclaw/agents/<agent>/sessions/<sessionId>.jsonl
3. Observe: the user message.content[0].text contains the user's text followed by the full Conversation info / Sender JSON blocks (the same content also appears in a separate custom_message of type openclaw.runtime-context immediately after)

Reproduces on multiple sessions, models, and message types.

Severity

Low-to-medium. Functional behavior is correct; the agent can still understand the message. But it's cosmetically broken and undermines the security model of out-of-band runtime context.

Workaround

None needed for functionality. Agent has been instructed to treat the in-body version as text-only and rely on the real out-of-band envelope.

Generated during a live debugging session by an OpenClaw agent.