Tools always failing | Friends of the Crustacean 🦞🤝 | Page 1

clever pathBOT Mar 2, 2026, 12:47 PM

#

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

dusk coralBOT Mar 2, 2026, 12:49 PM

#

This is almost always one of these three things: tool policy (allow/deny), sandboxing, or exec approvals.

1) First: grab the exact error + your version

Please paste:

openclaw --version
the exact “tool failed” message you see (copy/paste)

If you can also run one more, it usually makes the cause obvious:

openclaw sandbox explain (or openclaw sandbox explain --json)

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

2) Common cause: tools are blocked by an allowlist

If your config has tools.allow set (non-empty), then ONLY those tools are permitted. So if you forgot to include filesystem/runtime tools, you’ll see failures for “write/edit/shell”.

#

What you typically want in tools.allow is at least:

group:fs → read, write, edit, apply_patch
group:runtime → exec/bash/process (this is usually what people mean by “shell”)

Also: make sure you’re not using old/wrong entries like discord.message / web.fetch etc — allowlists must contain real tool names or group:* entries.

3) Common cause: you’re sandboxed (often surprises people in group chats)

If agents.defaults.sandbox.mode is "non-main", then group/channel sessions are sandboxed and may have restricted filesystem access (so write/edit fails).

sandbox explain will tell you if you’re sandboxed and whether workspace is ro vs rw.

4) If “shell/exec” specifically fails: approvals / allowlist

Exec can fail with messages like “approval required” or “allowlist miss”. That’s handled here:

#

https://docs.openclaw.ai/tools/exec-approvals

If you paste openclaw --version + the exact tool error + openclaw sandbox explain, I can tell you which of the above it is and what config key to change.

gleaming scroll Mar 2, 2026, 1:17 PM

#

the version is openclaw 2026.2.26 and this is my sanbox explain : agentId: main
sessionKey: agent:main:main
mainSessionKey: agent:main:main
runtime: direct
mode: off scope: agent perSession: false
workspaceAccess: none workspaceRoot: /Users/djryan/.openclaw/sandboxes

Sandbox tool policy:
allow (default): exec, process, read, write, edit, apply_patch, image, sessions_list, sessions_history, sessions_send, sessions_spawn, subagents, session_status
deny (default): browser, canvas, nodes, cron, gateway, telegram, whatsapp, discord, irc, googlechat, slack, signal, imessage

Elevated:
enabled: true
channel: (unknown)
allowedByConfig: false

Fix-it:

tools.sandbox.tools.allow
tools.sandbox.tools.deny
agents.list[].tools.sandbox.tools.allow
agents.list[].tools.sandbox.tools.deny
tools.elevated.enabled

#

also its telegram I am using so that would make sense why I cant use it.

dusk coralBOT Mar 2, 2026, 1:19 PM

#

openclaw 2026.2.26 is fine, and your sandbox explain actually says the important bit:

runtime: direct
mode: off

So this is not a sandbox restriction problem (and workspaceAccess: none only matters when sandboxing is on).

That usually leaves 3 real causes:

A) Tool policy/profile is blocking tools (most common)

Even if sandbox would allow them, a global/per-agent tool profile can still remove them.

Please paste these outputs:

openclaw config get tools.profile

#

openclaw config get tools.allow
openclaw config get tools.deny

If you see tools.profile: "minimal" or "messaging", or you have a non-empty tools.allow that doesn’t include filesystem/runtime tools, then write/edit/exec will get blocked.

Docs: https://docs.openclaw.ai/tools

B) Your Gateway service is running with a different config than your CLI

This causes “it looks enabled in my config, but it still fails” headaches.

Run:

openclaw gateway status --deep

#

…and look for a “Config (cli) vs Config (service)” mismatch (different config path/profile/user).

Docs: https://docs.openclaw.ai/gateway/troubleshooting

C) It’s failing at runtime (permissions / workspace / approvals), not policy

For this I need the exact error text you see when it fails (one line is enough). If you can, also grab the log lines around it:

