Summary

When a Feishu channel has both a top-level appSecret using SecretRef format and sub-accounts (e.g. accounts.resource-shrimp) with their own inline appSecret, the secrets resolver skips resolving the top-level SecretRef. This causes the [default] channel to fail on startup with:

channels.feishu.appSecret: unresolved SecretRef "env:default:FEISHU_APP_SECRET".
Resolve this command against an active gateway runtime snapshot before reading it.

The resolver logs:

[SECRETS_REF_IGNORED_INACTIVE_SURFACE] channels.feishu.appSecret:
no enabled account inherits this top-level Feishu appSecret.

Reproduction

Config (openclaw.json):

{
  "channels": {
    "feishu": {
      "enabled": true,
      "appId": "cli_xxx",
      "appSecret": {
        "source": "env",
        "provider": "default",
        "id": "FEISHU_APP_SECRET"
      },
      "accounts": {
        "resource-shrimp": {
          "enabled": true,
          "appId": "cli_yyy",
          "appSecret": "inline-secret-here"
        }
      }
    }
  }
}

Environment: FEISHU_APP_SECRET is set and confirmed present in the process via /proc/<pid>/environ.

Result: [default] channel crashes on every startup attempt, retries 10 times with exponential backoff, then gives up. resource-shrimp starts normally.

Expected behavior

The resolver should recognize that the [default] channel itself uses the top-level appSecret, not just check whether explicit sub-accounts inherit it. The SecretRef should be resolved as long as the channel is enabled.

Workaround

Replace the SecretRef object with an inline secret string (same value as the env var).

Version

OpenClaw 2026.6.9 (c645ec4)