Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

The built-in Entra ID (managed identity) onboarding for the microsoft-foundry provider can't complete: it writes a thinkingLevelMap key on each model entry that the provider schema rejects, so the atomic config write rolls back and nothing persists.

Steps to reproduce

1. Set up a Foundry resource with a system-assigned managed identity and the Cognitive Services OpenAI User role.
2. Run openclaw models auth login --provider microsoft-foundry --method entra-id.
3. Pass the connection test and let it write the config.
4. The write fails validation with the error below and the config is left unchanged.

Expected behavior

Onboarding writes a valid provider config and persists it, leaving a working microsoft-foundry provider that authenticates via Entra.

Actual behavior

The connection test passes, then the config write fails validation and rolls back:

models.providers.microsoft-foundry.models.0: Unrecognized key: "thinkingLevelMap"

There's no way to finish onboarding this way.

OpenClaw version

2026.6.1 (2e08f0f)

Operating system

Ubuntu 26.04

Install method

npm global

Model

gpt-5.4 / gpt-5.4-mini (Azure AI Foundry reasoning models). I only tested reasoning models, so I don't know whether thinkingLevelMap is also emitted for non-reasoning models; if it's added for every model the bug would reproduce more broadly.

Provider / routing chain

openclaw -> microsoft-foundry (Azure AI Foundry, Entra ID / managed identity auth)

Additional provider/model setup details

System-assigned managed identity (Entra), token audience https://cognitiveservices.azure.com. There's no API key here: with Entra, OpenClaw fetches an Azure access token (via az account get-access-token) instead of using a key.

Logs, screenshots, and evidence

models.providers.microsoft-foundry.models.0: Unrecognized key: "thinkingLevelMap"


The write is atomic, so on that validation error the whole thing rolls back and the on-disk config is
untouched.

Impact and severity

• Affected: anyone onboarding microsoft-foundry with Entra ID via the built-in flow.
• Severity: High. The supported onboarding path can't complete.
• Frequency: always.
• Consequence: failed onboarding; a working provider only by hand-authoring config (below).

Additional information

Why it happens. The provider-config writer (buildFoundryProviderConfig /
provider.onModelSelected) puts a thinkingLevelMap field on each entry under models.providers.*.models[], but the schema for that path doesn't allow thinkingLevelMap. So the writer and the schema are out of sync, and validation rejects the write.

It's specifically a write-path problem. normalizeResolvedModel re-adds thinkingLevelMap in memory at request time, so it doesn't occur at runtime and never reaches the validator on read. The only place it appeared in my testing is the disk write that onboarding performs.

Source pointers. Paths below are repo source at tag v2026.6.1 (the running build ships these bundled under dist/).

• Writer: buildFoundryProviderConfig in extensions/microsoft-foundry/shared.ts (~line 340; it spreads thinkingLevelMap onto each model entry at ~line 380), and the onModelSelected hook in extensions/microsoft-foundry/provider.ts (~line 27; emits thinkingLevelMap at ~line 99).
• Harmless runtime re-add: normalizeResolvedModel (plugin-SDK helper in src/plugins/provider-runtime.ts), invoked from extensions/microsoft-foundry/provider.ts (~line 165), which restores thinkingLevelMap in memory at request time.

Fix I'd suggest. Either allow thinkingLevelMap on models.providers.*.models[] in the schema, or strip it in the writer before persisting as it's rebuilt at runtime by normalizeResolvedModel.

Workaround I used. I hand-authored a microsoft-foundry provider block (cloned from a working custom provider whose model objects carry no thinkingLevelMap) and pointed the agent bindings at it with a raw config set, which doesn't go through onModelSelected and so never re-emits the field. That holds, but it means the supported onboarding path can't be used as-is.