Summary

• Problem: openclaw doctor --fix could migrate legacy skills.entries.nano-banana-pro config into an invalid models.providers.google object.
• Why it matters: the migration wrote apiKey only, then config validation failed because ModelProviderSchema requires baseUrl and models.
• What changed: the nano-banana migration now fills missing google.baseUrl and google.models when it introduces the google provider entry.
• What did NOT change (scope boundary): no broader provider normalization/refactor; existing explicit native google config is preserved.
• AI-assisted: yes (prepared with Codex/OpenClaw assistance).
• Testing level: lightly tested but targeted to the affected migration path.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes doctor --fix crashes with Config validation failed on models.providers.google.baseUrl #53756
• Related doctor --fix crashes with Config validation failed on models.providers.google.baseUrl #53756
• This PR fixes a bug or regression

Root Cause / Regression History (if applicable)

• Root cause: normalizeCompatibilityConfigValues() migrated legacy nano-banana config into models.providers.google.apiKey but did not materialize the rest of the required ModelProviderSchema shape.
• Missing detection / guardrail: there was no regression test asserting that the migrated google provider entry is schema-valid when created from legacy nano-banana config alone.
• Prior context (git blame, prior PR, issue, or refactor if known): reported in doctor --fix crashes with Config validation failed on models.providers.google.baseUrl #53756 with a direct repro against doctor --fix.
• Why this regressed now: legacy migration handled the model selection + API key move, but not the required provider defaults for a newly created google provider entry.
• If unknown, what was ruled out: N/A.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file: src/commands/doctor-legacy-config.migrations.test.ts
• Scenario the test should lock in: migrating legacy skills.entries.nano-banana-pro config with no pre-existing models.providers.google should produce a schema-valid google provider entry including baseUrl and models.
• Why this is the smallest reliable guardrail: the bug is introduced entirely inside the legacy migration logic, so the migration test is the narrowest place to prevent recurrence.
• Existing test that already covers this (if any): the nano-banana migration test existed, but it did not assert the full required google provider shape.
• If no new test is added, why not: N/A.

User-visible / Behavior Changes

• openclaw doctor --fix no longer fails validation when migrating legacy skills.entries.nano-banana-pro config into models.providers.google.

Security Impact (required)

• New permissions/capabilities? (Yes/No): No
• Secrets/tokens handling changed? (Yes/No): No
• New/changed network calls? (Yes/No): No
• Command/tool execution surface changed? (Yes/No): No
• Data access scope changed? (Yes/No): No
• If any Yes, explain risk + mitigation: N/A

Repro + Verification

Environment

• OS: macOS 25.3.0 (arm64)
• Runtime/container: local repo checkout, Node 25.5.0, pnpm 10.32.1
• Model/provider: N/A
• Integration/channel (if any): N/A
• Relevant config (redacted): legacy skills.entries.nano-banana-pro with apiKey or env.GEMINI_API_KEY, and no pre-existing models.providers.google

Steps

1. Configure legacy skills.entries.nano-banana-pro with an API key.
2. Ensure models.providers.google is absent.
3. Run openclaw doctor --fix.

Expected

• Legacy config migrates successfully.
• Resulting models.providers.google is schema-valid.

Actual

• Before this patch, validation failed with models.providers.google.baseUrl: Invalid input: expected string, received undefined.
• After this patch, the migration test passes and asserts the required google provider shape.

Evidence

Attach at least one:

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

• Verified scenarios:
  • ran pnpm exec vitest run src/commands/doctor-legacy-config.migrations.test.ts
  • verified migrated config now includes models.providers.google.baseUrl and models.providers.google.models
  • commit-time local checks passed during commit creation
• Edge cases checked:
  • preserves explicit existing native google provider config
  • prefers legacy env.GEMINI_API_KEY over legacy skill apiKey during migration
• What you did not verify:
  • did not run full pnpm build && pnpm check && pnpm test
  • did not run broader end-to-end doctor flows
  • did not run codex review --base origin/main yet

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

Compatibility / Migration

• Backward compatible? (Yes/No): Yes
• Config/env changes? (Yes/No): No
• Migration needed? (Yes/No): No
• If yes, exact upgrade steps: N/A

Failure Recovery (if this breaks)

• How to disable/revert this change quickly: revert commit 01c8787de4
• Files/config to restore: src/commands/doctor-legacy-config.ts, src/commands/doctor-legacy-config.migrations.test.ts
• Known bad symptoms reviewers should watch for: unexpected mutation of explicit existing models.providers.google config beyond filling missing fields in the legacy migration path

Risks and Mitigations

• Risk: migration could accidentally overwrite explicit google provider config.
  • Mitigation: changes only fill missing defaults in the path where the migration introduces the provider config; existing explicit config remains covered by regression tests.