Summary

Describe the problem and fix in 2–5 bullets:

• Problem: openclaw config set models.providers.ollama.apiKey "ollama-local" fails validation unless models.providers.ollama.baseUrl and models.providers.ollama.models are already present.
• Why it matters: this breaks the documented Ollama onboarding path and keeps Ollama auto-discovery fails: schema requires baseUrl+models[] but docs describe apiKey-only env var mode #22836 unresolved.
• What changed: config set now auto-seeds a valid minimal Ollama provider object when setting models.providers.ollama.apiKey and the provider object does not yet exist.
• What did NOT change (scope boundary): no model schema/type loosening, no global provider validation changes, no behavior changes for other provider paths.

Change Type (select all)

• Bug fix
• Feature
• Refactor
• 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 Ollama auto-discovery fails: schema requires baseUrl+models[] but docs describe apiKey-only env var mode #22836
• Related fix(config): make provider baseUrl and models optional for auto-discovery #25118
• Supersedes fix(config): make provider baseUrl and models optional for auto-discovery #25118 for this issue path

User-visible / Behavior Changes

• openclaw config set models.providers.ollama.apiKey "ollama-local" now writes a valid provider object (with default base URL and empty model list) instead of failing config validation.

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:

Repro + Verification

Environment

• OS: macOS
• Runtime/container: Node 22 / pnpm
• Model/provider: Ollama
• Integration/channel (if any): N/A
• Relevant config (redacted): empty ~/.openclaw/openclaw.json

Steps

1. Start with {} config.
2. Run openclaw config set models.providers.ollama.apiKey "ollama-local".
3. Inspect written config.

Expected

• Command succeeds and config remains schema-valid.

Actual

• Before this change: validation error for missing baseUrl/models.
• After this change: provider is auto-seeded with valid defaults and command succeeds.

Evidence

Attach at least one:

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

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios:
  • pnpm vitest run src/cli/config-cli.test.ts
  • pnpm check
  • Manual CLI run with temp HOME writing an empty config, then running openclaw config set models.providers.ollama.apiKey "ollama-local".
• Edge cases checked:
  • No seeding occurs when setting unrelated paths.
• What you did not verify:
  • Full onboarding wizard flow end-to-end.

Compatibility / Migration

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

Failure Recovery (if this breaks)

• How to disable/revert this change quickly:
  • Revert this PR.
• Files/config to restore:
  • src/cli/config-cli.ts
• Known bad symptoms reviewers should watch for:
  • Unexpected provider object creation on non-Ollama paths.

Risks and Mitigations

List only real risks for this PR. Add/remove entries as needed. If none, write None.

• Risk:
  • Over-seeding config for unrelated keys.
  • Mitigation:
    • Guard is path-exact (models.providers.ollama.apiKey) and only runs when provider object is absent.