OpenClaw Setup Errors and Fixes: The Index (July 2026)

Bottom Line (July 2026)

• Most “OpenClaw is broken” reports are one of nine failures. They are indexed below, each with symptom, cause, fix.
• The error message is usually not the error. Ollama missing from the picker is a networking problem. SearXNG failing looks like a model problem. Breaking after 10 prompts is a context problem.
• Test the dependency directly before you touch OpenClaw config. curl the Ollama endpoint, docker ps the SearXNG container, benchmark the model against the runtime. Half of these resolve at that step.
• Two failures are silent — SearXNG search and local tool calling both fail without an error, so the agent loops or lies instead of stopping.
• Back up your config before updating. “The last update broke everything” is a recurring pattern, and the only real defense is a snapshot plus a pinned version.

1. Ollama Not Showing in the Model Picker

Symptom: Ollama is installed and running, models are pulled, but OpenClaw’s model list is empty or does not include your local models.

Cause: Community-verified — this is a connectivity problem, not a model problem. Three variants, in order of frequency:

1. The Ollama service is not actually running (the CLI works because it starts a transient server; the persistent API is not up).
2. The endpoint configured in OpenClaw points at the wrong host or port.
3. OpenClaw is running in a container and localhost resolves to the container, not your machine.

Fix: Test the API directly before touching OpenClaw:

curl http://localhost:11434/api/tags

If that returns nothing, Ollama’s API is not up — start it with ollama serve. If it returns your models but OpenClaw still shows none, the endpoint in OpenClaw’s config is wrong.

If OpenClaw runs in Docker, localhost inside the container is the container. Point it at the host instead:

http://host.docker.internal:11434

On Linux, host.docker.internal needs --add-host=host.docker.internal:host-gateway on the container, or you use the host’s LAN IP.

Also check that Ollama is bound to something the container can reach. Bound only to 127.0.0.1, it is invisible from outside the host’s own loopback — set OLLAMA_HOST=0.0.0.0:11434 before ollama serve.

Related: OpenClaw defaults to Claude, not Ollama covers the case where local models are visible but never actually get used.

2. SearXNG Search Silently Failing

Symptom: The agent’s web searches return nothing useful. There is no error. The agent retries, rephrases, loops, and eventually answers from memory or gives up. It reads like the model is dumb.

Cause: Community-verified — the SearXNG container is usually not running, or is running on a different port than OpenClaw is configured for. The reason it costs people hours is the silence: a failed search comes back as an empty result, not an exception, so nothing in the OpenClaw logs points at SearXNG. One reported case burned roughly four hours of AI-assisted troubleshooting before checking whether the container was up.

Fix: Check the container and the port before anything else.

docker ps | grep -i searxng

If it is not listed, that is your answer. If it is listed, hit the search endpoint directly and confirm you get JSON back:

curl "http://localhost:8080/search?q=test&format=json"

Two follow-ups if that fails while the container is up:

• SearXNG ships with the JSON output format disabled in some configurations. Enable json under search.formats in settings.yml — without it, the endpoint returns HTML and the agent gets nothing it can parse.
• If OpenClaw is containerized, the same host.docker.internal rule from failure 1 applies to the SearXNG URL.

Diagnostic rule: any time an agent loops on a task that needs external data, test the data source by hand before you blame the model.

3. Breaks After ~10 Prompts / Spawns a New Session

Symptom: Everything works for a while, then around the tenth exchange the agent forgets what it was doing, drops earlier context, or starts a fresh session.

Cause: The context window is full. This is arithmetic, not a bug. OpenClaw’s system prompt plus tool definitions is thousands of tokens before your first message. Add file contents the agent has read and a handful of turns, and a 4–8K window is gone by prompt ten.

Fix: Raise the served context length, and cap it at what your VRAM can actually hold as KV cache.

OLLAMA_CONTEXT_LENGTH=32768 ollama serve

The catch: if the KV cache does not fit in VRAM it spills to system RAM and generation crawls. So this is a two-sided constraint — too small and the session breaks, too large and it grinds. Find the largest window that stays resident on your card.

Full treatment in context window traps for local agents. If you are sizing a card around this, Laguna XS 2.1 on 24GB vs 32GB works the KV-cache math for a specific model.

4. Model Responds in Chat but Never Executes Tools

Symptom: You ask the agent to edit a file, run a command, or search the web. It replies confidently that it did. Nothing happened. No files changed, no command ran.

Cause: The model is not emitting tool calls — it is describing tool calls in prose. Many local models handle chat well and tool-call format badly, especially at aggressive quantization. There is no error because, from OpenClaw’s side, the model just returned text.

Fix: This is a model-selection problem, not a config problem. Verify the model actually supports and reliably emits function calling in your runtime, and swap it if not. Quantization below Q4 degrades tool-call formatting noticeably before it degrades conversational quality, which is why the model still “sounds” fine.

Full write-up: when your local model says it did it but didn’t and local LLM tool calling reliability. If tool calls fail even on a known-good model, OpenClaw tool calling not working covers the config side.

5. Endless "thinking…" With No Reply

Symptom: You send a message. The agent shows “thinking” and stays there. Minutes pass. One reported case waited 15+ minutes for a reply to a single “hi.”

Cause: The model is too large or too slow for the machine and is still in prefill. This trips people up because the same model answers instantly in a plain chat UI — the difference is that OpenClaw prepends a large agent system prompt and full tool definitions to every request. Your first “hi” is thousands of tokens of prefill before the model generates a single output token. On a machine where the model is partially offloaded to CPU or spilling to swap, that takes minutes.