openclaw logs --follow

Then trigger one failure and paste the relevant chunk (it’ll usually say something like TOOL_DENIED, path must be within workspace, EACCES, or SYSTEM_RUN_DENIED: approval required).

If you paste (A) + the exact error line, I can tell you which fix applies and what to change.

#

Telegram being in that “Sandbox tool policy: deny … telegram” list isn’t why your write / edit / “shell” tools fail.

That list is about tools named telegram/discord (plugin/action tools), not about which chat app you’re using.
Your sandbox explain says runtime: direct + mode: off, so sandboxing isn’t the blocker here anyway.

The 2 most common real reasons write/edit/exec “fail”:

1) You’re trying to write/edit outside the agent workspace

OpenClaw’s file tools are workspace-rooted. If you ask it to edit ~/Downloads/... or ~/.openclaw/openclaw.json, it will fail.

Check what your workspace is set to:

openclaw config get agents.defaults.workspace

Docs: https://docs.openclaw.ai/concepts/agent-workspace

#

2) Tool profile / allowlist is restricting tools

Even without sandboxing, tools.profile, tools.allow, tools.deny can block fs/runtime tools.

Please paste:

openclaw config get tools.profile
openclaw config get tools.allow
openclaw config get tools.deny

Docs: https://docs.openclaw.ai/tools

If you paste the exact error line you see when a tool fails (copy/paste from the notice), I can tell you immediately which of the above it is (workspace path issue vs policy block vs exec approvals).

gleaming scroll Mar 2, 2026, 1:23 PM

#

i dont care about all of that how can i just allow it to work and outside the workspace?

dusk coralBOT Mar 2, 2026, 1:25 PM

#

You can’t “turn off workspace” for the write/edit tools. They’re designed to operate relative to the agent workspace (that’s the safety boundary).

The “just make it work” way is:

Option 1 (recommended): move the workspace to where your files are

Run on the machine where the Gateway runs:

openclaw config set agents.defaults.workspace "/Users/djryan"   # or your project folder
openclaw config set tools.profile "coding"                     # enables fs + shell tools
openclaw gateway restart

After that, write/edit will work normally because those paths are now “inside the workspace”.

Docs:

Workspace: https://docs.openclaw.ai/concepts/agent-workspace

#

Tool profiles: https://docs.openclaw.ai/tools

Option 2 (more dangerous): use shell (`exec`) with absolute paths

If you insist on touching arbitrary locations without moving the workspace, the blunt approach is to use exec and absolute paths (e.g. cat /etc/..., sed ... /Users/...). That bypasses the file-tool “stay in workspace” ergonomics and is easy to shoot yourself in the foot with, so I only recommend it if only you can talk to that agent in Telegram.

If you tell me which folder you’re trying to edit (and whether it’s DM or a Telegram group), I can tell you which of the two options is the least painful.

gleaming scroll Mar 2, 2026, 1:31 PM

#

option one gave this error error: too many arguments for 'set'. Expected 2 arguments but got 7.
error: too many arguments for 'set'. Expected 2 arguments but got 8.

dusk coralBOT Mar 2, 2026, 1:31 PM

#

That error means the CLI is seeing extra tokens after the 2 required args (<path> and <value>). Most commonly this happens when you:

paste multiple commands at once into one line, or
include the inline comments (# ...) / extra words from my message, or
your workspace path has spaces and isn’t quoted.

Run these exactly, one line at a time, with nothing extra:

openclaw config set agents.defaults.workspace "/Users/djryan"
openclaw config set tools.profile "coding"
openclaw gateway restart

Then verify:

#

openclaw config get agents.defaults.workspace
openclaw config get tools.profile

If you want the workspace to be a folder with spaces, you must quote it, e.g.:

openclaw config set agents.defaults.workspace "/Users/djryan/My Projects"

If it still complains, paste what your terminal shows for:

openclaw config file
openclaw --version

gleaming scroll Mar 2, 2026, 1:40 PM

#

okay how do i check if the access has been changed?

dusk coralBOT Mar 2, 2026, 1:40 PM

#

Run these to confirm what’s currently active:

openclaw config get agents.defaults.workspace
openclaw config get tools.profile
openclaw config get tools.allow
openclaw config get tools.deny

Then make sure the gateway is actually running with that config (service vs CLI mismatch check):

openclaw gateway status --deep

If you want a “does it actually work now?” quick test:

#

openclaw sandbox explain

and try a trivial file write inside the workspace (wherever agents.defaults.workspace points). If you paste the outputs of the first two commands, I can tell you if the change took effect.

gleaming scroll Mar 2, 2026, 1:42 PM

#

also Config path not found: tools.deny error

dusk coralBOT Mar 2, 2026, 1:43 PM

#

Config path not found: tools.deny is not a failure — it just means you don’t currently have a tools.deny key set in your ~/.openclaw/openclaw.json (it’s optional). Some openclaw config get … calls error if the key is unset.

To check whether your workspace change actually took effect, run:

openclaw config get agents.defaults.workspace
openclaw config get tools.profile
openclaw config file

What you want to see:

agents.defaults.workspace prints the folder you set (e.g. /Users/djryan)
tools.profile is coding (or empty/full; just not minimal/messaging)

If you want to inspect the whole tools block without hitting “path not found”, do:

#

openclaw config get tools

And if you really want tools.deny to exist (so config get tools.deny stops erroring), set it explicitly to an empty list:

openclaw config set tools.deny "[]" --strict-json
openclaw gateway restart

If you paste the output of the first two config get commands, I can tell you if you’re good — and if not, what’s still overriding it (service vs CLI config mismatch is the usual gotcha).

gleaming scroll Mar 2, 2026, 1:51 PM

#

this is what i got {
"profile": "coding",
"web": {
"search": {
"enabled": false
}
},
"agentToAgent": {
"enabled": true
},
"elevated": {
"enabled": true,
"allowFrom": {
"telegram": [
6471395025
]
}
},
"exec": {
"host": "gateway",
"security": "full",
"ask": "off"
}
}

dusk coralBOT Mar 2, 2026, 1:54 PM

#

That config you pasted is already basically “wide open” for tools (profile: "coding" + exec: { host: "gateway", security: "full", ask: "off" }), so if write/edit are still failing specifically when you target paths outside the workspace, it’s usually one of these:

1) You have filesystem “workspace-only” hardening turned on

There’s a config knob that forces read/write/edit/apply_patch to stay inside the workspace:

Check it:

openclaw config get tools.fs
openclaw config get tools.fs.workspaceOnly

If it’s true, turn it off:

openclaw config set tools.fs.workspaceOnly false --strict-json

#

openclaw gateway restart

(If config get tools.fs.workspaceOnly says “path not found”, that just means it’s unset.)

2) You’re actually in a different session that’s sandboxed/restricted (common with Telegram groups)

Earlier you showed sandbox explain for agent:main:main (your main session). Your Telegram chat might be a different session key.

List sessions, find the Telegram one, then explain that one:

openclaw sessions --all-agents --json
# copy the session key that looks like agent:main:telegram:...
openclaw sandbox explain --session "<that-key>"

#

If that Telegram session is sandboxed, absolute paths won’t touch your host filesystem unless you disable sandboxing (or add binds).

If you paste the output of:

openclaw config get tools.fs.workspaceOnly
openclaw sandbox explain --session "<your telegram session key>"

…I can tell you exactly which switch is blocking you.

gleaming scroll Mar 2, 2026, 1:58 PM

#

Config path not found: tools.fs.workspaceOnly, Config path not found: tools.fs got this error for step 1

dusk coralBOT Mar 2, 2026, 2:01 PM

#

Config path not found: tools.fs.workspaceOnly / tools.fs just means you haven’t set those keys. It’s not blocking anything.

Given that, if write/edit are still failing “outside the workspace”, the usual cause is: that Telegram chat is running in a sandboxed (non‑main) session, so filesystem tools are operating inside Docker where your macOS paths don’t exist.

