Skip to content

Feature: Include trusted sender_name in inbound metadata envelope #45427

@scekker

Description

@scekker

Summary

The current inbound metadata envelope provides sender_id (a trusted, platform-injected identifier) but not a resolved sender_name. Agents are forced to do their own name resolution — either via a local registry lookup or, incorrectly, by reading conversational context (untrusted).

This leads to a real failure mode: agents read names from prior messages or channel context and misroute DMs to the wrong person. We saw this today when Mendel sent messages intended for Steve to a different user because a name mentioned in conversation context bled into the wrong session.

Proposed Solution

Add a trusted sender_name field to the inbound metadata envelope, resolved by OpenClaw from the server's user directory at message ingestion time — the same way sender_id is already injected.

Current envelope (example):

{
  "sender_id": "927709652014215199",
  "sender": "scekker"
}

Proposed envelope:

{
  "sender_id": "927709652014215199",
  "sender": "scekker",
  "sender_display_name": "Stephen Ekker"  // resolved from server directory, trusted
}

Why This Matters

  • Security: Names in conversational context can be impersonated or drift across sessions. Only the platform-resolved identity is trustworthy.
  • Correctness: Agents shouldn't need local workaround registries to do basic identity resolution — this is a platform responsibility.
  • Failure mode is real: Agent DM misrouting to wrong users has already occurred in production (Mar 13, 2026). The current workaround (per-agent registry SOPs) is fragile and can be forgotten.

Current Workaround

Agents maintain local people/registry.json files and are instructed via SOP to always look up sender_id before composing any message. This works but is an agent-level patch for a platform-level gap.

Context

Reported by the Ekker Lab / UViiVe AI fleet. Fleet runs multiple agents (Atlas, Zevo, Uvy, S.A.R.A.H., Buster, Pip, Mendel) across Discord channels and DMs. Identity misrouting in this context has real consequences — wrong person receives sensitive research coordination or private messages.

/cc @scekker

Metadata

Metadata

Assignees

No one assigned

    Labels

    P1High-priority user-facing bug, regression, or broken workflow.clawsweeper:needs-live-reproClawSweeper needs live local, crabbox, or manual validation to confirm this issue.clawsweeper:needs-product-decisionClawSweeper marked this issue as needing a product or behavior decision.clawsweeper:no-new-fix-prClawSweeper does not recommend queueing a new automated fix PR for this issue.impact:message-lossChannel message delivery can be lost, duplicated, or misrouted.impact:securitySecurity boundary, credential, authz, sandbox, or sensitive-data risk.impact:session-stateSession, memory, transcript, context, or agent state can drift or corrupt.issue-rating: 🐚 platinum hermitGood issue quality with a plausible reproduction path needing some confirmation.

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions