Group chats: attach sender to LLM messages array entries so attribution survives the rolling context window

[kydorn]

Context

This is a follow-up to #77346, which was closed by ClawSweeper as "already implemented" pointing to buildInboundUserContextPrefix in src/auto-reply/reply/inbound-meta.ts. That analysis is correct for the current turn — but misses a gap that surfaces specifically with contextInjection: "continuation-skip".

The gap

With continuation-skip, openclaw does not re-inject conversation history into each new agent run. Previous turns sit in the model's rolling context window as plain body text — the structured metadata blocks (Sender (untrusted metadata):, Chat history since last reply:) that accompanied those turns are not re-injected alongside them. So the model can see what was said in prior turns but not who said it.

The structured metadata path correctly attributes the current turn. It does not make attribution durable across the context window.

Concrete example

Group chat between Alice, Bob, and Carol with contextInjection: "continuation-skip":

1. Alice: "Can someone help with X?" → agent replies
2. Bob: "I tried Y but it didn't work" → agent replies
3. Carol: "I agree with Bob" → agent replies

At turn 3, turns 1 and 2 are in the context window as raw body text with no sender prefix. The agent cannot tell it was Bob (not Alice) who tried Y, or confirm Carol is agreeing with Bob specifically. The structured block for turn 3 correctly identifies Carol as the current sender — but the history is opaque.

Why inline body prefixes complement the structured approach

Baking Alice: directly into BodyForAgent (which gets stored in the conversation transcript) means attribution persists in the rolling context window regardless of history re-injection. The two approaches are not mutually exclusive — they solve different layers of the same problem:

• Structured metadata blocks → attribution for the current turn (prompt-injection safe, structured)
• Inline body prefix → attribution that survives across the context window in the transcript

Suggested fix

A groupSenderPrefix option (defaulting to true for ChatType === "group") that inlines sender attribution into BodyForAgent and InboundHistory[].body:

BodyForAgent: isGroup && senderName
  ? `${senderName}: ${bodyText}`
  : bodyText,

This is exactly what ships in the existing inline-body envelope (Body/combinedBody already prepends sender via formatInboundEnvelope with senderLabel). The ask is to extend the same treatment to BodyForAgent so the transcript-stored version carries attribution too.

[kydorn]

Better approach: per-message sender context in the LLM messages array

The inline body prefix suggested in the issue description (Alice: message) is a workaround, not a proper fix. The right solution is to attach sender attribution at the messages-array level, so each entry in the conversation history carries its sender as structured metadata rather than polluting the body text.

What this looks like

The OpenAI chat completions format has a name field on messages specifically for this:

{"role": "user", "name": "Alice", "content": "Can someone help with X?"}
{"role": "assistant", "content": "..."}
{"role": "user", "name": "Bob", "content": "I tried Y but it didn't work"}
{"role": "assistant", "content": "..."}
{"role": "user", "name": "Carol", "content": "I agree with Bob"}

The model sees structured sender identity on every turn, not a text prefix it has to parse. For Anthropic-format APIs (no native name field), the equivalent is a short sender content block prepended to each message's content array.

Why this is the correct fix

1. Survives across the context window — attribution is stored with the message, not in an ephemeral metadata block that isn't re-injected on continuation turns.
2. No body pollution — BodyForAgent stays clean; sender identity lives in the right layer.
3. Structured, not parsed — the model doesn't need to infer Alice: from freeform text.
4. Works with all injection modes — whether history is re-injected or carried natively in the context window, the attribution travels with the message.

What openclaw would need to do

When storing a conversation turn to the transcript / messages array, include the sender (already available as SenderName) as the name field on the user message — or as a minimal structured prefix in the content block for providers that don't support name. The SenderName data is already flowing through the pipeline; it just needs to be written to the messages layer rather than discarded after the current-turn metadata block is built.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve.

Summary
Keep open: current main still keeps group sender attribution in prompt-local/current-turn metadata while the durable user transcript entry remains plain body text, so the reported continuation-skip attribution gap remains source-reproducible. The linked Slack PR is open, protected, and Slack-specific rather than a merged generic message-array attribution fix.

Reproducibility: yes. by source inspection. SenderName and InboundHistory reach current-turn prompt context, while transcriptPrompt/transcriptBody remain clean user text and continuation-skip can rely on prior transcript entries without re-injecting prior metadata blocks.

Next step
The remaining work crosses durable transcript shape, provider adapter behavior, and prompt-injection/trust semantics, so it needs maintainer product/design review before a repair PR.

