openclaw - 💡(How to fix) Fix [Bug]: Slack message-send action drops resolved config, causing SecretRef-backed botToken to appear missing [1 comments, 2 participants]

Bug type

Regression / behavior bug

Summary

openclaw message send --channel slack ... fails with:

Error: Slack bot token missing for account "default" (set channels.slack.accounts.default.botToken or SLACK_BOT_TOKEN for default).

This happens even when Slack is otherwise configured correctly and openclaw status reports tokens OK.

The failure appears specific to the Slack action-runtime path used by openclaw message send. In that path, resolved config is not forwarded into Slack send, so SecretRef-backed Slack tokens fall back to a fresh raw loadConfig() read and appear missing/unresolved.

Environment

• OpenClaw: 2026.4.21
• Platform: macOS
• Install method: global npm install
• Slack config: default account with SecretRef-backed botToken, appToken, and userToken

Reproduction Steps

1. Configure Slack under channels.slack.accounts.default using SecretRef-backed tokens instead of plaintext values.
2. Verify runtime health:
   • openclaw status
   • Status reports Slack tokens OK.
3. Run:
   • openclaw message send --channel slack --target <channelId> --message "test"
4. Observe failure:
   • Error: Slack bot token missing for account "default" ...

Expected Behavior

openclaw message send --channel slack ... should use the already-resolved runtime config and send successfully when openclaw status shows valid Slack tokens.

Actual Behavior

The Slack message-send path behaves as if channels.slack.accounts.default.botToken is absent, even though the resolved runtime config contains valid tokens.

What I verified

• openclaw status reported Slack tokens ok (bot config, app config).
• Host-side dry-run and direct send worked when the resolved config object was preserved.
• The failure reproduced specifically through the Slack plugin action path used by openclaw message send.

Suspected Root Cause

The Slack action runtime calls into Slack send without forwarding the resolved cfg.

Observed behavior was consistent with:

• action runtime invokes Slack send without cfg
• Slack send then does opts.cfg ?? loadConfig()
• that path reloads raw config instead of using the already-resolved runtime snapshot
• SecretRef-backed Slack tokens therefore appear missing/unresolved
• user gets a misleading Slack bot token missing for account "default" error

In my local install, forwarding the resolved config through the action-runtime path fixed the issue immediately.

Local Workaround

A local patch that passes resolved cfg through the Slack action runtime fixed the bug and allowed the exact failing openclaw message send --channel slack ... command to succeed.

Notes

This does not appear to be a simple keychain denial problem. The same environment had valid Slack credentials, and the failure was path-specific to the Slack action runtime used by the CLI send command.