Summary

Agent identity (name/avatar) configured via agents.list[].identity is not applied to Slack channel replies, always posting as the default bot name/avatar despite chat:write.customize scope being present.

Steps to reproduce

1. Create an agent with configured identity:

{
  "id": "tech-writer",
  "identity": {
    "name": "Quill",
    "emoji": "🪶",
    "avatar": "https://emoji.slack-edge.com/T395D6FP1/quill/49e50c4dc6379d6e.png"
  }
}

2. Configure bindings to route messages from a specific Slack channel to this agent.
3. Send a message in that channel.
4. Observe the agent's response.

Expected behavior

The agent's reply should display with the configured identity name ("Quill") and avatar image, using the chat:write.customize scope to override the bot's default profile via username and icon_url in chat.postMessage.

Actual behavior

The reply posts with the bot's default registered name and avatar. The username and icon_url parameters are never included in the Slack API call, even though chat:write.customize scope is active on the bot token.

OpenClaw version

2026.2.17

Operating system

Linux 6.8.0-83-generic (x64)

Install method

npm global

Logs, screenshots, and evidence

- Verified via auth.test that chat:write.customize scope is present: x-oauth-scopes: ... chat:write.customize ...
- Agent config verified to contain identity fields: identity: { name: "Quill", emoji: "🪶", avatar: "https://..." }
- Root cause traced in source: sendMessageSlack() correctly accepts opts.identity, but the channel reply path in reply-oSe13ewW.js never passes identity in the opts when calling sendMessageSlack(). The identity object is correctly constructed from config (including avatarUrl resolution) but never threaded through to the outbound send handler for inbound-triggered replies.
- Workaround: using the message tool for proactive sends works correctly and applies identity.

Impact and severity

• Affected users/systems/channels: Any OpenClaw deployment using multi-agent Slack configurations where individual agents are assigned distinct identities (name/avatar). Specifically affects replies sent via the channel reply path — DMs and proactive message tool calls are unaffected.

• Severity: Workflow-blocking for the intended use case. The agents.list[].identity config fields exist and are documented, the chat:write.customize Slack scope is supported, and sendMessageSlack() correctly implements the override — the plumbing simply never connects. Users who configure agent identity expecting it to work in channel replies will silently get no effect; no error is surfaced.

• Frequency: Always — 100% reproducible. Any agent with a configured identity replying to a channel message will post as the default bot identity.

• Consequence: Operators running multi-agent setups (e.g., a docs agent, a DevOps bot, an assistant agent all sharing one Slack app) cannot visually differentiate agents to end users. The practical forcing function is to provision separate Slack apps with separate bot tokens per agent — extra setup cost, extra OAuth apps to manage, extra tokens to rotate — to achieve what the identity config is designed to do natively. For teams relying on Quill/Forge/etc. to be recognizable, distinct presences in Slack, this makes the feature effectively unusable without that workaround.

Additional information

No response