openclaw - 💡(How to fix) Fix [Bug]: Ollama provider fails silently in Web/TUI in v2026.3.28+ with fallback chain and model allowlist validation [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#60679Fetched 2026-04-08 02:48:22
View on GitHub
Comments
0
Participants
1
Timeline
1
Reactions
0
Author
Participants
Timeline (top)
labeled ×1

After upgrading from v2026.3.24 to v2026.3.28+, Ollama providers become unresponsive in Web/TUI chat sessions while gateway logs show 'model not allowed' errors and fallback to OpenRouter.

Root Cause

After upgrading from v2026.3.24 to v2026.3.28+, Ollama providers become unresponsive in Web/TUI chat sessions while gateway logs show 'model not allowed' errors and fallback to OpenRouter.

Fix Action

Fix / Workaround

2026-03-30T22:46:42.073+08:00 [ws] ⇄ res ✗ sessions.patch 55ms errorCode=INVALID_REQUEST errorMessage=model not allowed: ollama-m2mba/minimax-m2.7 conn=fc544db5…54a8 2026-03-30T22:47:22.927+08:00 [ws] ⇄ res ✗ sessions.patch 93ms errorCode=INVALID_REQUEST errorMessage=model not allowed: ollama-m2mba/minimax-m2.7 conn=fc544db5…54a8

Affected: Users running multiple Ollama providers with fallback chains on v2026.3.28+. Severity: High (blocks chat functionality in Web/TUI when primary Ollama is unavailable). Frequency: Always when primary Ollama fails or is unavailable. Consequence: Agents become unresponsive; users must downgrade to v2026.3.24 to恢复 chat functionality.

Workaround: Stay on v2026.3.24 or set primary model directly to ollama-m2mba/minimax-m2.7:cloud (bypassing ollama-cloud).

Code Example

Gateway log excerpts (logs/gateway.log):


2026-03-30T22:46:42.073+08:00 [ws] ⇄ res ✗ sessions.patch 55ms errorCode=INVALID_REQUEST errorMessage=model not allowed: ollama-m2mba/minimax-m2.7 conn=fc544db5…54a8
2026-03-30T22:47:22.927+08:00 [ws] ⇄ res ✗ sessions.patch 93ms errorCode=INVALID_REQUEST errorMessage=model not allowed: ollama-m2mba/minimax-m2.7 conn=fc544db5…54a8

Historical errors:
2026-03-21T14:18:46.343+08:00 model not allowed: ollama-cloud/minimax-m2.7:cloud
2026-03-25T23:01:39.052+08:00 model not allowed: set ollama/minimax-m2.7:cloud
2026-03-26T19:13:32.246+08:00 model not allowed: ollama-cloud/m2mbaollama


Note: All three Ollama endpoints respond correctly to curl tests:
- curl https://ollama.mryee.win/api/tags → 200 OK
- curl https://m2mbaollama.mryee.win/api/tags → 200 OK
- Direct chat completions work via curl for ollama-imac and ollama-m2mba
RAW_BUFFERClick to expand / collapse

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

After upgrading from v2026.3.24 to v2026.3.28+, Ollama providers become unresponsive in Web/TUI chat sessions while gateway logs show 'model not allowed' errors and fallback to OpenRouter.

Steps to reproduce

  1. Upgrade from OpenClaw v2026.3.24 to v2026.3.28 (or v2026.4.1/v2026.4.2).
  2. Configure three Ollama providers: ollama-cloud (https://ollama.com), ollama-imac (https://ollama.mryee.win), ollama-m2mba (https://m2mbaollama.mryee.win via Cloudflare Tunnel).
  3. Set agent.defaults.model.primary to ollama-cloud/minimax-m2.7 with fallbacks to ollama-imac and ollama-m2mba.
  4. Attempt to chat in Web or TUI.
  5. Observe: session hangs or falls back to OpenRouter; gateway logs show 'model not allowed' errors.

Expected behavior

In v2026.3.24, when ollama-cloud (primary) fails or is unavailable, the fallback chain (ollama-imac, ollama-m2mba) works correctly and chat continues without issues.

Actual behavior

In v2026.3.28+, when ollama-cloud fails, the fallback chain does not properly recover. The gateway logs show repeated 'model not allowed' errors and the model eventually falls back to OpenRouter instead of the configured Ollama fallbacks. curl tests confirm all three Ollama endpoints are reachable and respond correctly.

OpenClaw version

v2026.4.2 (also affects v2026.3.28, v2026.3.29, v2026.4.1). Last known good: v2026.3.24.

Operating system

macOS 11+ (Big Sur/Catalina) on MacBook Air M2

Install method

No response

Model

ollama-cloud/minimax-m2.7 (primary); fallbacks: ollama-imac/minimax-m2.7:cloud, ollama-m2mba/minimax-m2.7:cloud

Provider / routing chain

openclaw -> ollama-cloud (https://ollama.com); fallback chain: ollama-imac (https://ollama.mryee.win), ollama-m2mba (https://m2mbaollama.mryee.win via Cloudflare Tunnel)

Additional provider/model setup details

No response

Logs, screenshots, and evidence

Gateway log excerpts (logs/gateway.log):


2026-03-30T22:46:42.073+08:00 [ws] ⇄ res ✗ sessions.patch 55ms errorCode=INVALID_REQUEST errorMessage=model not allowed: ollama-m2mba/minimax-m2.7 conn=fc544db5…54a8
2026-03-30T22:47:22.927+08:00 [ws] ⇄ res ✗ sessions.patch 93ms errorCode=INVALID_REQUEST errorMessage=model not allowed: ollama-m2mba/minimax-m2.7 conn=fc544db5…54a8

Historical errors:
2026-03-21T14:18:46.343+08:00 model not allowed: ollama-cloud/minimax-m2.7:cloud
2026-03-25T23:01:39.052+08:00 model not allowed: set ollama/minimax-m2.7:cloud
2026-03-26T19:13:32.246+08:00 model not allowed: ollama-cloud/m2mbaollama


Note: All three Ollama endpoints respond correctly to curl tests:
- curl https://ollama.mryee.win/api/tags → 200 OK
- curl https://m2mbaollama.mryee.win/api/tags → 200 OK
- Direct chat completions work via curl for ollama-imac and ollama-m2mba

Impact and severity

Affected: Users running multiple Ollama providers with fallback chains on v2026.3.28+. Severity: High (blocks chat functionality in Web/TUI when primary Ollama is unavailable). Frequency: Always when primary Ollama fails or is unavailable. Consequence: Agents become unresponsive; users must downgrade to v2026.3.24 to恢复 chat functionality.

Additional information

Last known good version: v2026.3.24. First known bad version: v2026.3.28.

Changelog analysis — most likely culprit:

  1. v2026.3.28 'Providers/transport policy': 'centralize request auth, proxy, TLS, and header shaping across shared HTTP, stream, and websocket paths' — may affect how auth headers are sent to Ollama endpoints.

  2. v2026.3.28 'Agents/subagents': 'pin admin-only subagent gateway calls to operator.admin' — may affect session/model routing.

  3. v2026.4.2 'Exec defaults': 'make gateway/node host exec default to YOLO mode by requesting security=full with ask=off' — if Ollama provider uses exec under the hood, this could affect it.

Workaround: Stay on v2026.3.24 or set primary model directly to ollama-m2mba/minimax-m2.7:cloud (bypassing ollama-cloud).

extent analysis

TL;DR

Downgrade to v2026.3.24 or set the primary model directly to ollama-m2mba/minimax-m2.7:cloud to bypass the unresponsive Ollama provider issue.

Guidance

  • Review the changelog for v2026.3.28 and subsequent versions to understand the changes made to providers, transport policy, and agent/subagent configurations.
  • Verify that the Ollama endpoints are correctly configured and reachable by running curl tests, as shown in the issue.
  • Test setting the primary model directly to ollama-m2mba/minimax-m2.7:cloud to see if it resolves the issue without downgrading.
  • Investigate the 'model not allowed' errors in the gateway logs to determine if there are any authentication or authorization issues with the Ollama providers.

Example

No code snippet is provided as the issue does not require a code change, but rather a configuration or version change.

Notes

The issue seems to be related to changes made in v2026.3.28, specifically with the centralization of request auth, proxy, TLS, and header shaping. The exact cause is unclear, but downgrading or changing the primary model appears to be a viable workaround.

Recommendation

Apply the workaround by setting the primary model directly to ollama-m2mba/minimax-m2.7:cloud, as this seems to bypass the issue without requiring a downgrade. This approach allows for continued use of a newer version while mitigating the regression.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

In v2026.3.24, when ollama-cloud (primary) fails or is unavailable, the fallback chain (ollama-imac, ollama-m2mba) works correctly and chat continues without issues.

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

openclaw - 💡(How to fix) Fix [Bug]: Ollama provider fails silently in Web/TUI in v2026.3.28+ with fallback chain and model allowlist validation [1 participants]