Summary

The strict Zod schema that validates persisted provider model entries (models.providers.*.models[]) did not allow a thinkingLevelMap field, even though it is a first-class part of the model definition (present on the runtime type and the read-path TypeBox schema). As a result, any config write that includes a model thinkingLevelMap failed .strict() validation and the atomic write rolled back.

This bites the built-in Microsoft Foundry Entra ID onboarding: its auth writer emits thinkingLevelMap on each model entry, so onboarding passes the connection test and then can't persist — leaving the provider unconfigured with no supported way to finish (#91011).

Root cause

• thinkingLevelMap is part of the model definition: runtime type ThinkingLevelMap (packages/llm-core/src/types.ts) and the read-path schema ThinkingLevelMapSchema (src/agents/sessions/model-registry.ts).
• But the write-path Zod schema ModelDefinitionSchema (src/config/zod-schema.core.ts), which validates models.providers.*.models[] on save, is .strict() and was missing the key → unrecognized key → the atomic config write rolls back. (normalizeResolvedModel re-adds the field in memory at request time, so it never surfaces on the read path — only on write.)

Changes

• src/config/zod-schema.core.ts — add ModelThinkingLevelMapSchema (mirrors the canonical 7 ModelThinkingLevel keys exactly: off/minimal/low/medium/high/xhigh/max, values string | null, strict) and wire it into ModelDefinitionSchema. Add bidirectional AssertAssignable guards tying z.infer<…> to the canonical ThinkingLevelMap type so the two can't drift.
• src/config/zod-schema.models.test.ts — schema accepts a provider model with thinkingLevelMap.
• extensions/microsoft-foundry/index.test.ts — Foundry auth writer emits the thinkingLevelMap shape on its model entry.
• docs/.generated/config-baseline.sha256 — regenerated config doc baseline to reflect the new schema field (pnpm config:docs:gen).

One logical change; no new dependency.

Verification (local, Node 22)

node scripts/run-vitest.mjs src/config/zod-schema.models.test.ts        # 2/2 pass
node scripts/run-vitest.mjs extensions/microsoft-foundry/index.test.ts  # 41/41 pass
pnpm tsgo:core                                                          # exit 0 (type guards compile)
pnpm config:schema:check                                                # ok
pnpm config:docs:check                                                  # OK (baseline regenerated)

Real behavior proof

Reproduced end-to-end through the real openclaw config validate command (no Azure/Entra account required — the bug is the config write/validate path).

Behavior addressed: persisted provider model config containing thinkingLevelMap was rejected by strict validation, rolling back the atomic write (blocks Microsoft Foundry Entra onboarding from persisting).

Real environment tested: local OpenClaw CLI built from source on macOS arm64, Node v22.22.3, run against an isolated config file via OPENCLAW_CONFIG_PATH.

Exact steps or command run after this patch: wrote /tmp/openclaw-foundry-repro.json with a microsoft-foundry provider model carrying a thinkingLevelMap (the shape the Entra onboarding writer emits), then ran the real CLI command:

OPENCLAW_CONFIG_PATH=/tmp/openclaw-foundry-repro.json pnpm openclaw config validate

Config file used:

{
  "models": {
    "providers": {
      "microsoft-foundry": {
        "baseUrl": "https://example.services.ai.azure.com/openai/v1",
        "api": "openai-completions",
        "models": [
          { "id": "gpt-5.4", "name": "gpt-5.4", "reasoning": true,
            "thinkingLevelMap": { "off": "none", "minimal": null, "low": "low", "medium": "medium", "high": "high" } }
        ]
      }
    }
  }
}

Before evidence: on main (unfixed), the same command rejected the config and exited 1:

OpenClaw config is invalid: /tmp/openclaw-foundry-repro.json
  × models.providers.microsoft-foundry.models.0: Invalid input
Run `openclaw doctor --fix` to repair, or fix the keys above manually.
# exit code 1

(Same rejection the issue reporter saw as Unrecognized key: "thinkingLevelMap".)

Evidence after fix: terminal output of the same command on this branch:

Config valid: /tmp/openclaw-foundry-repro.json
# exit code 0

Observed result after fix: the config with a model thinkingLevelMap now passes validation and persists; the onboarding write no longer rolls back.

What was not tested: the live Azure Foundry Entra managed-identity onboarding flow (no Entra resource available). Validated through the config write/validate path that the onboarding writer feeds, which is exactly where the rollback occurred.

AI-assisted

This change was AI-assisted. It was implemented by one model and independently reviewed by a different model (code read end-to-end; findings applied: removed a test boundary-escaping import, dropped a non-canonical schema key, added the type guards, regenerated the config baseline). I understand the code and ran the proof above myself. Prompts/session log available on request.

Closes #91011

Notes

Net: +72 / −3 across 4 files (1 schema, 2 tests, 1 generated config baseline).