Skip to content

sessions_send announce step uses wrong Slack accountId in multi-account setups #14854

@khuzad

Description

@khuzad

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:

  1. Parses the session key → extracts { channel: "slack", to: "channel:<id>" }no accountId
  2. Checks getChannelPlugin("slack")?.meta?.preferSessionLookupForAnnounceTarget
  3. Since the built-in Slack plugin does not set this flag, it returns the key-parsed fallback immediately
  4. The session store lookup (which would correctly resolve accountId: "forge" from deliveryContext) is never reached
  5. callGateway({ method: "send", params: { accountId: undefined } }) falls back to the default Slack bot token

Reproduction

  1. Configure multiple Slack accounts in channels.slack.accounts (e.g., veruca, forge)
  2. Set up bindings routing each account to a different agent
  3. From the main agent, use sessions_send(sessionKey: "agent:forge:slack:channel:<id>", message: "...")
  4. 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: true on the Slack channel plugin meta (so it actually looks up the session store)
  • Or always resolve accountId from the target session's deliveryContext regardless of the plugin flag — the key-parsed fallback should at minimum try to extract accountId from the session store before returning

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't workingstaleMarked as stale due to inactivity

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions