OpenClaw Tool Calling Not Working: NO_REPLY, "Model Is Not Allowed", SYSTEM_RUN_DENIED

When OpenClaw won’t call a tool — you get NO_REPLY, “Model is not allowed”, or SYSTEM_RUN_DENIED: approval required — the cause is almost always one of three things: the model name isn’t in your provider list, the action needs approval, or the model itself is too small or buggy to emit a valid structured tool call. Start with openclaw models status, confirm the model name and provider format, and if you’re on a sub-7B local model, switch to one that tool-calls reliably. That fixes the vast majority of cases.

These three errors look unrelated, but they cluster around the same workflow: the agent decides it needs to run a tool (shell command, file edit, skill, MCP call), and something between “decide” and “execute” goes wrong. Below is how to tell which failure you’re hitting and exactly what to do about each.

First: run the diagnostic

Don’t guess. Two commands tell you which of the three problems you have:

# Which models are loaded, reachable, and correctly named?
openclaw models status

# What model is the agent actually configured to use?
openclaw config get agents.defaults.models

If openclaw models status shows your model as unavailable or the name doesn’t match what’s in your config, you have a configuration problem (NO_REPLY or “Model is not allowed”). If the model is healthy and correctly named but tool calls still fail or come back empty, you have a model capability problem. And if the agent clearly tried to act but was blocked, you have an approval problem (SYSTEM_RUN_DENIED). Each is covered below.

”Model is not allowed” — the name isn’t in the provider list

Model ... is not allowed

This is the easiest one. OpenClaw was asked to use a model that isn’t in the configured provider list, so it refuses before doing anything. The cause is almost always a typo or a wrong provider/model format in the config.

The model id must include the provider prefix. A local Ollama model looks like ollama/qwen3:30b — not qwen3:30b, not qwen3-30b, not ollama:qwen3:30b. Check what’s actually set and what’s actually available:

# What the agent is configured to use
openclaw config get agents.defaults.models

# What's actually loaded and reachable
openclaw models status

If the configured name doesn’t appear verbatim in openclaw models status, fix it:

# Set the chat model to a name that exactly matches the provider list
openclaw config set agents.defaults.models.chat "ollama/qwen3:30b"

# Restart so the gateway picks up the change
openclaw gateway restart

After the restart, re-run openclaw models status to confirm the model reports healthy. Then try the action that failed.

SYSTEM_RUN_DENIED — this is a feature, not a bug

SYSTEM_RUN_DENIED: approval required

If you see this, your tool calling is working perfectly. The agent decided to run a tool, OpenClaw recognized that the action falls under your approval policy, and it paused to ask you first. This is the guardrail doing its job — it’s what stops a model from running rm -rf or pushing to main without a human in the loop.

You have two options:

• Approve the action. When OpenClaw surfaces the approval prompt, confirm it and the tool runs. The agent continues from there.
• Adjust the approval policy if a whole class of safe commands is being gated and slowing you down. Be conservative here: the entire point of the policy is to keep an autonomous agent from doing damage unsupervised. Loosen it deliberately, not reflexively.

The mistake people make is reading SYSTEM_RUN_DENIED as “tools are broken” and tearing apart their model config. They’re not broken. Check the logs to see exactly what the agent wanted to run before you decide whether to approve it:

openclaw logs --follow

NO_REPLY — usually the model can’t produce a valid tool call

NO_REPLY

This is the one that sends people in circles. NO_REPLY means the model produced nothing OpenClaw could act on for that turn. When the agent needs to call a tool, the model has to emit a precise, schema-valid structured tool call — essentially well-formed JSON naming the tool and its arguments. If the model emits something malformed, partial, or wrapped in prose, OpenClaw can’t parse it, there’s no action to take, and you get an empty reply.

First, rule out the simple causes — these overlap with the blank-response checklist in the troubleshooting guide:

# Is the gateway up?
openclaw gateway status

# Is the model reachable?
openclaw models status

# Watch what actually happens on the failing turn
openclaw logs --follow

If the gateway is healthy and the model is reachable but tool calls still come back empty, you’ve almost certainly hit a model capability problem. That’s the next section, and it’s the real fix for most NO_REPLY reports.

The root cause behind most tool failures: the model

Here’s the thing the model-leaderboards won’t tell you: a model’s benchmark score has almost nothing to do with whether it tool-calls reliably. A model can ace reasoning benchmarks and still be unable to consistently emit a valid tool call. That’s why this site filters every recommendation through a tool-calling reliability test, not benchmark scores.

Two patterns cause the overwhelming majority of NO_REPLY-on-tool-use reports:

1. The model is too small. Models under roughly 7B parameters struggle badly with structured tool calling. They’ll happily chat, but ask them to produce schema-valid JSON for a tool call on every turn and they drop arguments, malform the structure, or narrate the call in prose instead of emitting it. OpenClaw can’t parse any of that, so you get NO_REPLY. This is the single most common reason “tools don’t work” on a local setup.

2. A specific model + runtime combo has a regression. Tool calling depends on both the model and the runtime’s tool-call handling. Some pairings have known bugs. The clearest documented example is the Qwen 3.5 27B Ollama tool-calling bug (GitHub issue #14493) — a model that’s otherwise capable, but with broken tool calls in that specific runtime. The fix isn’t a bigger model; it’s a different pairing.

What to actually run

Bigger and better-supported models tool-call far more reliably. For production OpenClaw use, gpt-oss 20B has been the most consistent local model for tool calling. If you have the RAM headroom, the larger gpt-oss 120B is even more dependable. Among the Qwen family, prefer the current well-supported releases (Qwen 3.6 27B) over the regression-affected 3.5 27B + Ollama combo.

After switching models, set it as the default and restart so the gateway picks it up:

openclaw config set agents.defaults.models.chat "ollama/qwen3:30b"
openclaw gateway restart
openclaw models status

(Replace the model id with whichever reliable model you’re running — the format is the load-bearing part.)

The reason hardware matters here: the most reliable tool-calling models are the larger ones, and they need RAM to run without thrashing. Trying to force a tiny model to behave reliably on a memory-starved machine is the long way around. If you’re sizing a box for this, see the best local LLM by RAM hub to match a tool-calling-capable model to your available memory.

A clean checklist

When tool calling breaks, work this order:

1. openclaw models status — is the model loaded, reachable, and named correctly?
2. openclaw config get agents.defaults.models — does the configured name match, in provider/model format?
3. If you see SYSTEM_RUN_DENIED — that’s approval, not a bug. Approve it or adjust policy.
4. If you see NO_REPLY and the config is clean — your model is the problem. Move to a proven tool-caller (gpt-oss 20B).
5. openclaw gateway restart after any config change, then re-test.
6. Still stuck? openclaw logs --follow shows you exactly what the agent attempted on the failing turn.

Need help?

If you’ve worked the checklist and tool calling still won’t behave — or you want a second pair of eyes on your model and approval-policy setup — we offer 1:1 OpenClaw help for remote setup, troubleshooting, and training.