Summary

The built-in microsoft-foundry provider can discover/select Anthropic Claude deployments from Azure AI Foundry, but it still normalizes them onto the OpenAI-compatible runtime path (/openai/v1, chat/completions or responses) instead of the Anthropic Foundry path (/anthropic/v1/messages).

This makes Claude deployments appear selectable in onboarding/config, but real requests fail at runtime (commonly 404).

Why this looks like a bug in the built-in provider

Microsoft's Claude-on-Foundry docs expect:

• base URL: https://<resource>.services.ai.azure.com/anthropic
• request path: /anthropic/v1/messages
• API shape: Anthropic Messages API
• auth:
  • API key: x-api-key
  • Entra ID: Authorization: Bearer <token>
• Anthropic header: anthropic-version: 2023-06-01

But the built-in microsoft-foundry provider currently behaves like an OpenAI-compatible Foundry adapter:

• dist/provider-CbANfJPO.js
  • capabilities: { providerFamily: "openai" }
• dist/shared-Jirm7-bE.js
  • Foundry API resolution only supports openai-completions / openai-responses
  • endpoint normalization/building rewrites to .../openai/v1
• dist/onboard-BZJYM71H.js
  • connection test only calls /chat/completions or /responses
• dist/runtime-BEDfp2bA.js
  • Entra token refresh is wired, but the rebuilt base URL still comes from the OpenAI-style Foundry base URL builder

So the provider can successfully:

• authenticate with Azure CLI / Entra ID
• list Foundry resources
• list deployments
• let the user select Claude deployments

but then still send the wrong protocol/route for Anthropic deployments.

Repro

1. Run OpenClaw onboarding/configure.
2. Select Microsoft Foundry.
3. Choose Azure CLI login (az login already completed).
4. Select a Claude deployment from Azure AI Foundry, e.g. claude-opus-4-6.
5. Use that model in a real run.

Observed behavior

The configured model is routed through OpenAI-compatible Foundry endpoints instead of Anthropic Foundry endpoints, and requests fail (for example with 404).

Expected behavior

One of these should happen:

Option A: proper Anthropic support in microsoft-foundry

If the selected deployment is Anthropic/Claude, the provider should:

• support api: "anthropic-messages"
• build base URL as https://<resource>.services.ai.azure.com/anthropic
• call /v1/messages
• send anthropic-version: 2023-06-01
• use:
  • x-api-key for API key auth
  • Authorization: Bearer <token> for Entra ID auth

Option B: guardrail until support exists

If Anthropic deployments are not yet supported by the built-in provider, onboarding should not offer them as selectable deployments, or should clearly warn that only OpenAI-compatible Foundry APIs are currently supported.

Actual user impact

This is especially confusing because:

• the Azure CLI login flow works
• resource + deployment discovery works
• Claude deployments are shown as selectable
• the runtime failure only appears later when making actual requests

So it looks like configuration succeeded even though the provider/runtime protocol is wrong for that deployment family.

Related but distinct issue

• [Bug] Azure Foundry Anthropic: SSE stream events concatenated without \n\n delimiter — raw JSON parse error surfaced to all user channels #32179 is about custom Azure Foundry Anthropic provider streaming/SSE parsing.
• This issue is about the built-in microsoft-foundry provider selecting Anthropic deployments but routing them via the wrong API family.

Workaround

Current workaround is to use a custom provider pointed at the Anthropic Foundry endpoint instead of the built-in microsoft-foundry provider, e.g.:

• base URL: https://<resource>.services.ai.azure.com/anthropic
• API: anthropic-messages

API-key auth works most cleanly there today.