Bug: discord.actions.describeMessageTool fails with unresolved SecretRef in 2026.4.14channels.disc

[final turret]

Bug: discord.actions.describeMessageTool fails with unresolved SecretRef in 2026.4.14

channels.discord.token is a SecretRef: {source: "env", provider: "default", id: "DISCORD_BOT_TOKEN"}
openclaw secrets audit --check shows unresolved=0 — gateway resolves it successfully
openclaw channels status --probe shows token:config, works
openclaw secrets reload does not fix it
Agent turns fail with: discord.actions.describeMessageTool failed: unresolved SecretRef "env:default:DISCORD_BOT_TOKEN"
Result: incomplete turn detected: stopReason=stop payloads=0
Started after upgrading from 2026.4.12 to 2026.4.14
Workaround: unknown

[wicked marsh]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[round kindle]

Let me check the local docs and source, this smells like a regression rather than a bad secret config.

I found the likely fault line. The reply runtime is resolving agent/model secrets, but not channel secrets, and Discord’s describeMessageTool now reads the token eagerly. That exactly matches your stack.

This looks like a real 2026.4.14 regression, not a bad SecretRef config.

I checked the current source, and the failure path lines up:

• queued reply execution resolves secrets in src/auto-reply/reply/agent-runner-utils.ts
• that currently calls getAgentRuntimeCommandSecretTargetIds() with no includeChannelTargets: true
• so channel secrets like channels.discord.token are not hydrated for reply runs
• then Discord message-tool discovery calls resolveDiscordAccount() / resolveDiscordToken()
• extensions/discord/src/token.ts throws on a raw unresolved SecretRef object

That also explains why these all look healthy but replies still fail:

• openclaw secrets audit --check
• openclaw channels status --probe
• openclaw secrets reload

They use different paths. This specific reply-time path is missing channel-secret resolution.