Summary

On Slack, a single inbound system event is rendered twice in one assembled turn. The notification header System: [timestamp] Slack DM from <user> appears both inside an OpenClaw runtime context for the immediately preceding user message wrapper and again standalone just before the raw user text, with the same timestamp and the same label. The user body itself is delivered once; it is the system-event header that is duplicated.

This is distinct from the preview fix in #94549 / #94589. That change removed the 160-character body preview from the enqueued system event, so each header is now notification-only. It did not change how many times the event is rendered. Before that fix each of the two copies carried the truncated preview (so a message appeared three times: two previews plus the raw body); after it, the two copies are label-only, but there are still two of them. Removing the duplicate rendering was out of scope for that PR.

Environment

OpenClaw 2026.6.1, Linux, Node 24. Channel: Slack (first-party @openclaw/slack), direct message.

Reproduction

1. Send any inbound message from Slack.
2. Capture the model-facing request (the provider payload).
3. Observe the same System: header in two separate messages of the same turn.

Evidence (redacted model-facing payload, one turn)

Two adjacent messages in the same request, identical timestamp:

Message A (a standalone runtime-context message immediately preceding the user turn):

OpenClaw runtime context for the immediately preceding user message.
This context is runtime-generated, not user-authored. Keep internal details private.

System: [2026-06-20 13:59:51] Slack DM from <user>

Message B (the user message itself, header prepended before the raw text):

Conversation info (untrusted metadata):
{ ...redacted... }

Sender (untrusted metadata):
{ ...redacted... }

System: [2026-06-20 13:59:51] Slack DM from <user>

<the actual user text>

Both System: lines carry the same timestamp, confirming this is one event rendered twice in a single turn, not conversation-history replay (which would differ in timestamp) and not a second model call.

Channel contrast

A Telegram direct message in the same setup produces no System: header at all: the Telegram inbound path does not enqueue an inbound system event, so the user message arrives bare (no header, no metadata wrapper). The duplication is specific to channels that enqueue an inbound system event, which Slack does.

Likely area (hypothesis, for maintainer confirmation)

The two render sites appear to be:

1. The runtime-context split that extracts runtime-generated context into a separate OpenClaw runtime context for the immediately preceding user message message.
2. The reply-body assembly that prepends the drained system-event block into the user prompt body.

The drained inbound system event seems to be carried by both paths in the same turn, so the header is both extracted into the runtime-context message and left prepended in the body, rather than appearing once. Maintainers can confirm the exact flow.

Impact

Low severity, no data loss. The body is intact and the header is label-only since #94589, so this is a small amount of duplicated metadata per inbound turn: a redundant context block, a few wasted tokens, and a slightly inconsistent turn structure presented to the model. It is most visible on channels that enqueue inbound system events, and it compounds visually in busy multi-party Slack conversations.