openclaw - 💡(How to fix) Fix Slack DM read path ignores userToken and uses bot token only [1 participants]

Summary

Slack DM history reads appear to ignore the configured userToken and always use the bot token. This breaks DM readback even when sending works and a read-capable userToken is configured on the Slack account.

Environment

• OpenClaw 2026.3.31 (213a704)
• Slack channel integration in Socket Mode
• Multi-account Slack config
• channels.slack.defaultAccount = "reese"
• channels.slack.accounts.reese.userToken configured
• channels.slack.accounts.reese.botToken configured

Observed behavior

What works

• Sending a DM to a Slack user works
• Manual reactions work
• Ack reactions work in Slack DM

What fails

Reading the DM thread back via the message/read tool fails.

Repro from an active install:

1. Send a DM explicitly from Slack account reese to user U03B98862MV
2. OpenClaw returns:
   • messageId: 1775076461.846699
   • channelId: D0AQ59TGMU3
3. Immediately call Slack read on that exact channel and account:

{
  "action": "read",
  "channel": "slack",
  "channelId": "D0AQ59TGMU3",
  "accountId": "reese",
  "limit": 10
}

1. Result:

An API error occurred: channel_not_found

Earlier attempts against the same DM also produced:

An API error occurred: missing_scope

Expected behavior

When a Slack account has a configured userToken, Slack read operations (especially DM history reads) should prefer the user token or otherwise honor the documented read-token behavior, rather than forcing bot-token-only reads.

Likely root cause

The Slack read path appears to always resolve the bot token.

Relevant code in the built distribution:

probe--IEvIVqV.js

async function readSlackMessages(channelId, opts = {}) {
  const client = await getClient(opts);
  ...
  const result = await client.conversations.history({
    channel: channelId,
    ...
  });
}

async function getClient(opts = {}, mode = "read") {
  const token = resolveToken(opts.token, opts.accountId);
  return opts.client ?? (mode === "write" ? createSlackWriteClient(token) : createSlackWebClient(token));
}

function resolveToken(explicit, accountId) {
  const account = resolveSlackAccount({
    cfg: loadConfig(),
    accountId
  });
  const token = resolveSlackBotToken(explicit ?? account.botToken ?? void 0);
  ...
}

The key issue is that resolveToken() resolves the bot token only, even for read operations.

Why this seems wrong

The docs suggest user tokens can be preferred for actions/directory reads when configured, but this read path never appears to consult userToken.

Impact

• DM send/read symmetry breaks
• outbound DM workflows cannot reliably verify responses/history
• multi-account Slack setups are especially confusing because send works but immediate readback fails

Suggested fix

Split Slack client token resolution by mode:

• for read operations, prefer configured userToken when available and allowed
• for write operations, continue preferring bot token

If intentional, docs should clearly state that message read on Slack DMs is bot-token-only and may fail even when a userToken exists.