Summary

In group chat sessions, user messages stored in the agent session JSONL () are missing the __openclaw metadata block that is present in 1:1 (direct) session messages.

Expected behaviour

Group chat user messages should include sender identity metadata — at minimum senderId / sender_id — so that agents can distinguish between different human participants in a group.

In direct (1:1) sessions, user messages include a full metadata envelope:

{
  "role": "user",
  "content": "...",
  "timestamp": 1780628953073,
  "__openclaw": {
    "from": {
      "id": "8489979671",
      "first_name": "Ram",
      "last_name": "Shenoy"
    },
    "senderId": "8489979671"
  }
}

Actual behaviour

Group chat user messages contain only:

{
  "role": "user",
  "content": "...",
  "timestamp": 1780628953073
}

No __openclaw block, no sender ID, no name.

Impact

• Agents cannot attribute group messages to specific participants
• Group transcript loggers (e.g. scripts reading the JSONL to build memory/transcript files) cannot distinguish between human members — all user messages appear as a generic USER label
• This makes group memory systems significantly less useful: context like "Gari asked X" vs "Ram asked Y" is lost

Context

Discovered while implementing a group chat transcript/memory system for a Telegram group (Klub K: Ram + Garima + Purl bot). The Telegram gateway clearly has the sender identity at the envelope level (it is present in the inbound metadata delivered to the agent) — it is just not being persisted to the JSONL record.

Proposed fix

When writing a user message record to the session JSONL for a group chat session, include the same __openclaw metadata block that is already present in direct session records. At minimum:

"__openclaw": {
  "from": {
    "id": "<telegram_user_id>",
    "first_name": "<name>"
  },
  "senderId": "<telegram_user_id>"
}

Workaround

None currently. ID-to-name maps can be pre-coded in scripts, but without the ID in the JSONL the mapping cannot be applied.