openclaw - 💡(How to fix) Fix [Bug]: Channel token SecretRef unresolved on embedded agent reply path "channels.{telegram.botToken,discord.token}" [2 comments, 2 participants]

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

On 2026.4.29 and 2026.5.2, when channels.telegram.botToken or channels.discord.token is configured as a file-source SecretRef, the embedded agent runs successfully but its reply dispatch throws unresolved SecretRef and no reply is sent to the user.

Steps to reproduce

1. Configure channels.telegram.botToken or channels.discord.token as a file-source SecretRef pointing to an existing keystore entry. Verify openclaw secrets audit reports unresolved=0.
2. Verify the channel reports running, connected, works via openclaw channels status --probe.
3. From a paired user, send any DM to the bot.
4. Observe the channel inbound and ack succeed: gateway logs [telegram] sendMessage ok for the ack message. Then the embedded agent runs the model successfully and only fails when dispatching the reply.

Expected behavior

The bot's reply, the agent's model output, is delivered through the channel back to the user. This matches the behavior expected from issues #37909 and #42848, which document the same architectural gap for the explicit message tool path. The channel inbound path already resolves the same SecretRef correctly, so the reply path should as well.

Actual behavior

No reply is delivered. The gateway error log shows the embedded agent's attempt-dispatch phase failing with an unresolved SecretRef on the channel token, sourced from raw config rather than the resolved runtime snapshot:

[diagnostic] lane task error: lane=session:agent:main:telegram:direct:<userId> durationMs=27885 error="Error: channels.telegram.botToken: unresolved SecretRef "file:local_keys:/TELEGRAM_BOT_TOKEN". Resolve this command against an active gateway runtime snapshot before reading it." Embedded agent failed before reply: channels.telegram.botToken: unresolved SecretRef "file:local_keys:/TELEGRAM_BOT_TOKEN". Resolve this command against an active gateway runtime snapshot before reading it. [agent/embedded] [trace:embedded-run] startup stages: runId=<id> sessionId=<id> phase=attempt-dispatch totalMs=10925 stages=workspace:1ms,runtime-plugins:4ms,hooks:0ms,model-resolution:2628ms,auth:4378ms,context-engine:0ms,attempt-dispatch:3914ms

The model-resolution and auth stages succeed; the failure is at attempt-dispatch when the reply send needs the channel token. Same error pattern is observed for Discord with channels.discord.token.

OpenClaw version

2026.5.2. Also confirmed reproducible on 2026.4.29. Older versions not directly tested.

Operating system

macOS 26.4.1 on arm64

Install method

npm global via fnm-managed Node 25.6.0

Model

deepseek/deepseek-v4-pro

Provider / routing chain

openclaw -> api.deepseek.com over direct REST with no intermediate gateway or router. Model resolution and inference complete successfully, the failure is in the channel reply dispatch and is independent of the provider chain.

Additional provider/model setup details

Channel SecretRef configuration in openclaw.json, with provider alias and keystore path replaced by generic placeholders:

"channels": { "telegram": { "botToken": {"source": "file", "provider": "local_keys", "id": "/TELEGRAM_BOT_TOKEN"}, ... }, "discord": { "token": {"source": "file", "provider": "local_keys", "id": "/DISCORD_BOT_TOKEN"}, ... } }

"secrets": { "providers": { "local_keys": {"source": "file", "path": "<keystore-path>", "mode": "json"} } }

The keystore file has filesystem mode 0600. openclaw secrets reload reports success and openclaw secrets audit reports unresolved=0.

gateway.auth.token is also a file SecretRef pointing into the same keystore and resolves correctly for CLI and dashboard auth. Only channel-token reads on the embedded agent reply path fail.

Logs, screenshots, and evidence

Reproduction sequence in gateway logs:

Receive succeeds
[telegram] sendMessage ok chat=<id> message=82

Model run succeeds
[agent/embedded] [trace:embedded-run] startup stages: ... model-resolution:2628ms@2633ms,auth:4378ms@7011ms,context-engine:0ms@7011ms,attempt-dispatch:3914ms@10925ms

Reply dispatch fails
Embedded agent failed before reply: channels.telegram.botToken: unresolved SecretRef "file:local_keys:/TELEGRAM_BOT_TOKEN". Resolve this command against an active gateway runtime snapshot before reading it.
[diagnostic] lane task error: lane=session:agent:main:telegram:direct:<userId> durationMs=27885 ...

The pattern repeats for every user message. Replacing the SecretRef with the resolved plaintext string in openclaw.json eliminates the error and the reply is delivered normally.

The status path was softened in 2026.4.30 with the message "secret unavailable in this command path", verified on 2026.5.2. The embedded agent reply path was not covered by that fix.

Impact and severity

Affected: any deployment where channels.telegram.botToken or channels.discord.token is a SecretRef on 2026.4.27 and later. Verified on 2026.4.29 and 2026.5.2. Severity: High. Blocks workflow because the bot appears connected but does not reply to any user message. Frequency: Always. Every reply attempt fails. Reproduced across multiple sessions. Consequence: Silent message loss from the user's perspective. The user sees no reply; only gateway logs reveal the failure.

Additional information

Related issues: #37909 message tool cannot resolve SecretRef for channels.telegram.botToken at tool-call time. Same architectural gap on a different code path: explicit message tool versus the embedded agent's implicit reply #42848 message tool fails to resolve SecretRefs for channel credentials. #49427 skills.entries.<skill>.apiKey file SecretRef passes audit but unresolved during embedded run startup. Same architectural pattern on a different field family. #28306 feature request: expand SecretRef scope to channel credentials (botToken, webhookSecret). The reported bug is on a code path that is in scope of that work but does not honor the resolved runtime snapshot. #50161 and #57272 same "resolve against active gateway runtime snapshot" error class on doctor and status paths.

Regression status: NOT_ENOUGH_INFO on the exact first-bad version. 2026.4.24 was not directly retested with channel-token SecretRef on this machine. Confirmed bad on 2026.4.29 and 2026.5.2.

Workaround: revert channels.telegram.botToken and channels.discord.token to plaintext strings in openclaw.json, with file mode 0600. Channels resume working immediately. The keystore entries can remain in place to ease re-migration once fixed.

Suggested fix direction: the embedded agent reply path appears to read raw config. Aligning it with the runtime-snapshot accessor used by the post-2026.4.30 status path should resolve the symptom. The error message itself names the correct fix: "Resolve this command against an active gateway runtime snapshot before reading it."