#Unable to start gateway due to auth config

1 messages · Page 1 of 1 (latest)

north rover
#

[ERROR] [gateway/secrets] SECRETS_RELOADER_DEGRADED: SecretRefResolutionError: Environment variable "AZURE_OPENAI_API_KEY" is missing or empty. (2026-03-31T06:57:09Z)
[ERROR] Gateway failed to start: Startup failed: required secrets are unavailable. SecretRefResolutionError: Environment variable "AZURE_OPENAI_API_KEY" is missing or empty. (2026-03-31T06:57:09Z)

[ERROR] [gateway/secrets] SECRETS_RELOADER_DEGRADED: SecretRefResolutionError: Environment variable "AZURE_OPENAI_API_KEY" is missing or empty. (2026-03-31T06:57:18Z)
[ERROR] Gateway failed to start: ... (repeating every ~9s)

ocean ridgeBOT
#

Yep — this error is the secrets system failing by design because an active secret ref points to an empty env var.

AZURE_OPENAI_API_KEY is required somewhere in your active config, so gateway startup is blocked until it resolves.

Quick fix path:

  1. First, check version:
openclaw --version
  1. Check what the gateway sees:
openclaw status --all
openclaw models status
#
  1. If you do use Azure/OpenAI Foundry, set the env var where the daemon can read it (not just your current shell):
echo 'AZURE_OPENAI_API_KEY=your_key_here' >> ~/.openclaw/.env
openclaw gateway restart
  1. If you don’t use Azure, remove/disable the Azure secret ref/provider in config (or switch model/provider), then restart.

Why this happens: SecretRef resolution is fail-fast on active surfaces, so missing env = startup refusal.
Docs:

If you paste openclaw models status + openclaw status --all, I can point to the exact config field to change.

OpenClaw
Secrets Management - OpenClaw
OpenClaw
Environment Variables - OpenClaw
OpenClaw
FAQ - OpenClaw
north rover
#

what is the recommended secrets management method then? isn't putting in in .env files defeats the purpose?

ocean ridgeBOT
#

Great question — and you’re 100% right to push on that.

Short answer: .env is convenience, not the strongest security posture.
It doesn’t “defeat the purpose” completely, but it’s still plaintext at rest.

Recommended approach (in order)

  1. Best (production): exec SecretRef provider
    Keep secrets in a real secret manager (1Password/Vault/sops), and let OpenClaw resolve them at runtime via secrets.providers.<name>.source = "exec".

  2. Good: file SecretRef provider
    Store secrets in a separate locked-down secrets file (still at-rest secret, but not mixed into main config/auth files).

  3. Basic: env SecretRef provider
    Secret comes from process env (or ~/.openclaw/.env fallback). Better than hardcoding in openclaw.json, but still plaintext if you use .env.

So yes: if your goal is “no plaintext secrets on disk”, use exec provider + external secret manager.