Fast “just make it work on the host” fix

Turn sandboxing off entirely, restart:

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

Now absolute paths on the host should work for file tools.

Confirm what Telegram is actually using

Find your Telegram session key, then explain that session:

#

openclaw sessions --all-agents
openclaw sandbox explain --session "agent:main:telegram:dm:<id>"   # paste the real key from sessions output

If that shows runtime: sandbox, that’s exactly why host paths fail.

Docs (relevant):
https://docs.openclaw.ai/gateway/sandboxing
https://docs.openclaw.ai/gateway/sandbox-vs-tool-policy-vs-elevated

One important note: with exec.security: "full" + ask: "off" (like you set), anyone who can trigger that agent in Telegram can potentially run arbitrary commands on your machine. Make sure your Telegram DM policy/allowlist is tight.

gleaming scroll Mar 2, 2026, 2:02 PM

#

my telegram is set to paring

dusk coralBOT Mar 2, 2026, 2:05 PM

#

Pairing is good (it’s the “only people I approve can DM the bot” mode) — but pairing doesn’t control whether write/edit can touch your Mac filesystem. That’s almost always sandbox + session key.

Here’s the common gotcha on Telegram:

If agents.defaults.sandbox.mode is "non-main" and
your DMs are not using the agent:main:main session (because session.dmScope is set to something like per-channel-peer)

…then your Telegram DM session becomes non‑main → sandboxed, and write/edit will run inside the sandbox filesystem (so host paths “fail”).

Do this (2 commands + restart)

openclaw config get agents.defaults.sandbox.mode
openclaw config get session.dmScope

If you see mode: "non-main" and dmScope is not main, set it back to main:

#

openclaw config set session.dmScope "main"
openclaw gateway restart

Alternative blunt fix (disables sandbox entirely):

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

Also confirm only you are paired (since you enabled full exec)

With your current tools.exec.security: "full" + ask: "off", any paired DM is basically “can run commands on your machine”, so make sure it’s only you:

openclaw pairing list --channel telegram

#

If you paste the output of the two config get commands, I can tell you which exact setting is causing your Telegram chat to be treated as non-main/sandboxed.

gleaming scroll Mar 2, 2026, 2:08 PM

#

I think you tixed the issue thank you

dusk coralBOT Mar 2, 2026, 2:09 PM

#

Nice — if write/edit/exec are working now, then yeah it was almost certainly the session/sandbox/workspace boundary biting you.

If you want to sanity-check it stays fixed after restarts, run once:

openclaw sandbox explain
openclaw gateway status --deep

And if this solved it, please right-click the solution message → Apps → ✅ Mark Solution so Answer Overflow indexes it for the next person.

gleaming scroll Mar 2, 2026, 2:25 PM

#

okay the tools stopped working for some reasn again

dusk coralBOT Mar 2, 2026, 2:25 PM

#

If it “worked and then stopped”, it’s almost always one of these:

you’re now in a different Telegram session key (so different sandbox behavior / different session settings), or
the gateway service is running with a different config than the CLI (service/CLI mismatch), or
sandbox mode / dmScope got changed back (or you restarted and picked up a different profile).

To pinpoint it, I need the exact failure text + 4 command outputs.

1) Paste the exact tool error

Copy/paste the notice you see when a tool fails (one example is enough).

2) Run these and paste output

openclaw --version
openclaw config file
openclaw gateway status --deep

#

openclaw config get agents.defaults.sandbox.mode
openclaw config get session.dmScope

3) Check the session you’re actually using on Telegram

List sessions, find the one that looks like agent:main:telegram:..., then run sandbox explain on that key:

openclaw sessions --all-agents
openclaw sandbox explain --session "agent:main:telegram:dm:<whatever-you-see>"

Once you paste those, I can tell you exactly which knob flipped and what single setting to change.

If you want the blunt “make it work no matter what” switch while we debug:

#

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

(That removes the most common cause: “Telegram session is non-main → sandboxed”.)

