openclaw - 💡(How to fix) Fix [Bug]: doctor warns 'Gateway token SecretRef unavailable' even when Gateway runs normally

Bug: openclaw doctor reports "Gateway token is managed via SecretRef and is currently unavailable" even when Gateway runs normally

Bug Description

When gateway.auth.token is configured as a SecretRef with a file (or exec) provider, openclaw doctor emits this warning:

Gateway token is managed via SecretRef and is currently unavailable.
Doctor will not overwrite gateway.auth.token with a plaintext value.
Resolve/rotate the external secret source, then rerun doctor.

However, the Gateway runs and connects normally — gateway status shows running, connected. The SecretRef is correctly resolved at Gateway runtime, but the CLI doctor cannot resolve it.

This suggests the CLI (specifically the doctor check) uses a different config resolution context than the Gateway runtime, which cannot access file/exec-backed SecretRefs.

Impact

• Doctor gives a false warning: The Gateway is actually working fine; only the CLI's audit check fails.
• Users may be tempted to revert to plaintext to silence the warning, which reduces security.
• This is analogous to the channels.qqbot.clientSecret issue (CLI message send also cannot resolve SecretRefs), but for the gateway token the workaround is worse because the token is higher-privilege.

Environment

• OpenClaw 2026.5.27 (27ae826)
• macOS (Darwin arm64)
• Gateway token SecretRef with provider: "file", secretId: "openclaw.gateway-auth.token"
• Other secrets (minimax api key, wecom configs) also use file-backed SecretRefs without issues at runtime

Expected Behavior

openclaw doctor should distinguish between:

1. Gateway runtime unavailable (real problem) — Gateway cannot resolve the SecretRef and is not connected
2. CLI cannot resolve SecretRef in audit mode (cosmetic issue) — Gateway is running fine but CLI doctor cannot read the secret

Option A: Detect that the Gateway is running+connected and skip the warning in that case. Option B: Resolve the SecretRef in the CLI doctor context using the same mechanism the Gateway uses at runtime. Option C: Document this behavior clearly so users know it can be safely ignored when Gateway is confirmed running.

Additional Context

This is very similar to the channels.qqbot.clientSecret issue where CLI plugins (message send) also cannot resolve file/exec-backed SecretRefs. The fundamental problem is the CLI uses a different config resolution path that does not have access to the same environment/context that the Gateway has at runtime.