openclaw - ✅(Solved) Fix Bug: ollama plugin configSchema forbids baseUrl but provider code still reads it [2 pull requests, 1 participants]

openclaw2026-04-17 19:49:23

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.

GitHub issue URL

Helpful · Quick feedback

GitHub stats

openclaw/openclaw#68260•Fetched 2026-04-18 05:53:28

View on GitHub

Comments

Participants

Timeline

Reactions

Author

exscape86-lang

Participants

exscape86-lang

Timeline (top)

cross-referenced ×2referenced ×2

The bundled Ollama plugin's configSchema was tightened to only accept discovery.enabled (with additionalProperties: false), yet the provider runtime code still reads providerConfig.baseUrl / explicit.baseUrl. As a result, it is impossible to configure a remote Ollama endpoint through openclaw.json: any attempt to set plugins.entries.ollama.config.baseUrl is rejected at startup validation, the config is reset to {}, and the provider silently falls back to http://127.0.0.1:11434, generating hundreds of Ollama could not be reached at http://127.0.0.1:11434. warnings in gateway.err.log.

No documented environment variable replaces this — OLLAMA_HOST is set (in the gateway plist) but is not consumed by the plugin code (which only reads OLLAMA_API_KEY).

Error Message

Error: Config validation failed: plugins.entries.ollama.config: invalid config: must NOT have additional properties

Root Cause

Fresh openclaw.json with:

"plugins": {
  "entries": {
    "ollama": { "enabled": true, "config": {} }
  }
}

Attempt to point Ollama at a remote host (e.g. Tailscale-reachable desktop):

openclaw config set plugins.entries.ollama.config.baseUrl "http://100.x.y.z:11434"

Result:

Error: Config validation failed:
  plugins.entries.ollama.config: invalid config: must NOT have additional properties

