Discord message-tool send fails for env SecretRef-backed named accounts while provider starts successfully

Bug type

Regression / message delivery failure

Summary

On an OpenClaw gateway using named Discord accounts with bot tokens configured as env-backed SecretRefs, Discord providers can start successfully and inbound Discord prompts can reach agent sessions. However, agent-visible replies may not surface to Discord because the Discord message tool send path fails to resolve the same named-account token.

The affected agent appears responsive in the internal session transcript, but visible Discord send attempts fail with this class of error:

Discord bot token configured for account "<account>" is unavailable; resolve SecretRefs against the active runtime snapshot before using this account.

This can leave generated replies internal-only while users see silence in Discord.

Impact

High: message loss / invisible replies.

• Discord prompts are ingested.
• Agent runs continue and generate responses internally.
• Visible Discord delivery fails for replies using the message tool.
• From the user's perspective, agents appear silent or stuck.

Environment

• OpenClaw CLI: affected on a recent 2026.5.x install
• Gateway host: Linux
• Discord integration: external @openclaw/discord plugin
• Tokens configured via env-backed SecretRefs, e.g.:

{
  "channels": {
    "discord": {
      "accounts": {
        "<account>": {
          "token": {
            "source": "env",
            "provider": "runtime_env",
            "id": "<TOKEN_ENV_VAR>"
          }
        }
      }
    }
  }
}

No token values are involved in this report.

Observed behavior

1. Gateway starts and health checks pass.
2. Discord provider startup succeeds for a named account.
3. A Discord-originated prompt reaches the agent session.
4. The agent generates an internal response in the session transcript.
5. When the agent attempts visible delivery through the Discord message tool, delivery fails with:

Discord bot token configured for account "<account>" is unavailable; resolve SecretRefs against the active runtime snapshot before using this account.

Example transcript pattern:

User: <discord prompt>
Assistant toolCall: message { action: "send", message: "..." }
ToolResult: Discord bot token configured for account "<account>" is unavailable; resolve SecretRefs against the active runtime snapshot before using this account.
Assistant: <response exists internally, but does not surface visibly to Discord>

The provider startup path appears to have enough token material to start the Discord bot, but the message-tool send path treats the same env SecretRef as unavailable.

Expected behavior

The Discord message tool send path should resolve named-account tokens the same way the Discord provider startup path does.

If a named account token is configured as an env-backed SecretRef and the env var is present in the active gateway runtime environment, message delivery should succeed.

Actual behavior

The Discord provider starts, but the Discord message tool send path can return configured_unavailable for the named-account token and refuse to send.

Local mitigation that restored delivery

A narrow live mitigation was applied locally to the installed external Discord plugin token resolver.

The mitigation changes resolveDiscordTokenValue so that when resolveSecretInputString(..., mode: "inspect") returns configured_unavailable, env-backed SecretRefs are resolved directly from process.env[ref.id] before failing.

Patch shape:

if (resolved.status === "configured_unavailable") {
  const ref = resolved.ref;
  if (ref?.source === "env") {
    const envToken = normalizeDiscordToken(process.env[ref.id], ref.id);
    if (envToken) return {
      status: "available",
      value: envToken
    };
  }
  return { status: "configured_unavailable" };
}

After applying the mitigation and restarting the gateway:

• Gateway service was active.
• Gateway readiness checks passed.
• Overall health checks passed.
• An actual Discord send probe with the affected named account succeeded.

Why this appears to be an OpenClaw bug

The same token configuration is usable by the provider startup path but not by the message-tool send path. That suggests the send path is not consistently using the active runtime snapshot / runtime env resolution contract for external Discord plugin account tokens.

Related issues / prior art

This appears related to, but not fully covered by, existing SecretRef/runtime snapshot issues:

• #84530 — Discord channel-info fails for SecretRef-backed named account while send works
• #86545 — Cron isolated jobs fail Discord delivery with "SecretRefs not resolved against runtime snapshot" after v2026.5.22
• #51263 — Tool subsystem fails to resolve SecretRefs for Discord token (message tool)

This incident differs from #84530 because the failing operation is not metadata lookup; it is visible Discord send / agent reply surfacing, causing user-visible message loss.

Suggested fix direction

Ensure the external Discord plugin's token resolver and all message-tool send paths receive or select a runtime-resolved config/snapshot equivalent to provider startup.

At minimum, env-backed SecretRefs that are present in the gateway runtime environment should not produce configured_unavailable in the message-tool send path for named Discord accounts.

A regression test should cover:

1. Named Discord account token configured as env-backed SecretRef.
2. Gateway/runtime env contains the token.
3. Provider account resolution succeeds.
4. message send / message-tool delivery for that named account succeeds.
5. The test should specifically exercise the external @openclaw/discord send path, not only core config parsing.