Summary

When configuring auth-profiles.json with "api_key" as the field name for API key credentials, the key resolution silently fails. The correct field name is "key", but this is not documented and there is no validation error — the profile is simply skipped.

This causes downstream features (e.g., LCM plugin compaction, embedded agent runs) to fail with a misleading error:

modelAuth.resolveApiKeyForProvider FAILED: No API key found for provider "<provider>"

Environment

• OpenClaw: 2026.3.24 (also affects 2026.3.28)
• OS: Linux (Ubuntu)
• Plugin: @martian-engineering/lossless-claw v0.4.0 (triggers the issue via modelAuth.resolveApiKeyForProvider)

Steps to Reproduce

1. Configure a custom provider in openclaw.json:

{
  "models": {
    "providers": {
      "my-provider": {
        "baseUrl": "http://localhost:8080",
        "apiKey": "sk-xxxx"
      }
    }
  }
}

1. Set up auth-profiles.json for any agent:

{
  "profiles": {
    "my-key": {
      "type": "api_key",
      "provider": "my-provider",
      "api_key": "sk-xxxx"
    }
  },
  "order": {
    "my-provider": ["my-key"]
  }
}

1. Any feature that calls resolveApiKeyForProvider("my-provider") fails silently.

Root Cause

In the bundled runtime, resolveApiKeyForProfile reads:

• cred.key for inline API keys
• cred.keyRef for SecretRef-based keys

But the field "api_key" in the JSON is not mapped to either property. resolveProfileSecretString receives undefined for both value and valueRef, returns null, and the profile is skipped without any warning.

The call chain:

resolveApiKeyForProvider
  → resolveAuthProfileOrder (filters eligible profiles)
    → resolveApiKeyForProfile
      → resolveProfileSecretString(cred.key, cred.keyRef)
        → both undefined → returns null → profile skipped

Expected Behavior

Either:

1. Document that the correct field name is key (not api_key) in auth-profiles.json
2. Accept both api_key and key as valid field names with a normalization step
3. Validate auth-profiles.json on load and warn when unrecognized fields are present

Option 3 would have saved significant debugging time — the silent failure made this very hard to diagnose.

Workaround

Change "api_key" to "key" in all auth-profiles.json files:

{
  "profiles": {
    "my-key": {
      "type": "api_key",
      "provider": "my-provider",
      "key": "sk-xxxx"
    }
  },
  "order": {
    "my-provider": ["my-key"]
  }
}

Impact

• Any user setting up auth profiles with "api_key" (the intuitive name matching the profile type: "api_key") will hit this silently
• LCM plugin compaction fails without visible errors in chat — summaries simply stop being generated
• Embedded agent runs may fail or fall back unexpectedly
• Main conversation flow is unaffected if models.providers.*.apiKey is also configured, which masks the auth-profiles bug further and delays discovery