Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

After upgrading to OpenClaw 2026.4.29, inbound Telegram messages reach the gateway and Telegram can still send bot replies, but embedded agent reply runs fail before model output when channel credentials are configured through non-env SecretRefs.

The failing path appears to be embedded-run prompt/tool-discovery code reading the source/raw channel config instead of a resolved active runtime snapshot, then calling Telegram/Discord channel discovery helpers that synchronously resolve channel credentials.

Steps to reproduce

1. Configure Telegram or Discord with a channel credential stored as a non-env SecretRef, such as an exec-backed SecretRef.
2. Start OpenClaw 2026.4.29 and verify the channel itself is running.
3. Confirm channel transport works with openclaw channels status --probe or an equivalent direct send path.
4. Send an inbound message over Telegram to trigger an embedded agent reply run.
5. Observe that the embedded reply run fails before producing a model reply, while the channel still sends the generic failure message.

Expected behavior

Embedded channel reply runs should use the resolved active runtime snapshot for channel prompt/tool-discovery paths, or treat unresolved channel credentials as unavailable for discovery without failing the agent run.

A working channel with boot-resolved credentials should not crash before model execution.

Actual behavior

The inbound Telegram message is received and the Telegram bot can send the generic error reply, but the embedded agent run fails before the real assistant response.

The failure repeats after openclaw secrets reload --json succeeds with no warnings.

Discord appears affected in the same discovery layer: Discord direct send succeeds, but Discord message-action discovery throws on the unresolved Discord token SecretRef when using raw config.

OpenClaw version

OpenClaw 2026.4.29 (a448042)

Operating system

Ubuntu 26.04 LTS

Install method

pnpm-managed OpenClaw install

Model

Observed with an OpenAI Codex-backed embedded agent model. The failure occurs before model output and does not appear model-specific.

Provider / routing chain

Telegram inbound channel -> embedded agent reply runner -> model provider. Discord message-action discovery shows the same SecretRef failure pattern for Discord credentials.

Additional provider/model setup details

Channel credentials are configured as structured non-env SecretRefs.

The channel runtimes can resolve them for normal transport, but embedded-run discovery receives or reads unresolved source config.

Logs, screenshots, and evidence

Sanitized representative logs:

[diagnostic] lane task error: lane=main durationMs=13156 error="Error: channels.telegram.botToken: unresolved SecretRef \"exec:[redacted]:[redacted]\". Resolve this command against an active gateway runtime snapshot before reading it."
[diagnostic] lane task error: lane=session:agent:main:main durationMs=13158 error="Error: channels.telegram.botToken: unresolved SecretRef \"exec:[redacted]:[redacted]\". Resolve this command against an active gateway runtime snapshot before reading it."
[model-fallback/decision] model fallback decision: decision=candidate_failed requested=[redacted] candidate=[redacted] reason=unknown next=[redacted] detail=channels.telegram.botToken: unresolved SecretRef "exec:[redacted]:[redacted]". Resolve this command against an active gateway runtime snapshot before reading it.
Embedded agent failed before reply: channels.telegram.botToken: unresolved SecretRef "exec:[redacted]:[redacted]". Resolve this command against an active gateway runtime snapshot before reading it.
[telegram] sendMessage ok chat=[redacted] message=[redacted]

Discord discovery evidence from the same runtime:

[message-action-discovery] discord.actions.describeMessageTool failed: Error: channels.discord.token: unresolved SecretRef "exec:[redacted]:[redacted]". Resolve this command against an active gateway runtime snapshot before reading it.
    at normalizeDiscordToken (.../extensions/discord/token-*.js:5:18)
    at resolveDiscordToken (.../extensions/discord/token-*.js:26:22)
    at resolveDiscordAccount (.../extensions/discord/accounts-*.js:54:26)
    at listEnabledDiscordAccounts (.../extensions/discord/accounts-*.js:122:36)
    at resolveDiscordActionDiscovery (.../extensions/discord/channel-actions-*.js:12:44)

Local source-chain evidence from the packaged 2026.4.29 runtime:

embedded prompt prep calls collectRuntimeChannelCapabilities({ cfg: params.config, channel })
  -> resolveChannelPromptCapabilities(...)
  -> Telegram agentPrompt.messageToolCapabilities(...)
  -> resolveTelegramInlineButtonsScope(...)
  -> resolveTelegramAccount(...)
  -> resolveTelegramToken(...)
  -> unresolved SecretRef throws

embedded prompt prep also calls resolveChannelReactionGuidance(...) and listChannelSupportedActions(...), which can reach the same token-resolution path.

Discord describeMessageTool(...)
  -> resolveDiscordActionDiscovery(...)
  -> listEnabledDiscordAccounts(...)
  -> resolveDiscordToken(...)
  -> normalizeResolvedSecretInputString(...)
  -> unresolved SecretRef throws

Additional verification:

openclaw secrets reload --json
=> { "ok": true, "warningCount": 0 }

openclaw secrets audit --check --json
=> summary.unresolvedRefCount = 0

openclaw channels status --probe
=> Telegram connected/works; Discord connected/works

Impact and severity

High for operators using Telegram or Discord with SecretRef-backed channel credentials.

Inbound channel messages can become unusable even though the underlying channel transport is healthy. Users see only a generic “Something went wrong while processing your request” reply.

Additional information

This looks related to active-runtime-snapshot vs source-config leakage in embedded reply runs.

Discovery/prompt helper paths should not synchronously require raw channel credentials, and should not fail the whole embedded run when a SecretRef is unresolved in source config but available in the gateway runtime snapshot.