openclaw - 💡(How to fix) Fix [Bug]: doctor --lint falsely reports SecretRef-managed gateway.auth.token as unavailable

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

openclaw doctor --lint --json can emit core/doctor/gateway-auth claiming a SecretRef-managed gateway.auth.token is unavailable even when the token resolves correctly for the running gateway and security audit.

Steps to reproduce

1. Configure gateway.auth.mode as token and supply gateway.auth.token through a SecretRef, not inline plaintext.
2. Verify the gateway is running and authenticated normally.
3. Run openclaw doctor --lint --json.
4. Run openclaw security audit --deep --json and compare the gateway-auth result.

Expected behavior

Doctor should resolve the configured gateway token the same way the service-oriented auth checks do, or at minimum avoid warning when the token resolves successfully through the configured SecretRef.

Actual behavior

Doctor emits core/doctor/gateway-auth with the message Gateway token is managed via SecretRef and is currently unavailable. In the same environment, the live gateway is healthy and openclaw security audit --deep --json succeeds against the gateway without any gateway-auth finding.

OpenClaw version

2026.5.27 (27ae826)

Operating system

Ubuntu 26.04 LTS

Install method

pnpm

Model

Not model-specific; reproduced entirely through local CLI doctor/audit commands

Provider / routing chain

Not model-specific; local CLI checks against a token-authenticated local gateway

Additional provider/model setup details

Gateway auth was configured in token mode with the token supplied through a SecretRef/external secret source, not inline plaintext in the config file.

Logs, screenshots, and evidence

- `openclaw doctor --lint --json` returned a single warning: `core/doctor/gateway-auth` saying the SecretRef-managed token was unavailable.
- `openclaw security audit --deep --json` reached the live gateway successfully and reported only `gateway.trusted_proxies_missing` and `security.trust_model.multi_user_heuristic`.
- `openclaw config validate` passed and `scripts/config_baseline/config_baseline.sh auth-shadow` reported no shadowing.

Impact and severity

Medium. It creates a false auth alarm in a core maintenance command, can send operators chasing nonexistent secret or gateway breakage, and undermines trust in doctor output for SecretRef-backed gateway auth setups.

Additional information

Root cause appears to be in the core doctor check, not the actual gateway auth state. In the installed 2026.5.27 runtime, core/doctor/gateway-auth uses resolveGatewayAuth() directly on raw config. That path treats SecretRef-backed gateway.auth.token as absent unless a literal token string is already present, then emits the warning whenever a SecretRef exists and auth.token is unresolved in that raw path. A separate service-oriented token resolver does perform SecretRef resolution before judging availability, so the two doctor/auth surfaces disagree.