Review details

Best possible solution:

Define a generic persisted sender-attribution contract for user transcript messages, map it safely at provider boundaries, and add continuation-skip group-chat regression coverage.

Do we have a high-confidence way to reproduce the issue?

Yes, by source inspection. SenderName and InboundHistory reach current-turn prompt context, while transcriptPrompt/transcriptBody remain clean user text and continuation-skip can rely on prior transcript entries without re-injecting prior metadata blocks.

Is this the best way to solve the issue?

Unclear. Message-array-level attribution is the right layer for durable sender identity, but the transcript schema, provider mapping, and untrusted-sender semantics need maintainer design before implementation.

What I checked:

• Live issue discussion narrows the request: The issue body and follow-up comment distinguish current-turn metadata from durable rolling-context attribution and request sender identity at the LLM messages-array/transcript layer rather than only current-turn prompt context.
• Current-turn sender/history metadata exists: buildInboundUserContextPrefix builds Conversation info, Sender, and bounded Chat history blocks using SenderName and InboundHistory sender/body fields, but these are runtime prompt-context blocks for the active turn. (src/auto-reply/reply/inbound-meta.ts:436, 0ad3d25fb7cd)
• Durable transcript body remains clean base text: buildReplyPromptEnvelopeBase places ordinary inbound context in currentTurnContext while transcriptBody stays params.baseBody for normal user turns; the adjacent test asserts transcriptCommandBody remains the clean message text. (src/auto-reply/reply/prompt-prelude.ts:173, 0ad3d25fb7cd)
• Continuation-skip omits bootstrap context on later turns: resolveAttemptBootstrapContext marks completed continuation-skip turns as continuation turns and returns empty bootstrapFiles/contextFiles, matching the path where prior user transcript messages remain in the model window without re-injected prior metadata. (src/agents/pi-embedded-runner/run/attempt.context-engine-helpers.ts:37, 0ad3d25fb7cd)
• Historical runtime context is stripped before LLM boundary: normalizeMessagesForLlmBoundary strips historical openclaw.runtime-context custom messages, preserving only current-turn runtime context after the last user message rather than replaying older sender metadata as durable history. (src/agents/pi-embedded-runner/run/attempt.ts:653, 0ad3d25fb7cd)
• Slack remains raw on current main, with an open channel-specific PR: Current main builds Slack ctxPayload.message.bodyForAgent from rawBody. The related PR is open at d13bf8a with channel: slack and maintainer labels, and it adds opt-in Slack body-prefix behavior rather than a merged generic message-array contract. (extensions/slack/src/monitor/message-handler/prepare.ts:1099, 0ad3d25fb7cd)

Likely related people:

• @steipete: Current history and GitHub commit metadata show recent work across inbound metadata, prompt envelope, room-event gating, and the continuation/context surface relevant to durable prompt attribution. (role: recent prompt/context contributor; confidence: high; commits: 2e5a86adfea7, 3fa9658b392e, 532759e1ab2e; files: src/auto-reply/reply/inbound-meta.ts, src/auto-reply/reply/prompt-prelude.ts, src/agents/pi-embedded-runner/run/attempt.context-engine-helpers.ts)
• @vincentkoc: Authored the recent continuation-skip bootstrap preload change that directly affects whether previous metadata is re-injected on continuation turns. (role: recent adjacent contributor; confidence: medium; commits: a47132734ba2; files: src/agents/pi-embedded-runner/run/attempt.context-engine-helpers.ts, src/agents/pi-embedded-runner/run/attempt.spawn-workspace.context-injection.test.ts)
• @obviyus: Recent main history maps room-event turn semantics and prompt-prelude changes in the same prompt assembly area to Ayaan Zaidi, adjacent to the current-turn versus durable-transcript boundary. (role: recent prompt-turn contributor; confidence: medium; commits: 503c3d139c9a, 56cc15077158, 7ed4ad8d1779; files: src/auto-reply/reply/prompt-prelude.ts, src/agents/pi-embedded-runner/run/attempt.ts, extensions/telegram/src/bot-message-context.session.ts)

Remaining risk / open question:

• No live multi-participant channel run was executed; the reproduction is based on source and live issue/PR state.
• The durable schema and provider conversion contract are unresolved, especially for providers without native per-message sender fields.
• The docs say non-direct current message bodies are sender-prefixed, while current Slack/Telegram source keeps BodyForAgent clean, so the intended contract needs reconciliation.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 0ad3d25fb7cd.