-
-
Notifications
You must be signed in to change notification settings - Fork 52.7k
Closed as not planned
Closed as not planned
Copy link
Labels
bugSomething isn't workingSomething isn't workingstaleMarked as stale due to inactivityMarked as stale due to inactivity
Description
Bug Description
When using sessions_send to send a message to another agent's session in a multi-account Slack setup, the announce step posts the reply using the default Slack bot token instead of the target agent's bot token.
Expected Behavior
When agent A (Veruca, default Slack account) sends a message to agent B (Forge, separate Slack account) via sessions_send, Forge's announce reply should be posted to the channel using Forge's bot token (channels.slack.accounts.forge.botToken).
Actual Behavior
Forge's announce reply is posted using Veruca's (default) bot token, making it appear as if Veruca posted the message.
Root Cause
In resolveAnnounceTarget() (src/agents/tools/sessions-announce-target.ts), the function:
- Parses the session key → extracts
{ channel: "slack", to: "channel:<id>" }— no accountId - Checks
getChannelPlugin("slack")?.meta?.preferSessionLookupForAnnounceTarget - Since the built-in Slack plugin does not set this flag, it returns the key-parsed fallback immediately
- The session store lookup (which would correctly resolve
accountId: "forge"fromdeliveryContext) is never reached callGateway({ method: "send", params: { accountId: undefined } })falls back to the default Slack bot token
Reproduction
- Configure multiple Slack accounts in
channels.slack.accounts(e.g.,veruca,forge) - Set up bindings routing each account to a different agent
- From the main agent, use
sessions_send(sessionKey: "agent:forge:slack:channel:<id>", message: "...") - Observe that Forge's announce reply appears under Veruca's bot identity in Slack
Environment
- OpenClaw version: 2026.2.9 (33c75cb)
- Channel: Slack (socket mode)
- Multiple accounts configured with separate bot tokens
Suggested Fix
Either:
- Set
preferSessionLookupForAnnounceTarget: trueon the Slack channel plugin meta (so it actually looks up the session store) - Or always resolve
accountIdfrom the target session'sdeliveryContextregardless of the plugin flag — the key-parsed fallback should at minimum try to extract accountId from the session store before returning
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
bugSomething isn't workingSomething isn't workingstaleMarked as stale due to inactivityMarked as stale due to inactivity