@openclaw/discord plugin (2026.5.3 / host 2026.5.3-1): SecretRef inspect-mode returns configured_unavailable for per-account tokens despite fully valid setup

Versions: OpenClaw 2026.5.3-1 (host), @openclaw/[email protected] (npm-installed external plugin) Platform: macOS 26.4.1 arm64, node 24.13.0 Service mode: LaunchAgent (ai.openclaw.gateway, KeepAlive=true), launched via shim with owner-only env file (the post-#72996 official wrapper layout)

Summary

After upgrading from 2026.4.29 to 2026.5.3-1, every Discord account that uses a SecretRef-shaped token in channels.discord.accounts.<id>.token reports tokenStatus: configured_unavailable — even though the env var is present in the gateway process, the env provider is correctly defined, secrets.providers.default.allowlist contains the env var, and secrets reload returns OK with no unresolved refs. Replacing the same field with the same plaintext token value resolves immediately on next restart.

This appears to be a regression in the externalized discord plugin's inspect-mode token resolver, likely related to (but missed by) the Channels/secrets: resolve SecretRef-backed channel credentials through external plugin secret contracts after the plugin split change in 2026.5.x.

Repro (observed)

Setup before upgrade:

• 7 Discord accounts (default, gimli, pippin, samwise, smaug, boromir, faramir).
• Each account's token configured as {source: "env", provider: "default", id: "XXX_DISCORD_BOT_TOKEN"}.
• All 7 env vars supplied via owner-only env file sourced by the official wrapper (~/.openclaw/service-env/ai.openclaw.gateway-env-wrapper.sh → user shim → node).

After upgrade:

• Gateway boots cleanly. [gateway] http server listening (6 plugins: ..., discord, ...) confirms discord plugin is loaded.
• [gateway] starting channels and sidecars... runs.
• No discord provider startup activity ever appears in the log. No [discord] starting provider, no [discord] delaying provider startup …, no [discord] logged in to discord.
• openclaw channels status --probe reports each account: enabled, configured, secret unavailable in this command path, stopped, disconnected, token:config (unavailable), health:not-running, error:not configured.
• [tools] message failed: Discord bot token configured for account "<id>" is unavailable; resolve SecretRefs against the active runtime snapshot before using this account.

All preconditions are satisfied:

Conclusively isolating the bug: replacing the SecretRef on channels.discord.accounts.default.token with the same string-literal token immediately produced [discord] [default] starting provider (@Gandalf) and full connect on the next restart. Repeating for the other 6 accounts brought the entire fleet up.

Code-path pointer

@openclaw/discord/dist/token-BZtonk7d.js, resolveDiscordTokenValue:

function resolveDiscordTokenValue(params) {
  const resolved = resolveSecretInputString({
    value: params.value,
    path: params.path,
    defaults: params.cfg.secrets?.defaults,
    mode: "inspect"
  });
  if (resolved.status === "available") return { status: "available", value: stripDiscordBotPrefix(resolved.value) };
  if (resolved.status === "configured_unavailable") return { status: "configured_unavailable" };
  return { status: "missing" };
}

mode: "inspect" is what's returning configured_unavailable for the per-account SecretRefs. The default account happens to work via the legacy env fallback at the bottom of resolveDiscordToken (accountId === DEFAULT_ACCOUNT_ID ? normalizeDiscordToken(opts.envToken ?? process.env.DISCORD_BOT_TOKEN, "DISCORD_BOT_TOKEN") : void 0), so the bug is masked for the default account but breaks every named account.

What I had to do as a workaround

Convert all 7 account tokens (and channels.discord.token) from SecretRefs back to plaintext strings in openclaw.json, mode-600 the file. Functional but undoes the post-#72996 hardening for those specific fields. I'd rather restore the SecretRefs once this is fixed.

Loosely related observations (not blockers, just noticed)

• Doctor still reports Gateway service entrypoint does not match the current install for setups that retain a user-owned launcher shim chained behind the official wrapper (the chain shape ProgramArguments=[official-wrapper.sh, env-file, user-shim.sh, gateway, --port, 18789]). The wrapper does honor the chain, but the doctor's match treats it as drift and prompts to "Update gateway service config to the recommended defaults", which would replace the user shim. Suggest the doctor recognize the chain or stop offering to overwrite plists that already invoke the official wrapper.
• openclaw plugins list reports the discord plugin as enabled based on npm install state, but plugins.allow may not actually include it (it didn't in my case after the 2026.4.29 → 2026.5.3-1 jump). The CLI openclaw plugins enable discord was needed before the gateway would attempt to register the channel. A clearer "installed but not allow-listed" state in plugins list would have saved time.
• During the 2026.4.29 → 2026.5.3-1 package update the official wrapper directory was created at ~/.openclaw/service-env/, replacing the user-owned ~/.openclaw/service-env file. The previous file was preserved at ~/.openclaw/service-env.local, which is also where the user shim sources from — so this part worked smoothly in practice.