Draft GitHub Issue - openclaw status false-negative with gateway.auth.token SecretRef

Title

[Bug]: openclaw status / openclaw status --json fail to resolve gateway.auth.token env SecretRef even when runtime is healthy and env is present

Body

Bug type

Behavior bug (incorrect output/state without crash)

Summary

On OpenClaw 2026.3.13, openclaw status and openclaw status --json report a false-negative gateway auth failure when gateway.auth.token is configured as an env-backed SecretRef.

The gateway itself is healthy and the same SecretRef-backed configuration works at runtime. The failure appears specific to the status command's gateway probe/auth resolution path.

Config pattern

gateway.auth.token is configured as:

"gateway": {
  "auth": {
    "mode": "token",
    "token": {
      "source": "env",
      "provider": "default",
      "id": "OPENCLAW_GATEWAY_TOKEN"
    }
  }
}

The token value is present in:

• process environment
• ~/.openclaw/.env

Steps to reproduce

1. Configure local gateway token auth using an env SecretRef for gateway.auth.token
2. Ensure OPENCLAW_GATEWAY_TOKEN is present in the shell environment and/or ~/.openclaw/.env
3. Restart the gateway
4. Run:

openclaw gateway status
openclaw status
openclaw status --json

Expected behavior

openclaw status and openclaw status --json should resolve the env SecretRef and successfully probe the local gateway, or at minimum should not claim the SecretRef is unresolved when it is available and runtime is healthy.

Actual behavior

openclaw gateway status reports the gateway as healthy, including successful RPC probe.

But openclaw status reports the gateway as unreachable with an error like:

connect failed: device identity required; gateway.auth.token SecretRef is unresolved in this command path; probing without configured auth credentials.

And openclaw status --json includes equivalent false-negative gateway error output.

What was verified

• Gateway runtime is healthy
• openclaw gateway status reports RPC probe: ok
• Telegram channel remains healthy
• Brave search still works
• openclaw secrets audit --json reports:
  • plaintextCount: 0
  • unresolvedRefCount: 0
• The variable is present in the CLI process environment
• Even explicitly injecting the variable inline for the command invocation still reproduces the issue:

OPENCLAW_GATEWAY_TOKEN=... openclaw status --json

Likely cause

This appears to be a status command-path bug in gateway probe auth / SecretRef resolution rather than a runtime configuration problem.

Local inspection suggests the issue is in the status gateway probe path, around:

• resolveGatewayProbeSnapshot(...)
• resolveGatewayProbeAuthResolution(...)
• resolveGatewayProbeAuthSafe(...)

The exact warning string appears to come from the probe-auth path that says the SecretRef is unresolved in the current command path, even when the env is present.

Related issues

This looks related to other CLI-vs-runtime SecretRef gaps:

• Telegram botToken SecretRef unresolved in openclaw status (v2026.3.2) #33070 — Telegram botToken SecretRef unresolved in openclaw status
• [Bug]: v2026.3.2: openclaw status fails to resolve Telegram env SecretRef even when env is present #38973 — openclaw status fails to resolve Telegram env SecretRef even when env is present
• CLI: openclaw message send fails to resolve SecretRef botToken #39415 — openclaw message send fails to resolve SecretRef botToken
• gateway probe drops loopback device identity and can falsely report missing operator.read #46014 — local loopback gateway probe false negatives
• Stable v2026.3.13-1 still reports false missing scope: operator.read for local loopback probes #49730 — stable 2026.3.13-1 still reports false local loopback probe auth/scope failures

Environment

• OpenClaw: 2026.3.13
• OS: macOS arm64
• Gateway mode: local / loopback
• Auth mode: token
• Secret provider: env (default)

Impact

This undermines operational trust in openclaw status after SecretRef hardening, because the runtime is healthy while the status surface reports a misleading auth failure.