Summary

openclaw gateway status outputs an error-level message for unresolved SecretRefs even when the gateway is running and the affected channel is fully functional.

Environment

• OpenClaw: 2026.3.12
• OS: Debian Linux (x64)
• SecretRef provider: file (filemain)

Config shape

"channels": {
  "telegram": {
    "botToken": {
      "source": "file",
      "provider": "filemain",
      "id": "/channels/telegram/botToken"
    }
  }
}

Behaviour

Running openclaw gateway status while the gateway is live (RPC probe ok, Telegram receiving and sending messages) prints:

Error: channels.telegram.botToken: unresolved SecretRef "file:filemain:/channels/telegram/botToken".
Resolve this command against an active gateway runtime snapshot before reading it.

At the same time:

• Gateway probe: ok
• Telegram DMs: fully functional (messages received and sent)

Expected behaviour

The diagnostic output should either:

1. Suppress SecretRef resolution errors when the gateway RPC probe confirms the gateway is healthy (the secret is resolved at gateway runtime — the CLI just can't see it), or
2. Downgrade the message to a note/warning (e.g. ℹ️ SecretRef values not readable from CLI context (gateway runtime resolves these)) so it doesn't look like a failure when everything is working.

Related

Similar class of issue to #42618 (CLI SecretRef resolution vs gateway runtime resolution), but that issue is about functional failure (message send); this is about misleading diagnostic noise in gateway status.