Fix: Benchmark the model against the runtime directly, not through OpenClaw, so you separate model speed from OpenClaw config:

ollama run <model> --verbose

Look at the prompt-eval rate, not just generation tok/sec — prefill is what is killing you here. Then:

• Drop to a smaller model or a lower quant so the whole thing sits in VRAM.
• Confirm nothing is offloaded to CPU. Partial offload is the single biggest cause of minute-scale first-token latency.

More on this failure mode: why local LLMs are slow even when they fit and usable tokens per second by task.

6. Install Loops — "Tried 15 Times, Only Errors"

Symptom: The install fails, you retry with a tweak, it fails differently, and after a dozen attempts the environment is a mix of partial installs and half-edited config.

Cause: Varies by machine — this one is genuinely a diagnostic, not a known single fix. What makes it a loop rather than a single failure is that each retry runs against the residue of the last one, so you are never testing a clean state.

Fix: Stop retrying and do a clean install once, in order:

1. Check Node version against what the current OpenClaw release requires. A too-old or too-new major version is the most common single cause, and the error it produces rarely names the version.
2. Check Docker is installed and the daemon is actually running, if you are using the container path.
3. Check permissions. Installs that need sudo for a global package, or a config directory owned by root from an earlier sudo attempt, fail in ways that look unrelated. If you ever ran the installer with sudo, check ownership of the config directory.
4. Move the old config directory aside — rename it rather than deleting it — so the install writes a fresh one instead of merging into a broken schema.
5. Then install once and read the first error in full. Do not retry with a change until you have read it.

Step 4 is what breaks the loop most often. Partial config from failed attempts is what makes attempt 15 fail differently than attempt 1.

Walkthroughs: install OpenClaw, OpenClaw Docker setup, and OpenClaw troubleshooting. Windows-specific: command not recognized and Windows setup.

7. An Update Broke a Working Setup

Symptom: It worked yesterday. You updated. Now models are missing, tools fail, or it will not start. “Last update broke all my setup” is a recurring community refrain, not a one-off.

Cause: Config schema and defaults change between releases. A config that was valid is now partly ignored or rejected, and the failure surfaces somewhere unrelated to the setting that moved.

Fix: This one is procedural. There is no command that undoes it after the fact — the fix is what you do before.

• Snapshot the config directory before every update. A copy of the directory is enough. This is the single highest-value habit here, because it turns a debugging session into a restore.
• Pin the version you know works rather than tracking latest, if the setup is doing real work.
• Read the release notes for config changes before upgrading, not after something breaks.
• Update one thing at a time. OpenClaw, the model runtime, and the models themselves are three separate upgrade paths. Moving all three at once makes attribution impossible.

If you are already broken: restore the pinned version first to confirm the update is the cause, then upgrade again deliberately with the release notes open. Detail in the OpenClaw update survival guide.

8. Runaway Token Burn / Agent Looping on Failures

Symptom: A task that should be cheap costs many multiples of what you expected. Reviewing the transcript, the agent retried the same failing action repeatedly.

Cause: A silent dependency failure (see failures 2 and 4) plus no loop guardrail. The agent gets an empty or malformed result, decides to try again, and every retry is a full-context request. Cost scales with retries, and retries are unbounded by default.

Fix: Two layers — stop the loop and cap the damage.

• Fix the underlying silent failure first. Runaway loops are nearly always downstream of a tool that fails without erroring. Find it before tuning budgets.
• Set a spend cap so a loop cannot run overnight. See OpenClaw spending limits.
• Route auxiliary work to a cheaper model. Summarization, file triage, and search result filtering do not need your top model. Hybrid routing: local vs frontier covers the split.
• Watch the actual numbers, not the vibes. The real token cost of a Hermes agent shows what agent loops actually consume, and cut your OpenClaw bill with 5 settings is the fastest set of levers.

9. Anthropic Subscription Auth Stopped Working

Symptom: OpenClaw was authenticating against a Claude subscription and stopped — auth errors, refused requests, or the integration disabled outright.

Cause: Not a bug in your setup. Provider terms govern whether a consumer subscription may be driven by third-party agent harnesses, and enforcement of those terms has changed. When it changes, working setups stop working with no local cause to find.

Fix: Understand which side of the terms your setup is on before you spend time debugging it. Read the rules for using Claude and ChatGPT subscriptions in an agent harness first — if the answer is that the path is closed, no config change reopens it, and the move is an API key or a local model.

Background on how this played out: Anthropic’s OpenClaw cutoff and Anthropic banning OpenClaw integrations.

The 60-Second Triage

Before opening any config file, run these in order. They resolve or localize most of the above:

curl http://localhost:11434/api/tags        # Ollama API up? models listed?
docker ps                                   # SearXNG and other containers running?
ollama run <model> --verbose                # prefill and generation speed, outside OpenClaw
node --version                              # matches what the release requires?

If a dependency fails one of these, fix that. Do not touch OpenClaw config until all four are clean — most “OpenClaw errors” are dependency errors wearing an OpenClaw error message.

Related Guides

• OpenClaw troubleshooting — the broader problem index
• Context window traps for local agents — why sessions break early
• When your local model says it did it but didn’t — silent tool-call failure
• Why local LLMs are slow even when they fit — the stuck-thinking cause
• OpenClaw update survival guide — surviving releases
• The real token cost of a Hermes agent — what loops actually cost
• OpenClaw out of memory and Docker missing config — two specific failures with their own pages