Bug type

Behavior bug (incorrect output/state without crash)

Summary

In multi-account Slack setups, sessions_send announce replies use the default bot token instead of the target agent's bot token because the Slack channel plugin does not opt into session-store lookup for announce target resolution.

Steps to reproduce

1. Configure two Slack accounts (e.g., default and forge) with separate bot tokens
2. Agent A (default account) sends a message to Agent B (forge account) via sessions_send
3. Agent B's announce reply posts to the channel

Expected behavior

Agent B's announce reply should be posted using Agent B's bot token (channels.slack.accounts.forge.botToken).

Actual behavior

Agent B's announce reply is posted using Agent A's (default) bot token because resolveAnnounceTarget() returns the key-parsed fallback (which lacks accountId) instead of hydrating it from the session store.

OpenClaw version

2026.2.3+

Operating system

All platforms

Install method

Any

Logs, screenshots, and evidence

Root cause trace:

• resolveAnnounceTarget() in src/agents/tools/sessions-announce-target.ts checks plugin.meta.preferSessionLookupForAnnounceTarget at line 18
• Without this flag, it returns immediately with the key-parsed fallback which never carries accountId
• WhatsApp already sets this flag (extensions/whatsapp/src/channel.ts:46), Slack does not
• When accountId is missing, the delivery layer falls back to the default Slack account

Impact and severity

Affected: All multi-account Slack users using sessions_send between agents on different accounts
Severity: Medium (messages delivered to wrong bot identity)
Frequency: 100% repro in multi-account setups
Consequence: Announce replies appear under the wrong bot, confusing users and breaking multi-agent identity

Additional information

Original issue #14854 was auto-closed by the stale bot without the fix being merged. PR #14912 has a one-line fix (add preferSessionLookupForAnnounceTarget: true to Slack channel meta) plus a regression test.