gleaming scroll Mar 2, 2026, 2:26 PM

#

im using the openclaw dashboard currently

dusk coralBOT Mar 2, 2026, 2:27 PM

#

If you’re using the OpenClaw dashboard (Control UI), the #1 gotcha is: you might be chatting in a different session key than your “main” session.

When sandboxing is set to non-main, any non-main session (often Telegram DMs / group sessions) can end up sandboxed → then write/edit won’t be operating on your Mac filesystem (and absolute paths like /Users/... will fail / hit the sandbox FS).

Do this in the dashboard

In Control UI → Sessions, make sure the chat session you’re using is:

agent:main:main

If you’re in something like agent:main:telegram:..., switch to the main session and try again.

Docs: https://docs.openclaw.ai/web/control-ui

Hard “make it always work” fix (no sandbox anywhere)

On the machine running the gateway:

#

openclaw config get agents.defaults.sandbox.mode

If it’s "non-main" or "all", force it off:

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

Docs: https://docs.openclaw.ai/gateway/sandboxing

If it still fails

Paste:

the exact tool error line, and
the output of:

#

openclaw sessions --all-agents

…and tell me which session the dashboard is currently using (copy the agent:... key). That’ll let me tell you immediately if you’re sandboxed / in the wrong session.

gleaming scroll Mar 2, 2026, 2:33 PM

#

main direct agent:main:teleg...395025 just now kimi-k2.5:cloud 93k/262k (36%) system id:07eec55c-663f-4584-99a1-dcccdefea64e and i didnt get any errors

dusk coralBOT Mar 2, 2026, 2:33 PM

#

That line tells us the important bit: you’re currently in the Telegram DM session:

agent:main:telegram:dm:...395025

…not the “global main” session (agent:main:main). That matters because sandboxing is decided per session key (and tool behavior can differ per session).

Quick check (this usually reveals the culprit immediately)

Run:

openclaw sandbox explain --session "agent:main:telegram:dm:...395025"

(Use the full key from your list.)

If it shows mode: non-main (or runtime sandboxed), then your file tools are running in the sandbox filesystem, and /Users/... paths will “fail”.

#

Two “make it stay working” fixes

Fix A (recommended if you want Telegram DMs to be the same “main” session):

openclaw config set session.dmScope "main"
openclaw gateway restart

This makes Telegram DMs land in agent:main:main again.

Fix B (blunt): disable sandboxing entirely:

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

Why you “didn’t get any errors”

The sessions list won’t show tool errors. To catch the actual reason when it fails, tail logs while reproducing:

#

openclaw logs --follow

If you paste the output of sandbox explain --session ... (for that Telegram key), I’ll tell you exactly which setting to flip.

gleaming scroll Mar 2, 2026, 2:37 PM

#

14:36:53 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=session:agent:main:telegram:direct:6471395025 durationMs=7350 active=0 queued=0
stic {"subsystem":"diagnostic"} lane task done: lane=main durationMs=7348 active=0 queued=0
14:36:53 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=session:agent:main:telegram:direct:6471395025 durationMs=7350 active=0 queued=014:37:05 error Gateway start blocked: set gateway.mode=local (current: unset) or pass --allow-unconfigured.
14:37:05 error Config write audit: /Users/djryan/.openclaw-dev/logs/config-audit.jsonl

dusk coralBOT Mar 2, 2026, 2:37 PM

#

That log line is the smoking gun:

Gateway start blocked: set gateway.mode=local (current: unset)

So the gateway isn’t actually starting right now → no tools will work.

Fix = set gateway.mode and restart.

Run on the same machine/user that runs the gateway:

openclaw config file
openclaw config set gateway.mode "local"
openclaw gateway restart
openclaw gateway status

#

Notes:

Your log path shows ~/.openclaw-dev/... so you might be on a dev profile. openclaw config file will tell you which config you’re editing (CLI vs service mismatch is a common reason this keeps coming back).
If openclaw gateway restart still fails, paste openclaw gateway status --deep (it shows “Config (cli)” vs “Config (service)”).

