Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix CLI prints Ollama could not be reached at http://127.0.0.1:11434. to stderr on every invocation, even when Ollama is not a configured provider [3 pull requests, 3 comments, 2 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#77942•Fetched 2026-05-06 06:18:58
View on GitHub
Comments
3
Participants
2
Timeline
10
Reactions
2
Author
jvpflumjvpflum
Participants
clawsweeper[bot]clawsweeper[bot]jvpflumjvpflum
Timeline (top)
cross-referenced ×4commented ×3referenced ×3

On every CLI invocation — including non-interactive --json reads — the CLI emits

Ollama could not be reached at http://127.0.0.1:11434.

to stderr, regardless of whether Ollama is in agents.defaults.model.primary, agents.defaults.model.fallbacks, the model catalog, or any auth profile. There is no ollama/* model anywhere in my configuration.

This corrupts stderr capture in any programmatic consumer (frontends, CI scripts, GitHub Actions runners, daemon supervisors) and forces every consumer to filter the noise.

Error Message

The Ollama provider probe should run only when Ollama is referenced by the active agent's model chain or auth profiles. If a probe must run for catalog refresh, its unreachable-host message should be at debug level, not warn/stderr.

Root Cause

On every CLI invocation — including non-interactive --json reads — the CLI emits

Ollama could not be reached at http://127.0.0.1:11434.

to stderr, regardless of whether Ollama is in agents.defaults.model.primary, agents.defaults.model.fallbacks, the model catalog, or any auth profile. There is no ollama/* model anywhere in my configuration.

This corrupts stderr capture in any programmatic consumer (frontends, CI scripts, GitHub Actions runners, daemon supervisors) and forces every consumer to filter the noise.

Fix Action

Fix / Workaround

We ship a desktop frontend (Crystal: https://github.com/jvpflum/Crystal) on top of OpenClaw and currently filter this string in two places to avoid leaking the warning into user-facing chat output and into gateway-log views. Every JSON consumer needs the same workaround. A literal-string search for could not be reached at http://127.0.0.1:11434 will hit other downstream tools too.

  1. Demote unconfigured probes to debug. If no ollama/* reference is found in the resolved model chain, suppress the warning entirely.
  2. Honor OPENCLAW_LOG_LEVEL. Currently the warning prints regardless of level.
  3. Probe lazily. Only probe Ollama on the first dispatch that targets it, not on every CLI startup.

PR fix notes

PR #77951: fix(ollama): suppress unreachable warning when OLLAMA_API_KEY exists but Ollama is not configured

Description (problem / solution / changelog)

Fixes #77942

Root cause

resolveOllamaDiscoveryResult computes the quiet flag as:

quiet: !hasRealOllamaKey && !hasMeaningfulExplicitConfig,

When a user has OLLAMA_API_KEY set in their environment from a previous Ollama setup — but has since removed Ollama from their config — hasRealOllamaKey is true (the key is a real key, not the synthetic "ollama-local" marker). This makes quiet = false, so when the ambient discovery probe finds Ollama unreachable, buildOllamaProvider emits:

Ollama could not be reached at http://127.0.0.1:11434.

on every CLI invocation, even for unrelated commands like openclaw agents list --json.

The !hasRealOllamaKey condition was intended to distinguish "user has a key, so they care about Ollama" from "this is just the local synthetic marker". But a real key from a past setup doesn't mean the user has opted Ollama back in — the absence of any explicit Ollama config in openclaw.json is the correct signal.

Fix

Remove !hasRealOllamaKey from the quiet expression. Ambient discovery is always silent when there is no explicit Ollama config (hasMeaningfulExplicitConfig = false). The warn is only useful when the user has explicitly configured Ollama (models, custom baseUrl, apiKey, etc.) and it fails to connect.

// Before
quiet: !hasRealOllamaKey && !hasMeaningfulExplicitConfig,

// After
quiet: !hasMeaningfulExplicitConfig,

Test

Added a test case that reproduces the bug: OLLAMA_API_KEY set to a real (non-marker) value, no Ollama in config, Ollama unreachable → no console.warn fires.

All 15 existing Ollama provider-discovery tests pass.

Changed files

  • extensions/ollama/provider-discovery.test.ts (modified, +22/-0)
  • extensions/ollama/src/discovery-shared.ts (modified, +7/-1)

PR #77971: fix(skills): use junction symlinks on Windows to avoid EPERM without Developer Mode (#77958)

Description (problem / solution / changelog)

Fixes #77958.

Summary

  • Use Windows junction directory links when publishing plugin-provided skills into the managed plugin-skills directory.
  • Preserve the existing non-Windows dir symlink behavior.
  • Treat Windows junction-like generated directories as managed plugin-skill entries during stale cleanup.
  • Add focused regression coverage and an Unreleased changelog entry.

Verification

  • pnpm install --frozen-lockfile
  • pnpm test src/agents/skills/plugin-skills.test.ts — 22 tests passed
  • pnpm exec oxfmt --check --threads=1 src/agents/skills/plugin-skills.ts src/agents/skills/plugin-skills.test.ts CHANGELOG.md
  • git diff --check
  • pnpm check:changed

Maintainer notes

This branch was narrowed during maintainer prep to the #77958 plugin-skills Windows fix only. The unrelated Ollama changes from the original branch were dropped.

Live Windows standard-user proof was not run from this macOS maintainer workspace; the issue is source-backed by the existing fs.symlinkSync(..., "dir") call and covered by focused regression tests. A proof: override label/comment records that maintainer decision.

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • src/agents/skills/plugin-skills.test.ts (modified, +50/-2)
  • src/agents/skills/plugin-skills.ts (modified, +26/-8)

PR #78006: fix(daemon): fall back to Startup-folder on localized schtasks access-denied (#77993)

Description (problem / solution / changelog)

Fixes #77993.

Root cause

shouldFallbackToStartupEntry matched only the English string "Access is denied". On Windows hosts with a non-English locale, schtasks /Create emits the localized equivalent — for example Spanish "Acceso denegado" — which did not match the regex. The fallback to the per-user Startup-folder launcher was skipped and the install threw schtasks create failed: ERROR: Acceso denegado.

Fix

Extend the denial-string check to cover the most common locale variants:

LocaleString
Englishaccess is denied (existing)
Spanishacceso denegado
Germanzugriff verweigert
Frenchaccès refusé
Italianaccesso negato

All checks are case-insensitive.

Test

New test in schtasks.startup-fallback.test.ts drives installGatewayScheduledTask with stderr: "ERROR: Acceso denegado." and confirms the Startup-folder launcher is created (matching the English coverage added in the existing test).

All 14 startup-fallback tests pass.

Changed files

  • extensions/codex/src/app-server/run-attempt.ts (modified, +16/-3)
  • extensions/ollama/provider-discovery.test.ts (modified, +22/-0)
  • extensions/ollama/src/discovery-shared.ts (modified, +7/-1)
  • src/agents/skills/plugin-skills.ts (modified, +1/-1)
  • src/daemon/schtasks.startup-fallback.test.ts (modified, +13/-0)
  • src/daemon/schtasks.ts (modified, +4/-0)

Code Example

Ollama could not be reached at http://127.0.0.1:11434.

---

> openclaw agents list --json 2>&1 | Out-String
[
  { "id": "main", "model": "openai/gpt-5.4-mini", ... },
  ...
]
node.exe : Ollama could not be reached at http://127.0.0.1:11434.

> openclaw sessions --json 2>&1 | Out-String
{ "path": "...", "count": 69, "sessions": [...] }
node.exe : Ollama could not be reached at http://127.0.0.1:11434.

> openclaw models list --json 2>&1 | Out-String
node.exe : Ollama could not be reached at http://127.0.0.1:11434.
{ "count": 7, "models": [...] }
RAW_BUFFERClick to expand / collapse

Version

  • openclaw 2026.4.20 (115f05d) (also reproduces against latest 2026.5.4 per CHANGELOG inspection)
  • Windows 11, Node.js (via nvm4w), PowerShell 7

Summary

On every CLI invocation — including non-interactive --json reads — the CLI emits

Ollama could not be reached at http://127.0.0.1:11434.

to stderr, regardless of whether Ollama is in agents.defaults.model.primary, agents.defaults.model.fallbacks, the model catalog, or any auth profile. There is no ollama/* model anywhere in my configuration.

This corrupts stderr capture in any programmatic consumer (frontends, CI scripts, GitHub Actions runners, daemon supervisors) and forces every consumer to filter the noise.

Reproduction

With no Ollama configuration anywhere in ~/.openclaw/openclaw.json:

> openclaw agents list --json 2>&1 | Out-String
[
  { "id": "main", "model": "openai/gpt-5.4-mini", ... },
  ...
]
node.exe : Ollama could not be reached at http://127.0.0.1:11434.

> openclaw sessions --json 2>&1 | Out-String
{ "path": "...", "count": 69, "sessions": [...] }
node.exe : Ollama could not be reached at http://127.0.0.1:11434.

> openclaw models list --json 2>&1 | Out-String
node.exe : Ollama could not be reached at http://127.0.0.1:11434.
{ "count": 7, "models": [...] }

models list --json returns 7 models, none of them Ollama: openai/gpt-5.4-mini, openai/gpt-4o, vllm/nvidia/Qwen3-30B-A3B-NVFP4, openai/gpt-5.4, openai/gpt-4o-mini, openai/o4-mini, nvidia/Qwen3-30B-A3B-NVFP4.

Expected behavior

The Ollama provider probe should run only when Ollama is referenced by the active agent's model chain or auth profiles. If a probe must run for catalog refresh, its unreachable-host message should be at debug level, not warn/stderr.

Impact

We ship a desktop frontend (Crystal: https://github.com/jvpflum/Crystal) on top of OpenClaw and currently filter this string in two places to avoid leaking the warning into user-facing chat output and into gateway-log views. Every JSON consumer needs the same workaround. A literal-string search for could not be reached at http://127.0.0.1:11434 will hit other downstream tools too.

Suggested fixes (any one is sufficient)

  1. Demote unconfigured probes to debug. If no ollama/* reference is found in the resolved model chain, suppress the warning entirely.
  2. Honor OPENCLAW_LOG_LEVEL. Currently the warning prints regardless of level.
  3. Probe lazily. Only probe Ollama on the first dispatch that targets it, not on every CLI startup.

Happy to send a PR for option 1 if there's appetite.

extent analysis

TL;DR

The most likely fix is to demote unconfigured probes to debug level or honor the OPENCLAW_LOG_LEVEL environment variable to suppress the unnecessary warning.

Guidance

  • Verify that the OPENCLAW_LOG_LEVEL environment variable is set to a level that should suppress the warning, such as debug or info, and check if the warning still appears.
  • Check the OpenClaw configuration to ensure that there are no implicit or default references to Ollama that could be triggering the probe.
  • Consider implementing a lazy probing mechanism that only checks for Ollama on the first dispatch that targets it, rather than on every CLI startup.
  • If a fix is not immediately available, a temporary workaround could be to filter the warning string in downstream tools, as is currently being done in the Crystal desktop frontend.

Example

No code snippet is provided as the issue is more related to configuration and logging levels.

Notes

The issue seems to be related to the logging level and the probing mechanism of OpenClaw. The suggested fixes provided in the issue body are a good starting point for resolving the problem.

Recommendation

Apply workaround by demoting unconfigured probes to debug level, as this seems to be the most straightforward solution that can be implemented without requiring significant changes to the OpenClaw codebase.

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

The Ollama provider probe should run only when Ollama is referenced by the active agent's model chain or auth profiles. If a probe must run for catalog refresh, its unreachable-host message should be at debug level, not warn/stderr.

#tokenizer error#prompt formatting#chain error#conversation history#tool integration

Still need to ship something?

×6

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

Back to top recommendations

TRENDING