[Bug]: ollama local provider incorrectly requires API key after provider reconfiguration/removal; fallback fails with No API key found for provider "ollama"

[chidugit]

Summary

When using a local Ollama model (ollama/lfm2:latest) as fallback, OpenClaw can enter a broken state where it requires auth profile/API key for ollama even though provider is local and reachable. This leads to failover collapse if primary model is invalid/unavailable.

Error shown:

No API key found for provider "ollama"... Configure auth for this agent ... (auth)

This is unexpected for local Ollama usage.

Environment
OpenClaw version: 2026.2.26 (bc50708)
OS: macOS (Apple Silicon)
Node: v22.22.0
Ollama: local daemon at http://127.0.0.1:11434
Model: lfm2:latest (local, no cloud auth expected)

Relevant config snapshot (redacted)
{
"auth": {
"profiles": {
"openai-codex:default": {
"provider": "openai-codex",
"mode": "oauth"
}
}
},
"models": {
"providers": {}
},
"agents": {
"defaults": {
"model": {
"primary": "openai-codex/gpt-5.3-codex",
"fallbacks": ["ollama/lfm2:latest"]
},
"models": {
"openai-codex/gpt-5.3-codex": {},
"ollama/lfm2:latest": { "params": { "num_ctx": 32768 } }
}
}
}
}

Steps to reproduce

1. Configure fallback ollama/lfm2:latest.
2. Remove or mutate models.providers.ollama during troubleshooting/restart flow.
3. Set/leave primary to an invalid model (e.g. openai-codex/does-not-exist-test) so failover triggers.
4. Send any message.
5. Observe failover error demanding API key/auth profile for ollama.

Expected behavior

Suspected root cause
Fallback resolution path treats ollama as requiring auth profile when provider block is absent/incomplete.
Error classification likely conflates “provider not configured” with “missing API key/auth”.
In local model workflows, this is misleading and blocks recovery.
Suggested fixes
Provider validation before auth checks
If models.providers.ollama is missing, return explicit configuration error:
“Provider ollama not configured” (not auth error).
Local provider auth semantics
For api: "ollama" + loopback baseUrl, allow no-auth mode by default.

Actionable diagnostics
Add remediation hint:

“Add models.providers.ollama with baseUrl and model list”
Avoid suggesting openclaw agents add unless auth is truly required.
Guardrail in models set / startup checks
Warn if a fallback references a provider not present in models.providers.
Workaround
Re-add provider explicitly in ~/.openclaw/openclaw.json:

{
"models": {
"providers": {
"ollama": {
"baseUrl": "http://127.0.0.1:11434",
"api": "ollama",
"apiKey": "ollama-local",
"models": [
{
"id": "lfm2:latest",
"name": "LFM2 (local)",
"reasoning": false,
"input": ["text"],
"cost": { "input": 0, "output": 0, "cacheRead": 0, "cacheWrite": 0 },
"contextWindow": 32768,
"maxTokens": 32768
}
]
}
}
}
}

Actual behavior

Actual behavior
OpenClaw fails all models with combined errors:

primary: Unknown model: openai-codex/does-not-exist-test
fallback: No API key found for provider "ollama" ... (auth)
Result:

All models failed (2) ... openai-codex/does-not-exist-test ... | ollama/lfm2:latest: No API key found for provider "ollama"...

OpenClaw version

2026.2.26 (bc50708)

Operating system

macOS (Apple Silicon)

Install method

No response

Logs, screenshots, and evidence

Impact and severity

No response

Additional information

No response

[awkoy]

Opened a PR with a fix: #28963

The fix auto-injects a placeholder API key for keyless local providers (Ollama, vLLM) so they work without requiring OLLAMA_API_KEY or VLLM_API_KEY to be set. This follows the same pattern already used by minimax-portal and qwen-portal in the codebase.

[chidugit]

thanks @awkoy , waiting for your changes in next release!

[xxcbzxx]

I'm getting this error: - assuming related?

Agent failed before reply: All models failed (3): ollama/gpt-oss:20b: No API key found for provider "ollama". Auth store: /home/node/.openclaw/agents/main/agent/auth-profiles.json (agentDir: /home/node/.openclaw/agents/main/agent). Configure auth for this agent (openclaw agents add <id>) or copy auth-profiles.json from the main agentDir. (auth) | ollama/qwen:14b: No API key found for provider "ollama". Auth store: /home/node/.openclaw/agents/main/agent/auth-profiles.json (agentDir: /home/node/.openclaw/agents/main/agent). Configure auth for this agent (openclaw agents add <id>) or copy auth-profiles.json from the main agentDir. (auth) | ollama/llama3:8b: No API key found for provider "ollama". Auth store: /home/node/.openclaw/agents/main/agent/auth-profiles.json (agentDir: /home/node/.openclaw/agents/main/agent). Configure auth for this agent (openclaw agents add <id>) or copy auth-profiles.json from the main agentDir. (auth). Logs: openclaw logs --follow

[ethduke]

Still reproducible on 2026.3.1 (Linux, AWS EC2).

Trigger: primary model set to openai/gpt-5.3-codex via natural language switch with no OpenAI API key in auth-profiles.json.

Additional symptom not in the original report: the failure cascades into an error storm — both lane=main and lane=session:agent:main:main fail and immediately re-enqueue with zero backoff, producing repeated identical errors within the same second. The embedded agent fallback also hits the same wall. End result is the agent fully locks up with no recovery, spamming the error to the connected channel (Telegram in my case).

Fallback also doesn't execute when primary fails with auth error on 2026.3.1, so the error is thrown upstream of the failover dispatch, so no fallback is ever attempted regardless of configuration. The agent locks up completely.

[bennydiesel]

Same issue here - looking forward to the update.

[vincentkoc]

Maintainer triage note:

This looks related to the keyless local-provider/auth path that has changed on main since v2026.3.2.

Relevant status:

• v2026.3.2 exists and was tagged on 2026-03-03
• there is still no v2026.3.3 tag yet
• main now contains follow-up work allowing configured Ollama endpoints without dummy API keys (36afd1b2b0)

So the current read is: likely fixed on main for the misleading local-Ollama API-key/auth path, but not yet verified in a tagged release.

I would retest this on the next tagged release before treating any remaining local-model failures here as the same bug. If it still reproduces after that, please capture whether the failure is still the auth/API-key path or a different fallback/runtime failure.

[vincentkoc]

Closing this as fixed on main for the misleading local-Ollama auth/API-key path.

The bug here was the local provider falling into No API key found for provider "ollama" after provider reconfiguration / fallback resolution. That path has changed on main since v2026.3.2, and the relevant follow-up is in 36afd1b2b0.

This should not stay open as a catch-all for every future local-model failure, because the auth/provider failure described here is specific and appears addressed.

Thanks for the detailed repro and the fallback-collapse details. If a build that includes the post-v2026.3.2 Ollama fixes still fails, please open a fresh issue with the current error path so we do not conflate new runtime failures with this resolved auth/provider bug.