Docs reference (same error signature): https://docs.openclaw.ai/gateway/troubleshooting#gateway-service-not-running

gleaming scroll Mar 2, 2026, 2:39 PM

#

I am using a dev profile for n8n should I switch?

dusk coralBOT Mar 2, 2026, 2:39 PM

#

You can keep using a dev profile — profiles are just separate configs + state. The downside is you now have two places things can be misconfigured, and that’s exactly what happened: your dev profile is missing gateway.mode, so the gateway refuses to start (Gateway start blocked: set gateway.mode=local).

If n8n is the only reason you made a dev profile

You don’t need a separate OpenClaw profile for n8n. n8n can talk to your normal gateway just fine (often simpler).

If you want to KEEP the dev profile (totally fine)

Configure it properly:

openclaw config set gateway.mode "local"
openclaw gateway restart

Then confirm it’s actually the same profile the service is running under:

#

openclaw config file
openclaw gateway status --deep

(That --deep output is the “CLI vs service config mismatch” detector.)

If you want to SWITCH back to default (simpler)

Use the default profile for day-to-day OpenClaw, and only use dev when you’re actively testing. The key is: n8n must point at the gateway URL/token of whichever profile you’re running.

If you tell me how you start OpenClaw (launchd service? openclaw gateway start manually? docker?) I can tell you the cleanest way to ensure the service and your CLI/dashboard are using the same profile consistently.

gleaming scroll Mar 2, 2026, 2:40 PM

#

I start with openclaw gateway start

dusk coralBOT Mar 2, 2026, 2:41 PM

#

If you start the gateway with openclaw gateway start and sometimes you’re in a dev profile, the “tools work / tools don’t work” flip-flop is usually just: you’re accidentally starting/connecting to different profiles (different state dirs + different ports + different config).

From the docs, the dev profile uses:

state dir: ~/.openclaw-dev
config: ~/.openclaw-dev/openclaw.json
default gateway port: 19001 (instead of 18789)
Source: https://docs.openclaw.ai/help/debugging

Recommendation

Yes: don’t use the dev profile for day-to-day unless you really want two isolated gateways. Use default for your “real” gateway, and only use dev for experiments.

If you want to KEEP dev profile anyway

You must start the service under the dev profile too (otherwise you edit ~/.openclaw-dev/... but start the default gateway service, or vice versa):

# stop whatever is running

#

openclaw gateway stop

# start the dev profile gateway service
OPENCLAW_PROFILE=dev openclaw gateway start
# (or equivalently if you prefer flags: openclaw --profile dev gateway start)

And set the required key once in the dev config (this is what bit you earlier):

OPENCLAW_PROFILE=dev openclaw config set gateway.mode "local"
OPENCLAW_PROFILE=dev openclaw gateway restart

Quick “which one am I actually running?” check

Run these once (with and without OPENCLAW_PROFILE=dev) and compare:

#

openclaw config file
openclaw gateway status --deep

If you tell me whether you want one gateway (simplest) or two (default + dev), I can give you the clean exact setup so n8n and the dashboard always hit the right one.

gleaming scroll Mar 2, 2026, 2:43 PM

#

I am using the 18789 its good I just want to be able to use the tools lets fix that

dusk coralBOT Mar 2, 2026, 2:44 PM

#

If you’re on 18789 and the dashboard loads, the remaining “tools failing” cases are usually:

you’re accidentally running/connecting to a different profile/config than you think, or
you’re chatting in a session that’s sandboxed (common with Telegram sessions), or
the current model is flaky at tool-calling (you had kimi-k2.5:cloud in the session list).

Do this exact checklist on the machine running the gateway:

1) Make sure the service is using the config you’re editing

openclaw config file
openclaw gateway status --deep

You want the config path to be ~/.openclaw/openclaw.json (not ~/.openclaw-dev/...), and gateway status --deep should show RPC probe: ok.

2) Ensure the gateway is actually allowed to start (this bit you earlier)

#