Cron jobs configured with ollama/* models fall back to the agent default and then fail downstream (in our case, gpt-5.4 fallback hit a separate MCP tool schema error; that's our bug, not yours — but it surfaces because ollama routing silently broke).

Fix Action

Fix / Workaround

Workaround (what we're doing)

Add baseUrl (and optionally authToken, headers if applicable) back to configSchema.properties. Rough patch:

PR fix notes

PR #68270: fix(ollama): allow baseUrl in plugin configSchema to match what the provider code already reads

Repository: openclaw/openclaw
Author: hclsys
State: open | merged: False
Link: https://github.com/openclaw/openclaw/pull/68270

Description (problem / solution / changelog)

Summary

Fixes #68260 — the bundled Ollama plugin's `configSchema` was locked to `discovery.enabled` only (via `additionalProperties: false`), but the runtime code at `extensions/ollama/provider-discovery.ts:70,149` and `extensions/ollama/index.ts:68,179` still reads `providerConfig.baseUrl` / `explicit.baseUrl`. The schema over-restricted a field the code was still consuming, so:

`openclaw config set plugins.entries.ollama.config.baseUrl http://<host>:11434` was rejected at validation
The config was silently reset to `{}` on next gateway restart
The provider fell back to the default `http://127.0.0.1:11434\`, spamming `Ollama could not be reached` errors in `gateway.err.log` for anyone running a remote Ollama server (Tailscale / LAN / Docker `host.docker.internal` / etc.)

Root cause

The reporter traced this cleanly: four distinct call sites in the ollama plugin runtime already branch on `providerConfig.baseUrl` being a trimmed string, so the field has been a first-class runtime input the whole time. The schema just never advertised it.

Fix

Add `baseUrl: { "type": "string" }` to `configSchema.properties` in `extensions/ollama/openclaw.plugin.json`, plus a matching `uiHints.baseUrl` entry for the Control UI settings pane. The `additionalProperties: false` guardrail is preserved — this extends the allowlist rather than loosening it.

No runtime or provider code changes needed because the runtime already reads the field correctly.

Test plan

Added two regression tests in `extensions/ollama/index.test.ts`:
- `configSchema accepts baseUrl so remote Ollama endpoints can be configured (#68260)`
- `configSchema keeps additionalProperties: false so unknown keys still error`
`NODE_OPTIONS=--max-old-space-size=8192 npx tsc --noEmit` — 245 baseline errors on main, 245 on branch (the 1 error is a pre-existing `extensions/ollama/src/stream.ts:644` issue unrelated to this fix).
`pnpm exec oxlint` on the test file — 0 warnings, 0 errors.

Local full vitest is blocked by pre-existing `test/non-isolated-runner.ts` drift (reproduces on `main`); CI exercises the new cases normally.

Risk

No behavior change for users who didn't set `baseUrl` (the field simply becomes an allowed no-op when absent).
The runtime already handled the field correctly before this PR — this just stops validation from stripping it.
Users who were hitting the rejection will get back the behavior they had before the schema tightened (presumably around when #65491 / #64501 et al. moved audio/cli provider detection onto the same validation path).

Changed files

extensions/ollama/index.test.ts (modified, +39/-0)
extensions/ollama/openclaw.plugin.json (modified, +5/-0)

PR #68342: fix(ollama): allow baseUrl in plugin config schema

Repository: openclaw/openclaw
Author: yxjsxy
State: open | merged: False
Link: https://github.com/openclaw/openclaw/pull/68342

Description (problem / solution / changelog)

Summary

allow extensions.ollama.config.baseUrl in the Ollama plugin config schema
add a focused test to lock the schema entry in place
align plugin schema with existing runtime behavior and docs for remote Ollama hosts

Problem

The Ollama plugin runtime already reads pluginConfig.baseUrl, and the docs describe configuring a custom base URL for remote hosts, but extensions/ollama/openclaw.plugin.json did not allow baseUrl in configSchema.

That meant users could follow the documented setup and still hit schema validation failures.

Fixes #68260.

Testing

pnpm vitest run extensions/ollama/index.test.ts extensions/ollama/provider-discovery.import-guard.test.ts extensions/ollama/plugin-registration.contract.test.ts

Notes

I also attempted the broader repo check chain during commit, but it was terminated by the local environment with SIGKILL after targeted tests had already passed. No failures were reported for the changed Ollama files before that termination.

Changed files

extensions/ollama/index.test.ts (modified, +13/-0)
extensions/ollama/openclaw.plugin.json (modified, +5/-0)

Code Example

"plugins": {
     "entries": {
       "ollama": { "enabled": true, "config": {} }
     }
   }

---

openclaw config set plugins.entries.ollama.config.baseUrl "http://100.x.y.z:11434"

---

Error: Config validation failed:
     plugins.entries.ollama.config: invalid config: must NOT have additional properties

---

plugins.entries.ollama.config: invalid config: must NOT have additional properties
  ... Ollama could not be reached at http://127.0.0.1:11434.

---

ERROR: memory embedding provider already registered: ollama (owner: memory-core)

---

"configSchema": {
  "type": "object",
  "additionalProperties": false,
  "properties": {
    "discovery": {
      "type": "object",
      "additionalProperties": false,
      "properties": { "enabled": { "type": "boolean" } }
    }
  }
}

---

if (typeof providerConfig.baseUrl === "string" && providerConfig.baseUrl.trim())
    return resolveOllamaApiBase(providerConfig.baseUrl) !== OLLAMA_DEFAULT_BASE_URL;

---

baseUrl: typeof explicit.baseUrl === "string" && explicit.baseUrl.trim()
    ? resolveOllamaApiBase(explicit.baseUrl)
    : OLLAMA_DEFAULT_BASE_URL,

---

"configSchema": {
   "type": "object",
   "additionalProperties": false,
   "properties": {
+    "baseUrl": { "type": "string", "format": "uri" },
     "discovery": {
       "type": "object",
       "additionalProperties": false,
       "properties": { "enabled": { "type": "boolean" } }
     }
   }
 }

RAW_BUFFERClick to expand / collapse

Bug: ollama plugin `configSchema` forbids `baseUrl`, but provider code still reads it

Environment

OpenClaw: 2026.4.14 (323493f)
Node: v22.22.2
OS: macOS 15 (Darwin 25.2.0), Apple Silicon
Plugin: bundled @openclaw/ollama-provider (dist/extensions/ollama)

Summary

No documented environment variable replaces this — OLLAMA_HOST is set (in the gateway plist) but is not consumed by the plugin code (which only reads OLLAMA_API_KEY).

Reproduction

Fresh openclaw.json with:

"plugins": {
  "entries": {
    "ollama": { "enabled": true, "config": {} }
  }
}

Attempt to point Ollama at a remote host (e.g. Tailscale-reachable desktop):

openclaw config set plugins.entries.ollama.config.baseUrl "http://100.x.y.z:11434"

Result:

Error: Config validation failed:
  plugins.entries.ollama.config: invalid config: must NOT have additional properties

Cron jobs configured with ollama/* models fall back to the agent default and then fail downstream (in our case, gpt-5.4 fallback hit a separate MCP tool schema error; that's our bug, not yours — but it surfaces because ollama routing silently broke).

Expected Behavior

Either:

(a) configSchema accepts baseUrl (and the previously working discovery sub-object) as the code path already handles it, or
(b) The plugin reads a well-known environment variable such as OLLAMA_HOST as a remote-endpoint escape hatch (this would match common Ollama ecosystem convention).

Actual Behavior

configSchema rejects any property besides discovery.enabled.
On gateway restart, any "invalid" ollama config fields are stripped / reset to {}.

gateway.err.log fills with:

plugins.entries.ollama.config: invalid config: must NOT have additional properties
... Ollama could not be reached at http://127.0.0.1:11434.

openclaw plugins inspect ollama shows diagnostic:

ERROR: memory embedding provider already registered: ollama (owner: memory-core)

Root Cause (source evidence)

Schema declaration at dist/extensions/ollama/openclaw.plugin.json (bundled copy):

"configSchema": {
  "type": "object",
  "additionalProperties": false,
  "properties": {
    "discovery": {
      "type": "object",
      "additionalProperties": false,
      "properties": { "enabled": { "type": "boolean" } }
    }
  }
}

Code that still reads baseUrl:

dist/extensions/ollama/provider-discovery.js:22

if (typeof providerConfig.baseUrl === "string" && providerConfig.baseUrl.trim())
  return resolveOllamaApiBase(providerConfig.baseUrl) !== OLLAMA_DEFAULT_BASE_URL;

dist/extensions/ollama/provider-discovery.js:56

baseUrl: typeof explicit.baseUrl === "string" && explicit.baseUrl.trim()
  ? resolveOllamaApiBase(explicit.baseUrl)
  : OLLAMA_DEFAULT_BASE_URL,

dist/extensions/ollama/index.js:122 mirrors the same explicit.baseUrl path.

The plugin's providerAuthEnvVars.ollama only lists OLLAMA_API_KEY, so there is no documented env-var path either.

Workaround (what we're doing)

Reverted the affected cron job to google/gemini-2.5-flash so it stops routing through the broken ollama path.
The ollama provider remains effectively unusable for remote hosts until this is resolved; a local socat proxy bridging 127.0.0.1:11434 → <remote>:11434 would work but is a system-level hack rather than a real fix.

Suggested Fix

Add baseUrl (and optionally authToken, headers if applicable) back to configSchema.properties. Rough patch:

 "configSchema": {
   "type": "object",
   "additionalProperties": false,
   "properties": {
+    "baseUrl": { "type": "string", "format": "uri" },
     "discovery": {
       "type": "object",
       "additionalProperties": false,
       "properties": { "enabled": { "type": "boolean" } }
     }
   }
 }

Alternatively (or in addition), honor OLLAMA_HOST as the canonical remote-endpoint env var.

Impact

Affects any multi-machine setup where Ollama runs on a different host than the gateway (e.g. thin-laptop + workstation-GPU topology via Tailscale, which is a common pattern). Silent fallback to localhost is particularly painful because openclaw doctor and other health checks do not currently surface this mismatch.

Happy to open a PR if the maintainers confirm approach (a) or (b) is the intended direction.

extent analysis

TL;DR

The most likely fix is to update the configSchema to include baseUrl as a valid property, allowing users to configure a remote Ollama endpoint.

Guidance

Update the configSchema in openclaw.plugin.json to include baseUrl as a string property with a URI format, as suggested in the issue.
Consider adding baseUrl to the providerAuthEnvVars.ollama to allow configuration via an environment variable, such as OLLAMA_HOST.
Verify that the updated configSchema allows configuration of a remote Ollama endpoint without validation errors.
Test the updated configuration to ensure that the Ollama provider can connect to the remote endpoint successfully.

Example

 "configSchema": {
   "type": "object",
   "additionalProperties": false,
   "properties": {
+    "baseUrl": { "type": "string", "format": "uri" },
     "discovery": {
       "type": "object",
       "additionalProperties": false,
       "properties": { "enabled": { "type": "boolean" } }
     }
   }
 }

Notes

The suggested fix assumes that the intention is to allow configuration of a remote Ollama endpoint. If the intention is to use an environment variable, such as OLLAMA_HOST, the configSchema update may not be necessary.

Recommendation

Apply the suggested fix by updating the configSchema to include baseUrl as a valid property, as this will allow users to configure a remote Ollama endpoint without validation errors.

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?

#api #conversation history #tool integration #LLM response #environment variable

Still need to ship something?

×6

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

openclaw - ✅(Solved) Fix Bug: ollama plugin configSchema forbids baseUrl but provider code still reads it [2 pull requests, 1 participants]

Recommended Tools

GitHub issue graph ai analysis

Error Message

Root Cause

Fix Action

Fix / Workaround

Workaround (what we're doing)

PR fix notes

PR #68270: fix(ollama): allow baseUrl in plugin configSchema to match what the provider code already reads

Description (problem / solution / changelog)

Summary

Root cause

Fix

Test plan

Risk

Changed files

PR #68342: fix(ollama): allow baseUrl in plugin config schema

Description (problem / solution / changelog)

Summary

Problem

Testing

Notes

Changed files

Code Example

Bug: ollama plugin configSchema forbids baseUrl, but provider code still reads it

Environment

Summary

Reproduction

Expected Behavior

Actual Behavior

Root Cause (source evidence)

Workaround (what we're doing)

Suggested Fix

Impact

extent analysis

TL;DR

Guidance

Example

Notes

Recommendation

Still need to ship something?

RELATED_DISCOVERY

TRENDING

Bug: ollama plugin `configSchema` forbids `baseUrl`, but provider code still reads it