Summary

channels.discord.token is configured as a SecretRef pointing to a valid filemain provider key. openclaw secrets audit reports 0 unresolved. But at runtime, Discord channel operations fail with channels.discord.token: unresolved SecretRef "file:filemain:/DISCORD_BOT_TOKEN".

This is a regression/fragility in how the Discord extension resolves the token at runtime vs how the CLI audit resolves it.

Environment

• OpenClaw: 2026.4.29 (a448042)
• OS: Linux 6.8.0 (Ubuntu/Debian)
• Install: npm global
• secrets.json mode: json (filemain provider)

Config

"channels": {
  "discord": {
    "enabled": true,
    "token": {
      "source": "file",
      "provider": "filemain",
      "id": "/DISCORD_BOT_TOKEN"
    }
  }
}

"secrets": {
  "providers": {
    "filemain": { "source": "file", "path": "/path/to/secrets.json", "mode": "json" }
  }
}

secrets.json top-level key DISCORD_BOT_TOKEN exists and is valid.

Steps to reproduce

1. Configure channels.discord.token as a filemain SecretRef ("id": "/DISCORD_BOT_TOKEN")
2. Confirm openclaw secrets audit reports 0 unresolved
3. Restart the gateway
4. Attempt any Discord message action (e.g. openclaw message send, or inbound Discord message)
5. Observe: channels.discord.token: unresolved SecretRef "file:filemain:/DISCORD_BOT_TOKEN"

Expected vs Actual

• Expected: Discord token resolves at gateway startup (as secrets audit confirms), runtime usage works
• Actual: Gateway starts clean, Discord operations fail at runtime with unresolved SecretRef

Stack trace

Error: channels.discord.token: unresolved SecretRef "file:filemain:/DISCORD_BOT_TOKEN". Resolve this command against an active gateway runtime snapshot before reading it.
    at createUnresolvedSecretInputError (types.secrets-BHp0Y_k0.js:68:25)
    at resolveSecretInputString (types.secrets-BHp0Y_k0.js:99:52)
    at normalizeResolvedSecretInputString (types.secrets-BHp0Y_k0.js:110:19)
    at normalizeDiscordToken (token-D-w3Rigl.js:5:18)
    at resolveDiscordToken (token-D-w3Rigl.js:26:22)
    at resolveDiscordAccount (accounts-BKnkNaoA.js:54:26)
    at resolveScopedDiscordActionDiscovery (channel-actions-8bJreMW_.js:22:18)
    at Object.describeDiscordMessageTool [as describeMessageTool] (channel-actions-8bJreMW_.js:34:20)
    at Object.describeMessageTool (channel-CMeIg_K8.js:306:146)
    at describeMessageToolSafely (message-action-discovery-CW9J9hh5.js:60:17)

Root cause hypothesis

The describeMessageTool code path calls loadConfig() which re-reads the raw config from disk. The raw config has the unresolved SecretRef object. The already-resolved in-memory token is discarded. This is the same root cause as issue #33573 but in a different code path (describeMessageTool instead of sendMessage).

Impact

• Gateway starts successfully and secrets audit is clean
• But Discord channel is non-functional at runtime
• Workaround: keep Discord token as plaintext (not a SecretRef)

Related issues

• [Bug]: openclaw message send fails with unresolved SecretRef for Discord channel token #33573 — same root cause for sendMessage path (closed, fix was for send path only)
• doctor false positive warning on Gateway auth token handled in secrets #65201 — similar doctor false positive for file-backed secrets
• openclaw status fails on Telegram file SecretRef while resolving allowlist metadata #74832 — similar Telegram pattern (SecretRef resolves in audit but not in status/channel ops)

openclaw --version

OpenClaw 2026.4.29 (a448042)