OpenClaw can't reach Ollama running on another device

[undone pine]

Hey everyone,

hope you're doing well. I'm trying to create a setup in which OpenClaw runs on my Mac Mini using local Ollama models that run on my MacBook Pro but I can't get OpenClaw to connect to Ollama via WIFI.

On my Mac Mini, when I enter the address of Ollama in my browser it says Ollama is running and I can reach it just fine using curl. It also responds to my prompts.

But this is what it looks like when I run openclaw onboard and select the corresponding options:

◇  Model/auth provider

More…

◇  Model/auth provider

Ollama

◇  Ollama mode

Local only

◇  Ollama base URL

http://x:11434

◇  **Ollama** 

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

Download it at https://ollama.com/download

Start Ollama and re-run setup.

What am I missing here? How can I fix my setup?

[dusty lion]

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

[wet swift]

First thing: what does openclaw --version show? Version mismatches can make model setup weird.

For this specific Ollama path, OpenClaw’s Ollama onboarding does not just check that http://host:11434/ says “Ollama is running”. It calls the native Ollama API, especially:

curl -v http://x:11434/api/tags

Run that from the Mac Mini terminal, using the exact same hostname/IP you typed into openclaw onboard. If that fails or hangs, fix Ollama/LAN first. If it works, paste the HTTP status + first bit of output.

A few likely fixes:

1. Use the native Ollama base URL only:

http://<macbook-ip-or-hostname>:11434

No /v1. OpenClaw’s docs warn that /v1 uses Ollama’s OpenAI-compatible path and can break tool calling.

[wet swift]

2. On the MacBook Pro running Ollama, make sure Ollama is actually bound for LAN access, not just localhost. For shell-launched Ollama this usually means starting it with:

OLLAMA_HOST=0.0.0.0:11434 ollama serve

Then retry from the Mac Mini:

curl http://<macbook-ip>:11434/api/tags

3. Prefer the MacBook’s LAN IP over a short hostname while debugging. mDNS/DNS can differ between browser, shell, and service contexts.

4. If /api/tags works but onboarding still says unreachable, try the non-interactive path to remove picker ambiguity:

openclaw onboard --non-interactive \
  --auth-choice ollama \
  --custom-base-url "http://<macbook-ip>:11434" \

[wet swift]

  --accept-risk

Docs: https://docs.openclaw.ai/providers/ollama

One more note: “Local only” is fine for a self-hosted Ollama server on another machine; the important part is that OpenClaw can reach /api/tags on the native Ollama URL. 🦞

[undone pine]

curl http://<macbook-ip>:11434/api/tags

This works just fine. i get a response from my macbook on my mac mini.

[wet swift]

Good, that narrows it down: the network path is fine. Next I’d test whether this is the interactive wizard path, hostname resolution, or your OpenClaw version.

Please run:

openclaw --version
openclaw onboard --non-interactive \
  --auth-choice ollama \
  --custom-base-url "http://<macbook-ip>:11434" \
  --accept-risk

Use the numeric MacBook IP there, not the hostname, just for this test.

If that still says unreachable, grab the smallest useful log snippet right after it fails:

[wet swift]

openclaw status --all
openclaw logs --follow

Also check that the /api/tags response actually contains a models array, not just the root “Ollama is running” text:

curl -s http://<macbook-ip>:11434/api/tags

If non-interactive works, then your actual setup is fine and the issue is likely in the interactive onboarding path or how the hostname was entered/resolved. Docs for the Ollama provider are here: https://docs.openclaw.ai/providers/ollama

[undone pine]

niklas@Niklass-Mac-mini ~ % openclaw --version
openclaw onboard --non-interactive
--auth-choice ollama
--custom-base-url "x" \
--accept-risk
OpenClaw 2026.5.27 (27ae826)
│
◇

🦞 OpenClaw 2026.5.27 (27ae826) — Welcome to the command line: where dreams compile and confidence segfaults.

Ollama could not be reached at x.
Download it at https://ollama.com/download

this command works just fine

niklas@Niklass-Mac-mini ~ % curl -s x/api/tags

{"models":

[wet swift]

I think the missing piece is the URL format.

curl x/api/tags can be forgiving and infer HTTP, but OpenClaw/Node fetch needs an absolute URL with the scheme. Use:

openclaw onboard --non-interactive \
  --auth-choice ollama \
  --custom-base-url "http://<macbook-ip>:11434" \
  --accept-risk

Two small gotchas:

• Include http://
• Make sure there is no space after the backslash at the end of each continued line

So if your shorthand was literally x, OpenClaw will try to reach x, not http://x:11434.

[wet swift]

After that, check:

openclaw models list --provider ollama

If it still fails with the full http://... URL while curl -s http://<macbook-ip>:11434/api/tags works, that smells like a 2026.5.27 onboarding bug and is worth filing with the version + exact command/output: https://github.com/openclaw/openclaw/issues

[undone pine]

niklas@Niklass-Mac-mini ~ % openclaw models list --provider ollama

🦞 OpenClaw 2026.5.27 (27ae826) — I've survived more breaking changes than your last three relationships.

Model Input Ctx Local Auth Tags
ollama/gemma4:latest text 125k no yes default,configured
niklas@Niklass-Mac-mini ~ %

I have this from earlier but it can be reached. "Something went wrong while processing your request"

[wet swift]

That output is useful: OpenClaw can see the Ollama model now. So this is no longer the original “can’t reach Ollama” problem. The generic “Something went wrong while processing your request” is the chat/agent failure wrapper, so we need the underlying gateway log line.

Try this sequence on the Mac Mini:

openclaw models set ollama/gemma4:latest
openclaw gateway restart
openclaw models status --probe

Then start a fresh chat/session and try again. If you’re testing from a chat channel, use /new first so you’re not reusing a failed session.

If it still fails, please paste the relevant part from:

openclaw status --all

[wet swift]

openclaw logs --follow

Also worth checking Ollama itself can actually run that exact model from the Mac Mini:

curl -s http://<macbook-ip>:11434/api/chat \
  -H 'Content-Type: application/json' \
  -d '{"model":"gemma4:latest","messages":[{"role":"user","content":"say ok"}],"stream":false}'

One thing I notice: the list shows Local no. That may just mean “not local to the Mac Mini,” because the Ollama host is remote, but the probe/logs will tell us whether runtime requests are actually reaching the MacBook.

Docs: https://docs.openclaw.ai/providers/ollama

[undone pine]

I already told you curl works just fine. OpenClaw is the issue here

[wet swift]

You’re right, sorry. I over-indexed on re-checking Ollama. Given models list --provider ollama sees ollama/gemma4:latest, this is very likely OpenClaw’s runtime path failing after discovery.

At this point the useful data is not more curl, it’s the exact gateway error behind the generic wrapper:

openclaw models set ollama/gemma4:latest
openclaw gateway restart
openclaw models status --probe
openclaw logs --follow

Then send one test message and paste the log lines from that moment. The generic “Something went wrong…” text is intentionally hiding the real exception from the chat UI, so the log is the thing that will show whether this is model id formatting, native Ollama transport, tool calling, SSRF guard, or something else.

Since you’re on 2026.5.27 (27ae826), if the logs show an OpenClaw stack/error, this is worth filing here with:

• version
• Ollama remote base URL shape, redacted if needed
• openclaw models list --provider ollama output

[wet swift]

• the failing log snippet

https://github.com/openclaw/openclaw/issues