openclaw - 💡(How to fix) Fix [Bug]: macOS LaunchAgent gateway cannot reliably use env-backed model-provider SecretRefs even when local CLI can [1 participants]

Summary

On macOS LaunchAgent installs, gateway-managed inference cannot reliably use an env-backed model-provider API key even when the exact same provider config works for local CLI inference.

Concrete example:

{
  "models": {
    "providers": {
      "openrouter": {
        "baseUrl": "https://openrouter.ai/api/v1",
        "apiKey": {
          "source": "env",
          "provider": "default",
          "id": "OPENROUTER_API_KEY"
        }
      }
    }
  }
}

With OPENROUTER_API_KEY present in the interactive shell:

• openclaw infer model run --local --model openrouter/openai/gpt-5.4-mini ... succeeds
• gateway-backed paths do not consistently resolve the same secret unless the LaunchAgent itself is separately given direct access to the key

This creates an inconsistent split where local CLI behavior works, but gateway / TUI / agent paths do not.

Why this matters

For model-provider config, local-only success is not enough. If gateway-managed paths cannot resolve the same provider secret, users end up with a confusing state where:

• provider config looks valid
• --local works
• gateway-backed inference fails or the service remains unhealthy

That makes it hard to know what the supported secret path is for model providers on macOS.

Steps to reproduce

1. On macOS, install OpenClaw with the gateway managed as a LaunchAgent.
2. Configure a model provider API key as an env-backed SecretRef in ~/.openclaw/openclaw.json, for example:

{
  "models": {
    "providers": {
      "openrouter": {
        "baseUrl": "https://openrouter.ai/api/v1",
        "apiKey": {
          "source": "env",
          "provider": "default",
          "id": "OPENROUTER_API_KEY"
        }
      }
    }
  }
}

1. Export OPENROUTER_API_KEY in the interactive shell.
2. Run a local inference:

openclaw infer model run --local --model openrouter/openai/gpt-5.4-mini --prompt 'Reply with exactly: ok'

1. Run the same request through the gateway:

openclaw infer model run --gateway --model openrouter/openai/gpt-5.4-mini --prompt 'Reply with exactly: ok'

Expected behavior

Either:

1. the LaunchAgent-backed gateway resolves env-backed model-provider secrets the same way as the local CLI, or
2. OpenClaw documents and supports a durable service-level secret path for model-provider API keys on macOS so the gateway and local CLI behave consistently.

Actual behavior

The local CLI can authenticate and run the model, but the gateway path cannot reliably use the same secret unless the service environment is wired separately.

In the same setup, trying a file-backed SecretRef for the provider key produced:

Secret provider "default" is not configured

So from a user perspective the service-safe secret path for model-provider API keys is unclear.

Environment

• OpenClaw: 2026.4.16 (be7a415)
• macOS: 26.3.1 (arm64)
• Node: v22.22.1
• Provider tested: OpenRouter
• Model tested: openrouter/openai/gpt-5.4-mini

Related issues

This seems adjacent to, but not the same as:

• #53742 (LaunchAgent plist secret handling)
• #57144 (LaunchAgent env vars lost on update)
• #53387 (LaunchAgent env precedence / stale values)

Those focus on service env persistence / serialization. This report is specifically about the local-vs-gateway mismatch for model-provider SecretRef resolution.

Suggested direction

A fix could be any of:

• make gateway-managed model providers resolve env-backed SecretRefs the same way as local CLI inference
• provide a first-class service secret source for provider API keys on macOS LaunchAgent installs
• tighten validation / doctor output so users get a direct explanation when a provider secret is available to local CLI but not to the gateway service

I can provide sanitized follow-up details if needed.