#Bot can't use tools like exec or write or read. "tool not found"

1 messages · Page 1 of 1 (latest)

cinder girderBOT
#

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

gusty heraldBOT
#

That symptom almost always means the agent isn’t being given those tools in its tool schema (tool policy / profiles / allowlists), so when it tries to call exec / read / write the gateway rejects it as “tool not available / not found”.

1) Quick checks (paste the output)

  1. openclaw --version
  2. In the chat where it fails, run: /context detail
    (this prints the effective tool list + counts; super useful for spotting “only messaging tools” etc.)

2) Most common root cause: restrictive tool profile / allowlist

Check your openclaw.json for any of these:

  • tools.profile: "minimal" → only session_status
  • tools.profile: "messaging" → no filesystem/runtime tools
  • tools.allow: [...] with only a few entries → turns into a hard allowlist (everything else disappears)

To allow those tools, you typically want either:

Option A: easiest

# 
{
  tools: { profile: "full" }
}

Option B: still restrictive but includes what you asked for

{
  tools: {
    profile: "coding",
    allow: ["group:fs", "group:runtime"] // fs=read/write/edit, runtime=exec/bash/process
  }
}

Docs: https://docs.openclaw.ai/tools (see tool profiles + group:fs / group:runtime)

#

3) If it only happens in Discord channels/threads (but works in DMs)

You may be running with sandbox mode "non-main" and a stricter sandbox tool allowlist. Run:

  • openclaw sandbox explain

And check:

  • tools.sandbox.tools.allow/deny
  • any per-agent overrides under agents.list[].tools.*

Docs: https://docs.openclaw.ai/gateway/sandbox-vs-tool-policy-vs-elevated

If you paste:

  • your tools: { ... } section (and any agents.list[].tools overrides)
  • the exact “tool not found” line
    …I can point to the exact key that’s blocking it.
#

Run these on the machine where the Gateway is running:

# 1) Make sure the base tool profile isn’t restricting you (messaging/minimal will hide exec/read/write)
openclaw config set tools.profile full

# 2) If you previously set a tool allowlist, REMOVE it (non-empty tools.allow = “only these tools”)
openclaw config unset tools.allow

# 3) Validate + restart
openclaw config validate
openclaw gateway restart

If it still says Tool not available: exec/read/write, then you’ve likely got a per-agent restriction too. Paste this output and I’ll tell you the exact agents.list[...] path to change:

# 
openclaw config get tools
openclaw config get agents.list
#

Config path not found: agents.list means you’re on a config schema where that path doesn’t exist (usually: older OpenClaw, or you’re editing a different config than the running gateway).

Run these and paste the output:

openclaw --version
openclaw config file
openclaw config get agents
openclaw config get agent

One of agents or agent should exist on your build — then we’ll use that path for the fix.

Also: after openclaw config set tools.profile full you must restart the gateway (otherwise the running process still has the old tool schema):

# 
openclaw gateway restart

If you paste the four command outputs above, I’ll reply with the exact openclaw config set ... line for your schema.

#

Good, you’re on 2026.3.8 and your config file is:

  • ~/.openclaw/openclaw.json

Also: openclaw config get agents showing only defaults is normal — you haven’t configured any per-agent overrides (agents.list[...]), so config get agents.list will error until you actually set it.

Now, if you still get “tool not found” for exec/read/write even with tools.profile: "full", the two most common remaining causes are:

A) You’re using Ollama in OpenAI-compatible mode (/v1) → tool calling breaks

Check your Ollama provider config:

openclaw config get models.providers.ollama

If you see baseUrl ending in /v1 or api: "openai-completions", switch to native Ollama API:

# 
openclaw config set models.providers.ollama.api "ollama"
openclaw config set models.providers.ollama.baseUrl "http://127.0.0.1:11434"   # NO /v1 (adjust host if remote)
openclaw gateway restart

(Ref: https://docs.openclaw.ai/providers/ollama — the /v1 warning is explicit.)

B) Sandbox tool policy is stripping tools in Discord threads/channels

Run:

openclaw sandbox explain

If it says tools are blocked in sandbox, quickest “just make it work” fix is to disable sandboxing:

# 
openclaw config set agents.defaults.sandbox.mode "off"
openclaw gateway restart

—or keep sandboxing but allow fs/runtime tools inside it:

openclaw config set tools.sandbox.tools.allow '["group:fs","group:runtime"]' --strict-json
openclaw gateway restart

If you paste the output of openclaw config get models.providers.ollama and openclaw sandbox explain, I can tell you which of A/B is the real culprit.

#

Your Ollama provider config looks fine (native api: "ollama", no /v1). So this isn’t the “Ollama /v1 breaks tools” problem.

At this point, the most likely cause is: your Discord thread is running as a “non‑main” session and is sandboxed / sandbox-tool-restricted, so exec/read/write simply aren’t in the tool set for that session → the gateway reports them as not available (“tool not found”).

Confirm (one command)

openclaw sandbox explain

Fix (pick one)

Option 1: Disable sandboxing entirely (fastest)

openclaw config set agents.defaults.sandbox.mode off
openclaw gateway restart