openclaw - 💡(How to fix) Fix Unexpected local Ollama probing to 127.0.0.1:11434 on 2026.3.28 when Ollama is not explicitly configured [1 participants]

Summary

After upgrading to OpenClaw 2026.3.28, I started seeing repeated local connection attempts from openclaw-gateway (node) to 127.0.0.1:11434, even though I was not intentionally using Ollama and did not have an explicit Ollama provider configured in openclaw.json.

This behavior was visible both in logs and in a local network-monitoring app, which flagged the node process for abnormally frequent requests and temporarily blocked/suspended some of its connections.

Disabling the bundled ollama provider stopped the behavior.

Environment

• OpenClaw: 2026.3.28
• OS: macOS (arm64)
• Node: v22.22.0
• Gateway mode: local
• Primary model: openrouter/openai/gpt-5.4

What I expected

If Ollama is not explicitly configured or intentionally enabled, OpenClaw should not probe the default local Ollama endpoint at 127.0.0.1:11434.

At minimum, if this is expected bootstrap/discovery behavior, it should be clearly gated and explained.

What actually happened

A local network monitor reported that the node process used by OpenClaw (openclaw-gateway) was making requests at an unusually high rate.

From the monitor:

• it repeatedly flagged the node process (/opt/homebrew/Cellar/node@22/22.22.0/bin/node)
• it reported very high request volume
• in one alert it said Surge processed 617 requests within one second
• the monitor temporarily suspended requests from the relevant node PID
• this all happened around the same time the OpenClaw-side symptoms were observed

This was not just a single harmless startup probe; the request volume was high enough to trigger the local network monitor’s abnormal-traffic protection.

Separately, investigation showed the destination involved was:

• 127.0.0.1:11434

Since Ollama was not running locally, this produced repeated failed local connection attempts / noise.

Related observation

Around roughly the same time, I also saw a provider-bootstrap-related log message such as:

{"subsystem":"agents/model-providers"} [xai-auth] bootstrap config fallback: no config-backed key found

I am not claiming this log is the direct cause of the Ollama probing.
I’m only noting that the timing was roughly aligned, which suggests a provider bootstrap / discovery pass may have been happening at that time.

Relevant config context

My active config was OpenRouter-based, not Ollama-based.

Relevant points:

• primary model was openrouter/openai/gpt-5.4
• there was no intentional active Ollama usage
• there was no explicit models.providers.ollama entry in the current config

I had experimented with a different local-model setup in the past, but it was not successfully used, was later removed from config, and I had not seen this 127.0.0.1:11434 probing behavior in recent earlier versions before 2026.3.28.

Why this seems surprising

The current docs describe Ollama auto-discovery as opt-in behavior (for example via OLLAMA_API_KEY / auth profile and no explicit provider entry).

In my case, from the visible active config and actual usage, Ollama was not intentionally in use, yet the bundled provider still appeared to probe the default local endpoint.

So this looks like one of:

1. a bug in provider bootstrap/discovery,
2. undocumented implicit opt-in behavior,
3. or a docs/behavior mismatch.

Workaround / mitigation

I added:

{
  "plugins": {
    "deny": ["ollama"]
  }
}

After restarting the gateway, the local probing to 127.0.0.1:11434 stopped.

Suggested improvement

One or more of the following would help:

• do not probe local Ollama unless it is explicitly enabled,
• add a clear config switch controlling bundled local-provider discovery,
• log the exact reason Ollama discovery is being attempted,
• or suppress repeated failed local discovery attempts when the target is unavailable.

Notes

I have not fully ruled out the possibility of some inherited environment-level opt-in (for example an old env var), but from the active config and real usage this did not appear to be an intentional Ollama setup.

Even if environment-based opt-in is involved, the current behavior is still fairly opaque because the gateway probes a local port unexpectedly and can generate enough failed requests to trigger local network-monitoring alerts.