openclaw - 💡(How to fix) Fix [Bug]: Custom-named providers reusing bundled api adapters (Azure Foundry) silently lose models on 2026.4.29 [1 comments, 2 participants]

Summary

Custom-named provider entries in models.providers that reuse bundled api adapters (e.g. openai-responses, openai-completions, anthropic-messages) silently stop returning models after upgrading from 2026.4.26 → 2026.4.29. Rolling back to 2026.4.26 restores them with no other changes.

The pattern affects deployments that put multiple Azure AI Foundry routes (Anthropic via Foundry, OpenAI Responses via Foundry, Kimi via Foundry, projects-scoped OpenAI via Foundry) behind their own provider IDs to share an Azure resource and key.

Reproduction

Provider config (abridged) that works on 2026.4.26 and fails on 2026.4.29:

{
  "models": {
    "providers": {
      "anthropic-foundry": {
        "baseUrl": "https://<tenant>-foundry-ai.services.ai.azure.com/anthropic/v1",
        "apiKey": { "source": "file", "provider": "filemain", "id": "/providers/anthropic-foundry/apiKey" },
        "auth": "api-key",
        "api": "anthropic-messages",
        "models": [ { "id": "claude-sonnet-4-6", "api": "anthropic-messages", "input": ["text","image"] } ]
      },
      "pmi-openai": {
        "baseUrl": "https://<tenant>-foundry-ai.openai.azure.com/openai/v1/",
        "apiKey": "<inline-azure-key>",
        "auth": "api-key",
        "api": "openai-responses",
        "models": [ { "id": "gpt-5.4-pro", "api": "openai-responses", "input": ["text","image"] } ]
      },
      "pmi-foundry-project": {
        "baseUrl": "https://<tenant>-foundry-ai.services.ai.azure.com/api/projects/<project>/openai/v1/",
        "apiKey": "<inline-azure-key>",
        "auth": "api-key",
        "api": "openai-responses",
        "models": [ { "id": "gpt-5.5-1", "api": "openai-responses" } ]
      },
      "kimi-foundry": {
        "baseUrl": "https://<tenant>-foundry-ai.services.ai.azure.com",
        "apiKey": "<inline-azure-key>",
        "auth": "api-key",
        "api": "openai-completions",
        "models": [ { "id": "Kimi-K2.6-1", "api": "openai-completions" } ]
      }
    }
  }
}

On 2026.4.26:

$ openclaw models list --provider anthropic-foundry | head
anthropic-foundry/claude-sonnet-4-6   text+image  195k  no  yes  default,configured,alias:az-sonnet-4-6
anthropic-foundry/claude-opus-4-7     text+image  977k  no  yes  configured,alias:az-opus-4-7
...

After upgrading to 2026.4.29 (no other config changes):

$ openclaw models list --provider anthropic-foundry
$ openclaw models list --provider pmi-openai
$ openclaw models list --provider pmi-foundry-project
$ openclaw models list --provider kimi-foundry

All four return zero rows. Sessions defaulting to those models start failing with empty responses / model-resolution errors. Downgrading back to 2026.4.26 restores all four immediately.

Expected

Custom-named provider entries with a known bundled api value (openai-responses, openai-completions, anthropic-messages) should keep activating the corresponding bundled adapter regardless of provider ID.

Suspected cause (from changelog scan)

Two 2026.4.29 entries land on this pattern:

• #74307 — "Plugins/runtime-deps: include bundled provider plugins when models.providers, auth profiles, agent defaults, or subagent model refs configure that provider, while keeping inactive default-enabled provider plugins out of doctor repair." Reads as if the inclusion check matches by provider ID. Custom IDs like pmi-openai, kimi-foundry, pmi-foundry-project don't match any bundled plugin ID, so the bundled openai-responses / openai-completions / anthropic-messages adapters never get pulled in.

• #74423 — "Models/UI: hide unauthenticated providers from the default Web chat, /models, and model setup pickers..." Inline apiKey: "<string>" may not be detected as authenticated under the new rule, even though the provider works at the HTTP layer.

The 4.27 manifest-first catalog migration probably set the conditions that 4.29 made breaking.

Open questions

1. For custom-named providers reusing bundled api adapters, should the bundled plugin activation check fall back to matching by api field when the provider ID is not a bundled ID?
2. Is inline apiKey: "<string>" still a supported "authenticated" shape for the 4.29 picker hide rule (#74423), or does it now require SecretRef + auth-profile?
3. What's the recommended config pattern for Azure AI Foundry deployments that need multiple provider IDs (Anthropic + OpenAI Responses + OpenAI completions + Kimi) behind one Azure resource? A documented example would prevent this whole class of breakage.

Workaround

Pin to 2026.4.26:

npm install -g [email protected]

Environment

• OpenClaw: was on 2026.4.29, currently 2026.4.26 (be8c246)
• Node: v22.17.1
• macOS Darwin 24.6.0 (x64)
• Install: global npm

Related

• #74307 (bundled provider plugin inclusion)
• #74423 (hide unauthenticated providers)
• #60546 (microsoft-foundry routing — different but adjacent)