openclaw config set gateway.mode "local"
openclaw gateway restart

3) Remove the #1 “why do file tools fail” cause: sandboxing

(Especially if you’re working from Telegram sessions / non-main sessions.)

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

4) Sanity-check the session you’re using in the dashboard

In Control UI → Sessions, if you’re chatting in something like:
agent:main:telegram:dm:...
run:

#

openclaw sandbox explain --session "agent:main:telegram:dm:YOURKEY"

If that session is sandboxed, file paths on your Mac won’t match what the tool sees.

5) If you’re using `kimi-k2.5:cloud`

Some non-default models are just unreliable at tool calls (they’ll “fail” write/edit/exec even though config is fine). In the dashboard, temporarily switch the session to a known tool-reliable model (ask in #models if unsure), then retry the same request.

If you paste the exact tool failure message you see in the dashboard (one example) + the output of openclaw gateway status --deep, I can tell you which of the above is the actual cause in your setup.

gleaming scroll Mar 2, 2026, 2:47 PM

#

it only says cloud on olama. should I switch to one that has the tools ?

dusk coralBOT Mar 2, 2026, 2:48 PM

#

Tools aren’t something a model “has” — they’re enabled/disabled by your OpenClaw gateway config (tool policy + sandbox).

But: some models/providers are simply bad at tool-calling (they don’t emit valid tool JSON), and then you’ll see “write/edit/exec failed” even though tools are enabled.

So yes: if you’re currently on an Ollama model (or something labeled “cloud” but coming via an Ollama/OpenAI-compat shim) and tool calls keep failing, switch to a known tool-reliable cloud model/provider for tool work. Local/Ollama models are a frequent culprit here.

Two quick checks before/after switching:

Make sure you’re not clamping tools for that provider:

openclaw config get tools.byProvider

After you switch models, retry and if it still fails, paste:

the exact error line
your session key (the agent:main:telegram:... one)
openclaw sandbox explain --session "<that key>"

#

Also: I won’t recommend a specific model name here (it changes too fast). Ask in #models which current models are reliably tool-capable with OpenClaw, and pick one of those for “coding/tools” sessions.

gleaming scroll Mar 2, 2026, 2:49 PM

#

got this error for step 1 Config path not found: tools.byProvider

dusk coralBOT Mar 2, 2026, 2:49 PM

#

Config path not found: tools.byProvider is fine — it just means you haven’t set any provider-specific tool restrictions, so there’s nothing there to show.

On your actual question: yes, switch. A lot of Ollama/local models (and some “cloud via Ollama”) are simply unreliable at tool-calling, so OpenClaw shows tool failures even though tools are enabled.

What to do:

In the OpenClaw dashboard → Sessions/Chat, change the session model to a tool-reliable cloud provider you have configured (typically an Anthropic/OpenAI-backed model rather than Ollama).
Retry the same “write/edit/exec” request.

If it still fails after switching, paste the exact tool error line you see (the red banner / notice text) and tell me which model/provider you switched to — the wording will tell us whether it’s:

tool policy blocked,
sandbox/path issue,
or the model returning invalid tool JSON.

gleaming scroll Mar 2, 2026, 2:50 PM

#

yea im going to try another cloud model if it still doesnt work then I will go to openrouter

dusk coralBOT Mar 2, 2026, 2:50 PM

#

Sounds good.

Two quick tips so you don’t chase ghosts:

Restart the gateway after any config/profile changes, otherwise you can end up testing stale state:

openclaw gateway restart

When you test the new cloud model, try one tiny tool action first (e.g. “create a file test.txt with ‘hi’ in it” inside your workspace). If that works, the tool pipeline is fine and any later failures are likely just path/sandbox/session issues.

If it still fails after switching models, paste:

the exact tool error banner text
openclaw gateway status --deep
the session key you’re using (the agent:... line from Sessions)

…and we’ll nail it quickly.

gleaming scroll Mar 2, 2026, 2:57 PM

#

when i switched, it said all tools working,

#Tools always failing