trim cragBOT Feb 25, 2026, 9:54 PM

#

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

autumn coveBOT Feb 25, 2026, 9:59 PM

#

A Mac mini on “latest macOS” generally isn’t the blocker here — what you described usually comes down to one (or more) of these:

Tool allowlist is missing “paired” tools (most common)
exec is allowed but process is NOT → exec can’t background/poll, so anything “long” times out
sessions_spawn is either disallowed by tool policy, or broken in that specific OpenClaw version
Local/OpenAI-compatible models (incl. Ollama / Kimi) sometimes don’t reliably follow multi-step tool protocols (so they “self-check” instead of calling tools)

1) First: paste these (they’re the fastest way to pinpoint which bucket you’re in)

Run on the Mac mini and paste output:

openclaw --version
openclaw status --all
openclaw config get tools

Docs for that triage ladder: https://docs.openclaw.ai/help/faq#first-60-seconds-if-somethings-broken

#

2) Why `exec` “works under ~5s” but not longer

In OpenClaw, long shell work is supposed to be: exec backgrounds → process poll/log reads output.

But per docs, if process is disallowed, exec runs synchronously and ignores backgrounding — that makes long commands feel “impossible” and they’ll hit timeouts.
Source: https://docs.openclaw.ai/tools/exec

So please check your tools config for allow/deny. You want both:

exec
process

Easiest is allowing the group:

group:runtime (includes exec, process)
and for spawning QA agents: group:sessions (includes sessions_spawn)

Tool groups reference: https://docs.openclaw.ai/gateway/configuration-reference (Tools → “Tool groups”)

3) Why `sessions_spawn` can be “completely broken”

#

Two common causes:

Tool policy: sessions_spawn is in group:sessions. If you’re on a restrictive tools.profile / tools.allow, it may simply not be available.
Version/regression: you mentioned 2026.2.24 — if you confirm that’s your actual version via openclaw --version, I’ll tell you the most likely upgrade target / workaround once I see your status --all + logs.

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

4) One more quick check (often revealing)

In the chat where Mochi runs, send:

/exec (shows whether exec is running on gateway vs node vs sandbox)
/model status (confirms what model/provider is active)

If /exec shows you’re running on a node and that node runtime has a short command timeout, that can also produce the “~5 seconds then dead” behavior.

5) If you see any “pairing required / 1008” type errors in logs

Then tool calls that touch gateway/session infra can fail until device identity is approved:

#

openclaw devices list

…and approve anything pending (only if you recognize it). Runbook section: https://docs.openclaw.ai/gateway/troubleshooting

Send those 3 command outputs (--version, status --all, config get tools) and (if you can) the exact error text you see when exec “times out”, and I’ll point to the specific fix (it’s usually a 1–2 line config change: allow group:runtime + group:sessions, or adjust where exec runs).

peak meteor Feb 25, 2026, 10:10 PM

#

Gateway logs (tail, summarized): /Users/djryan/.openclaw/logs

stderr: /Users/djryan/.openclaw/logs/gateway.err.log

2026-02-25T22:03:43.938Z [imessage] imsg rpc: failed to parse permissionDenied(path: "/Users/djryan/Library/Messages/chat.db", underlying: authorization denied (code: 23)): Unexpected token 'p', "permission"... is not valid JSON
2026-02-25T22:03:44.476Z [imessage] imsg rpc: failed to parse permissionDenied(path: "/Users/djryan/Library/Messages/chat.db", underlying: authorization denied (code: 23)): Unexpected token 'p', "permission"... is not valid JSON
2026-02-25T22:03:45.013Z [imessage] imsg rpc: failed to parse permissionDenied(path: "/Users/djryan/Library/Messages/chat.db", underlying: authorization denied (code: 23)): Unexpected token 'p', "permission"... is not valid JSON
2026-02-25T22:03:45.548Z [imessage] imsg rpc: failed to parse permissionDenied(path: "/Users/djryan/Library/Messages/chat.db", underlying: authorization denied (code: 23)): Unexpected token 'p', "permission"... is not valid JSON
2026-02-25T22:03:46.085Z [imessage] imsg rpc: failed to parse permissionDenied(path: "/Users/djryan/Library/Messages/chat.db", underlying: authorization denied (code: 23)): Unexpected token 'p', "permission"... is not valid JSON
2026-02-25T22:03:46.643Z [imessage] imsg rpc: failed to parse permissionDenied(path: "/Users/djryan/Library/Messages/chat.db", underlying: authorization denied (code: 23)): Unexpected token 'p', "permission"... is not valid JSON
… 18 lines omitted …
2026-02-25T17:03:54.407-05:00 - pid 24677 djryan: openclaw-gateway (127.0.0.1:18789)
2026-02-25T17:03:54.407-05:00 - Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.

autumn coveBOT Feb 25, 2026, 10:12 PM

#

That /exec output is a big clue:

host=sandbox, security=deny

So your agent is trying to run exec inside the sandbox, and (crucially) long commands only work reliably if OpenClaw can background them quickly and then poll via process.

With a bunch of OpenAI-compatible/self-hosted providers (including some “Kimi via Ollama/OpenAI compat” setups), the model request can time out very fast while it’s waiting for a tool result — so anything that runs longer than a few seconds looks like “exec timed out”.

Fix 1 (most likely): background sooner than the provider timeout

Set exec to auto-background quickly:

openclaw config set tools.exec.backgroundMs 1000
openclaw gateway restart

That makes exec return a sessionId after ~1s instead of waiting ~10s (default), and then the agent should use process poll/log to get output.

#

(If process isn’t allowed, this won’t help — see Fix 2.)

Fix 2: make sure `process` + `sessions_spawn` are actually allowed

If tool policy is restrictive, you can end up in exactly what Mochi described (can’t spawn QA agents, can’t poll background jobs).

Please paste:

openclaw --version
openclaw config get tools

What I’m looking for in that output:

tools.profile (if it’s minimal, you won’t have what you need)
tools.allow / tools.deny
any tools.byProvider rules that might be disabling session tools for your Kimi/Ollama provider

#

Reference for tool groups/profiles: https://docs.openclaw.ai/gateway/configuration-reference#tools

Fix 3: your iMessage errors are unrelated, but they’re flooding your logs

These lines:

authorization denied (code: 23) for ~/Library/Messages/chat.db

mean macOS privacy blocked Messages DB access. Either:

grant Full Disk Access to the process running OpenClaw/imsg, or
disable iMessage channel if you’re not using it (to stop the noise)

Docs: https://docs.openclaw.ai/channels/imessage (see Full Disk Access / missed prompts)

Also: “Gateway already running locally” isn’t a problem

That just means you already have the daemon up on 127.0.0.1:18789, and you tried to start a second copy.

#

If you paste openclaw --version + openclaw config get tools, I can tell you exactly why sessions_spawn is failing in your setup (policy vs version bug), and what to change (usually just enabling group:runtime + group:sessions for your agent/provider).

peak meteor Feb 25, 2026, 10:15 PM

#

{
"web": {
"search": {
"enabled": false
},
"fetch": {
"enabled": false
}
},
"exec": {
"backgroundMs": 1000
}
}

autumn coveBOT Feb 25, 2026, 10:17 PM

#

Cool — that confirms you only changed one thing: tools.exec.backgroundMs: 1000 (good), and web tools are disabled (not relevant to exec/process/sessions_spawn).

0) Make sure you restarted the gateway

Config changes won’t reliably apply until restart:

openclaw gateway restart

1) Quick smoke test (tells us if `exec`+`process` are fundamentally working)

In the chat with Mochi, ask it to run something that must exceed 5s, e.g.:

“Run exec with sleep 12; echo done (or equivalent), and then poll with process until it exits.”

What you should see if things are healthy:

exec returns quickly with status: running + a sessionId
then process poll returns output and eventually exit status

#

If it still “times out”, paste the exact tool error Mochi shows for:

the exec call result
the first process poll result

(Without the exact error text, we’re guessing.)

2) Your `/exec` defaults show `host=sandbox` — verify sandbox is actually healthy

Please paste:

openclaw --version
openclaw status --all

status --all will usually reveal if sandbox is failing/restarting, if tools are denied by policy, etc.
Docs: https://docs.openclaw.ai/help/faq#first-60-seconds-if-somethings-broken

#

3) `sessions_spawn` specifically: we need the actual failure message

When Mochi says “sessions_spawn broken”, it could be either:

tool is denied by policy (common if an agent has a restrictive tool allowlist), or
it’s an actual runtime error/regression, or
the model is just not calling it correctly

So: please trigger the “spawn Billy” behavior once, then paste the literal sessions_spawn tool error from the chat (or the relevant log lines around that time from gateway.err.log).

4) iMessage log spam is separate (but you should fix/disable it)

Those authorization denied (code: 23) Messages DB lines mean macOS privacy blocked access to:

~/Library/Messages/chat.db

It won’t cause exec timeouts, but it will flood logs and hide the real errors.

Fix options:

grant Full Disk Access to the process context running OpenClaw/imsg, or

#

disable iMessage channel if you aren’t using it

Docs: https://docs.openclaw.ai/channels/imessage

Post openclaw --version + openclaw status --all + the exact exec/process failure text and I can tell you if this is (A) sandbox/runtime, (B) tool policy/allowlist, or (C) model/provider weirdness with Kimi/Ollama.

peak meteor Feb 25, 2026, 10:33 PM

#

got this error for step 1 Exec tool is completely unavailable

autumn coveBOT Feb 25, 2026, 10:35 PM

#

“Exec tool is completely unavailable” means OpenClaw isn’t even offering the exec tool to Mochi (this is tool policy/allowlist, not a timeout/provider issue).

Your openclaw config get tools output only shows tools.exec.backgroundMs, but tool allow/deny can be set in other places (global profile, per-agent overrides, or tools.byProvider).

Please run these and paste the output

openclaw --version

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

openclaw config get agents.defaults.tools
openclaw config get agents.list

#

Quick “just make exec come back” fix (safe default)

If this is your personal bot and you actually want tools enabled, set the global tool profile to coding (this includes exec + process + sessions tools like sessions_spawn):

openclaw config set tools.profile coding
openclaw gateway restart

Tool profile reference (what each profile includes): https://docs.openclaw.ai/gateway/configuration-reference#tool-profiles

If you want it only for Mochi (and not other agents), paste agents.list and I’ll tell you the exact agents.list[INDEX]... command to apply it just to that agent.

(Also: if this bot is in a public Discord server, don’t enable exec unless your allowFrom/pairing is locked down to you.)

peak meteor Feb 25, 2026, 10:39 PM

#

[
{
"id": "main",
"name": "main",
"workspace": "/Users/djryan/.openclaw/workspace",
"agentDir": "/Users/djryan/.openclaw/agents/main/agent",
"tools": {
"profile": "full",
"alsoAllow": [
"read",
"edit",
"write",
"exec",
"web_search",
"process",
"memory_get",
"memory_search",
"sessions_spawn",
"canvas",
"browser",
"nodes",
"agents_list",
"image"
]
}
},
{
"id": "tom",
"name": "Tom",
"workspace": "/Users/djryan/.openclaw/agents/tom/workspace",
"agentDir": "/Users/djryan/.openclaw/agents/tom/agent",
"identity": {
"name": "Tom",
"theme": "Level 5 Autonomous Operator (AI engine)",
"emoji": "🕵️",
"avatar": "_[To be configured]"
}
},
{
"id": "hasan",
"name": "Hasan",
"workspace": "/Users/djryan/.openclaw/agents/hasan/workspace",
"agentDir": "/Users/djryan/.openclaw/agents/hasan/agent",
"identity": {
"name": "Hasan",
"emoji": "🏗️"
}
},
{
"id": "ashley",
"name": "Ashley",
"workspace": "/Users/djryan/.openclaw/agents/ashley/workspace",
"agentDir": "/Users/djryan/.openclaw/agents/ashley/agent",
"identity": {
"name": "Ashley",
"emoji": "📽️"
}
},
{
"id": "rick",
"name": "Rick",
"workspace": "/Users/djryan/.openclaw/agents/rick/workspace",
"agentDir": "/Users/djryan/.openclaw/agents/rick/agent",
"identity": {
"name": "Rick",
"emoji": "🎬"
}
},
{
"id": "hunter",
"name": "Hunter",
"workspace": "/Users/djryan/.openclaw/agents/hunter/workspace",
"agentDir": "/Users/djryan/.openclaw/agents/hunter/agent",
"identity": {
"name": "Hunter",
"emoji": "🎯"
}
}
]

autumn coveBOT Feb 25, 2026, 10:41 PM

#

That makes sense now: your session has /exec host=sandbox, but on macOS the sandbox runtime is often not actually running / not installed (Docker/Podman) — and OpenClaw fails closed in that case, which surfaces as:

“Exec tool is completely unavailable”

So this isn’t a Kimi/Ollama timeout thing yet — it’s “you told exec to run in a sandbox that doesn’t exist”.

Fix it immediately (no sandbox): switch exec to run on the Mac host

In the chat with Mochi, send this as a standalone message:

/exec host=gateway security=full ask=off

Then try a long-ish command again (sleep test or git). With your backgroundMs: 1000, long commands should background and become pollable.

Docs for exec host + the “fails closed if sandbox is off” behavior: https://docs.openclaw.ai/tools/exec

#

Important safety note (since you’re on Discord)

Only do security=full ask=off if your bot is locked to just you (DM/pairing/allowFrom). Otherwise you’re basically giving anyone who can talk to the bot shell access.

If you want the “safer” version, use allowlist mode instead:

/exec host=gateway security=allowlist ask=on-miss

…but then you’ll need to allowlist /usr/bin/git, etc.

If you do want sandbox mode

Then you need to actually enable/run the sandbox runtime on the Mac (usually Docker), and confirm it’s healthy via:

openclaw status --all

#

openclaw doctor

One more thing: your agent list looks fine

Your main agent is tools.profile: "full" and explicitly allows exec/process/sessions_spawn, so tool policy is probably not the issue here — it’s the host=sandbox setting.

Reply with what /exec prints after you set it to host=gateway, and whether exec now returns a sessionId (background) or still errors.

peak meteor Feb 25, 2026, 10:45 PM

#

⚙️ Exec defaults set (host=gateway, security=full, ask=off).

autumn coveBOT Feb 25, 2026, 10:45 PM

#

Nice — that confirms the root cause was “host=sandbox with no working sandbox runtime”. With:

host=gateway, security=full, ask=off

exec should now actually run on your Mac host.

Next: verify long commands + background/poll works

In the chat with Mochi, ask it to run exactly this and show you the tool outputs:

exec:

command: sleep 12; echo done

Because you set tools.exec.backgroundMs: 1000, it should return a sessionId quickly.

then process:

action: poll
sessionId: (the one from exec)

#

Expected result: you eventually see done + an exit code.

If that works, your “>5s commands time out” + “background processes can’t be polled” problems are basically solved.

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

Then: test sub-agent spawning (without relying on the model)

Instead of having Mochi call sessions_spawn, use the gateway command (more deterministic):

/subagents spawn main write a single line: OK

You should get an announce back when it finishes. If this fails, paste the error text.

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

#

Security follow-up (important on Discord)

security=full ask=off is “no guardrails”. Once you confirm it works, I’d strongly recommend switching to:

/exec host=gateway security=allowlist ask=on-miss

…and then allowlist the few binaries you need (git, node, python, etc.). That’s the safe setup if there’s any chance other people can message the bot.

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

Post the output from the sleep 12 test (exec + first poll result) and we’ll know if anything else is still broken vs just model/tool-calling flakiness.

peak meteor Feb 25, 2026, 10:52 PM

#

got this Exec tool is completely down — "Tool not found" error.

Even with your settings (host=gateway, security=full), the tool won't load. This is a system-level failure, not a policy issue.

autumn coveBOT Feb 25, 2026, 10:55 PM

#

That “Tool not found” / “exec completely down” line smells like either:

you’re still in a sandboxed (non-main) session where sandbox tool policy blocks runtime tools, or
Mochi is hallucinating the error text (not actually coming from OpenClaw).

Let’s make it unambiguous with 2 CLI commands + a sandbox inspector.

1) Prove where the error is coming from

Run this in Terminal, then reproduce the exec attempt once:

openclaw logs --follow

If OpenClaw is truly rejecting the tool, you’ll see a real gateway-side error there (unknown tool / blocked by policy / sandbox, etc.). If logs show nothing relevant, Mochi is likely just making that up.

2) Check if this Discord thread session is “sandboxed (non-main)”

#

List recent sessions and grab the session key that matches your Discord thread/channel:

openclaw sessions --active 240

Then run:

openclaw sandbox explain --session "<PASTE_SESSION_KEY_HERE>"

This will explicitly tell you:

sandbox mode (off / non-main / all)
whether this session is considered sandboxed
the effective sandbox tool allow/deny, and the exact config keys to change

#

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

3) Paste these 3 outputs

the relevant lines from openclaw logs --follow when you trigger exec
openclaw sessions --active 240 (just the entry for this thread is enough)
openclaw sandbox explain --session ...

Once I see that, I can tell you the exact fix (usually one of):

set agents.defaults.sandbox.mode=off, or
allow group:runtime in tools.sandbox.tools.allow, or
switch to the true “main” session key (if you’re in "non-main" mode)

Right now, /exec host=gateway … only sets defaults — it can’t override sandbox/tool policy if the session is being treated as sandboxed.

peak meteor Feb 25, 2026, 10:59 PM

#

I do see this warn tools {"subsystem":"tools"} agents.main.tools.allow allowlist contains unknown entries (web_search, memory_get, memory_search). These entries won't match any tool unless the plugin is enabled. and agent/embedded {"subsystem":"agent/embedded"} embedded run tool end: runId=f002661a-c618-4e6f-a8cd-b2ff67c6a23c tool= toolCallId=ollama_call_4e056b2c-13d0-4403-8f99-663cb09a7ce7

autumn coveBOT Feb 25, 2026, 11:01 PM

#

That log line is the smoking gun:

embedded run tool end ... tool= (tool name is empty)
which then surfaces to you as “Tool not found”

That usually does not mean OpenClaw “lost” the exec tool — it means your model/provider returned a malformed tool call (e.g. a tool_call object with no name), so OpenClaw can’t route it to exec/process/etc.

What the warning about `web_search` / `memory_*` means

This one is separate:

agents.main.tools.allow ... unknown entries (web_search, memory_get, memory_search)

In your config, tools.web.search.enabled and tools.web.fetch.enabled are false, so web_search isn’t registered. Same story if memory tools are disabled/unconfigured. That warning is basically: “you allowlisted tools that are currently disabled, so they’ll never match.”

It’s noisy but not the root cause of exec being “Tool not found”.

The real fix: use a provider/API mode that actually supports tool calling

#

Since your toolCallId is ollama_call_..., OpenClaw thinks it’s talking to an Ollama provider. If you’re pointing that at some “Ollama Cloud Kimi 2.5” endpoint, there’s a good chance it’s not implementing tool calling correctly (or not with streaming).

Do these two checks on your Mac mini and paste them:

openclaw config get agents.defaults.model
openclaw config get models.providers.ollama

What we’re looking for:

If your baseUrl ends with /v1 and api is openai-completions, you’re in “OpenAI-compat mode”, which often breaks tool calling + streaming.
For “real” Ollama tool calling, you generally want the native Ollama API (api: "ollama") and a non-/v1 baseUrl (like http://127.0.0.1:11434).

Docs: https://docs.openclaw.ai/providers/ollama (see Legacy OpenAI-Compatible Mode note)

If you actually want “Kimi 2.5”, don’t run it through the Ollama provider

#

Kimi is Moonshot. OpenClaw has a first-class provider for it:

Docs: https://docs.openclaw.ai/providers/moonshot
(Default model ref there is moonshot/kimi-k2.5.)

That route is much more likely to produce valid tool calls than “Kimi behind an Ollama/OpenAI-compat proxy”.

Quick sanity test after you adjust provider

Once the provider config is fixed, exec should stop producing tool= blank in logs and will start showing tool=exec.

If you paste the two config outputs above, I’ll tell you exactly what to change (the correct api + baseUrl combo for your setup).

peak meteor Feb 25, 2026, 11:03 PM

#

that reminds me i did something yesterday where I switched openclaw to local ollama but then switched back to the cloud using ollama

autumn coveBOT Feb 25, 2026, 11:06 PM

#

Yep — that warning + the embedded run tool end ... tool= line fits perfectly with “you switched providers yesterday”.

What’s happening:

The Gateway has the tools (your agent config shows exec, process, etc. are allowed).
But your current model/provider is emitting broken tool calls (tool name ends up empty), so OpenClaw can’t route it → you see “Tool not found”.

That’s almost always caused by using an OpenAI-compatible “cloud” endpoint through the ollama provider, or using OpenAI-compat mode + streaming where the backend doesn’t implement tool-calling deltas correctly.

Why the “unknown entries” warning appears

You have tools allowed (web_search, memory_*) that are currently not registered because those subsystems are disabled/unconfigured (you set tools.web.search.enabled=false, etc.). It’s noisy but not the core failure.

Fix path (pick one)

Option A (recommended if you want Kimi 2.5 reliably): use the Moonshot provider, not Ollama

OpenClaw has a dedicated Moonshot/Kimi provider. Docs + copy/paste here:
https://docs.openclaw.ai/providers/moonshot

#

On your Mac mini:

openclaw onboard --auth-choice moonshot-api-key
# then set your default model to moonshot/kimi-k2.5 (per the docs)

This avoids the broken “Ollama cloud OpenAI-compat” tool-call format entirely.

Option B (if you insist on “cloud via ollama/openai-compat”): disable streaming for that model

Some OpenAI-compatible backends can’t do streaming + tool calling correctly. OpenClaw’s Ollama docs explicitly warn about this:
https://docs.openclaw.ai/providers/ollama#legacy-openai-compatible-mode

You’d set the model params to disable streaming (params: { streaming: false }) — but I need your exact model ref to give the exact command.

Paste these 3 commands so I can tell you exactly what to change

#

openclaw config get agents.defaults.model
openclaw config get models.providers.ollama
openclaw models status

Once I see whether your “cloud Kimi” is configured as ollama with api: openai-completions (and what the model id is), I’ll tell you the minimal change to get tools working again.

peak meteor Feb 25, 2026, 11:09 PM

#

🦞 OpenClaw 2026.2.24 (df9a474) — I'm the reason your shell history looks like a hacker-movie montage.

{
"primary": "ollama/kimi-k2.5:cloud",
"fallbacks": [
"ollama-cloud/kimi-k2.5:cloud",
"ollama-cloud/gemini-3-flash-preview:cloud"
]
}

🦞 OpenClaw 2026.2.24 (df9a474) — I'm not saying your workflow is chaotic... I'm just bringing a linter and a helmet.

{
"baseUrl": "http://127.0.0.1:11434/v1",
"apiKey": "OPENCLAW_REDACTED",
"api": "ollama",
"models": [
{
"id": "kimi-k2.5:cloud",
"name": "kimi-k2.5:cloud",
"reasoning": true,
"input": [
"text",
"image"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 262144,
"maxTokens": 262144,
"api": "ollama"
},
{
"id": "gemma2:2b",
"name": "gemma2:2b",
"input": [
"text"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 8192,
"reasoning": false,
"maxTokens": 8192,
"api": "ollama"
},
{
"id": "qwen2.5-coder:7b",
"name": "qwen2.5-coder:7b",
"input": [
"text"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 32768,
"reasoning": false,
"maxTokens": 8192,
"api": "ollama"
},
{
"id": "ministral-3",
"name": "ministral-3",
"input": [
"text"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0

autumn coveBOT Feb 25, 2026, 11:09 PM

#

Yep — your config shows a mismatched Ollama setup, and that’s very likely why you’re getting the “tool not found / tool name empty” behavior.

You currently have:

models.providers.ollama.baseUrl = "http://127.0.0.1:11434/v1"
models.providers.ollama.api = "ollama"

/v1 is the OpenAI-compatible endpoint path. The native Ollama API (the one OpenClaw expects when api: "ollama") is not /v1.

When the backend/provider tool-call format doesn’t line up, you get exactly what you saw in logs:

embedded run tool end ... tool= (empty tool name) → OpenClaw can’t route → “Tool not found”.

Fix (recommended): use native Ollama API properly

Run these on your Mac mini:

#

openclaw config set models.providers.ollama.baseUrl "http://127.0.0.1:11434"
openclaw config set models.providers.ollama.api "ollama"
openclaw gateway restart

Then re-check:

openclaw models status

…and try your exec sleep 12; echo done test again.

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

If you intentionally want OpenAI-compatible mode (`/v1`)

#

Then you should flip the provider API mode to OpenAI-compatible, and be aware tool-calling + streaming can be flaky there:

openclaw config set models.providers.ollama.baseUrl "http://127.0.0.1:11434/v1"
openclaw config set models.providers.ollama.api "openai-completions"
openclaw gateway restart

If tool calls still come through broken, the Ollama docs note you may need to disable streaming for that model in its params.

Strong suggestion if your goal is “Kimi K2.5 cloud”

Don’t route it through “Ollama cloud”. Use the Moonshot/Kimi provider directly (it’s designed for this):

https://docs.openclaw.ai/providers/moonshot

#

If you do the native-Ollama fix above and it still logs tool= (empty), paste the next few lines around the tool call from openclaw logs --follow, plus openclaw config get models.providers.ollama-cloud (since you also have ollama-cloud/... in fallbacks).

peak meteor Feb 25, 2026, 11:10 PM

#

okay so I want to use the cloud because I am paying for it. its 20 dollars a month vs paying for tokens

autumn coveBOT Feb 25, 2026, 11:12 PM

#

Totally fair — if you’re already paying Ollama Cloud (the :cloud models), you should use that and not burn API tokens elsewhere.

The good news: your setup is very close. The bad news: right now OpenClaw is talking to Ollama in a mismatched mode:

you have api: "ollama" (native Ollama)
but your baseUrl is http://127.0.0.1:11434/v1 (OpenAI-compatible path)

That mismatch is exactly the kind of thing that produces broken tool-calls (tool= blank → “Tool not found”).

Do this (keeps using your paid `kimi-k2.5:cloud`)

On the Mac mini:

openclaw config set models.providers.ollama.baseUrl "http://127.0.0.1:11434"
openclaw config set models.providers.ollama.api "ollama"
openclaw gateway restart

#

Then verify:

openclaw models status

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

Why this matters for your “tools don’t work” symptoms

When OpenClaw uses the native Ollama API (/api/chat under the hood), it has reliable streaming + tool calling. When it goes through /v1 OpenAI-compat, some backends/proxies mess up tool-call chunks, and OpenClaw ends up seeing “unknown tool” / empty tool names.

One more thing: you have `ollama-cloud/...` in fallbacks

After the restart, also paste:

openclaw config get models.providers.ollama-cloud

#

If that provider also points at a /v1 URL with api: "ollama", we should fix it the same way (or remove it from fallbacks and just stick to ollama/...:cloud).

Billing reality check (so expectations are set)

ollama/kimi-k2.5:cloud uses your Ollama Cloud plan (flat monthly).
moonshot/kimi-k2.5 uses Moonshot API billing (pay-per-token). That’s why I was steering you away from it if your goal is “use what I’m already paying for”.

Run the two config changes + restart, then try the sleep 12; echo done exec test again. If it still fails, paste the first “tool not found” log chunk after the restart.

peak meteor Feb 25, 2026, 11:15 PM

#

the one more thing command didnt work

autumn coveBOT Feb 25, 2026, 11:16 PM

#

That’s almost certainly just the hyphen in the provider name.

openclaw config get models.providers.ollama-cloud won’t parse as a normal “dot path”, because ollama-cloud isn’t a valid identifier. Use bracket notation:

openclaw config get 'models.providers["ollama-cloud"]'

If you want to see what provider keys you actually have configured, run:

openclaw config get models.providers

Two follow-ups that will help confirm the “/v1 mismatch” is fixed:

#

openclaw config get models.providers.ollama.baseUrl
openclaw config get models.providers.ollama.api

If the bracket command still “didn’t work”, paste the exact error output it printed (even one line is enough) — there are two different cases:

path not found → you don’t have an ollama-cloud provider configured (so we should remove that fallback or add the provider)
parse error → quoting issue, and we’ll adjust the syntax for your shell

peak meteor Feb 25, 2026, 11:18 PM

#

this what i got for the follow up http://127.0.0.1:11434

🦞 OpenClaw 2026.2.24 (df9a474) — Turning "I'll reply later" into "my bot replied instantly".

ollama

#

and this {
"ollama": {
"baseUrl": "http://127.0.0.1:11434",
"apiKey": "OPENCLAW_REDACTED",
"api": "ollama",
"models": [
{
"id": "kimi-k2.5:cloud",
"name": "kimi-k2.5:cloud",
"reasoning": true,
"input": [
"text",
"image"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 262144,
"maxTokens": 262144,
"api": "ollama"

autumn coveBOT Feb 25, 2026, 11:19 PM

#

Perfect — that’s the correct combo for native Ollama tool calling:

baseUrl = http://127.0.0.1:11434 (no /v1)
api = ollama

That should stop the “tool name is empty → Tool not found” failures.

Next steps (quick verification)

Restart gateway (so the model runtime definitely reloads with the new baseUrl):

openclaw gateway restart

In the Discord thread, start fresh (so the session isn’t stuck in a bad tool-call loop):

#

/new

Ask Mochi to run this exact test (it forces background + process poll):

exec: sleep 12; echo done
then process poll on the returned sessionId until it finishes

Expected: exec returns a sessionId quickly (you set backgroundMs: 1000 earlier), and process poll eventually prints done.

One more thing: remove that `ollama-cloud/...` fallback (it’s probably not configured)

Your agents.defaults.model.fallbacks includes:

ollama-cloud/kimi-k2.5:cloud
ollama-cloud/gemini-3-flash-preview:cloud

If you don’t actually have a models.providers["ollama-cloud"] entry, those fallbacks will always fail and can confuse debugging. You can simplify to just Ollama:

#

openclaw config set agents.defaults.model.fallbacks '[]' --strict-json
openclaw gateway restart

(Or set a real fallback you know exists, like a local model.)

If the exec test still fails after the restart + /new, paste the exact few log lines around the failure (especially any line that again shows tool= empty).

#

Nice — that confirms the provider config is now clean:

models.providers.ollama = {
  baseUrl: "http://127.0.0.1:11434",
  api: "ollama",
  models: [{ id: "kimi-k2.5:cloud", ... }]
}

That is exactly what you want for Ollama native tool calling (and you still get your paid :cloud model).

Now do the “does it actually work?” checklist

Restart so the gateway reloads everything:

openclaw gateway restart

#

In the Discord thread, reset the chat session (clears any stuck/bad tool-call state):

/new

Ask Mochi to run:

exec: sleep 12; echo done
then process poll on the returned sessionId

If it works, your original issues should improve a lot:

long scripts stop “timing out”
background polling becomes reliable
multi-step “exec → poll → verify” chains behave again

Optional cleanup (recommended)

Your defaults had ollama-cloud/... fallbacks earlier. If you don’t have a real models.providers["ollama-cloud"] configured, remove those fallbacks so the bot doesn’t bounce into a dead provider:

#

openclaw config set agents.defaults.model.fallbacks '[]' --strict-json
openclaw gateway restart

If the test still fails, paste the exact tool error Mochi shows and the matching lines from openclaw logs --follow (we’re looking specifically for whether tool= is still empty or if it’s now a real tool=exec but something else is blocking).

peak meteor Feb 25, 2026, 11:24 PM

#

got this tatus: Tools are degrading

Started working briefly → now "Tool not found" again
Can't use process to poll
Can't use exec anymore
Summary:

exec started but couldn't complete
process tool completely unavailable
session "good-shore" (pid 74264) is running but I can't interact with it
This confirms:

2026.2.24 is fundamentally unstable
Tools appear and disappear randomly
No reliable way to run long commands

autumn coveBOT Feb 25, 2026, 11:27 PM

#

That “Tools are degrading / tools appear and disappear randomly” message is almost certainly Mochi guessing, not OpenClaw reporting facts.

What is real from your logs earlier is this pattern:

embedded run ... tool= (tool name is empty)
→ that only happens when the model/provider sends a malformed tool call (missing the tool name), so OpenClaw can’t route it and you get “Tool not found”.

There are two practical things to do now:

1) Stop provider failover from changing behavior mid-run

Your defaults were set to fall back to ollama-cloud/... models. If that provider isn’t configured (or behaves differently), you can get “random” differences.

Run:

openclaw config set agents.defaults.model.fallbacks '[]' --strict-json

#

openclaw gateway restart

Then in the Discord thread do:

/new
/model status

Confirm it stays on ollama/kimi-k2.5:cloud and isn’t bouncing.

2) Prove whether the problem is “Kimi cloud tool-calling” vs OpenClaw tools

Do one A/B test:

A) Switch to a local model you already have (just for the test)

#

In the Discord thread:

/model ollama/qwen2.5-coder:7b

Then ask Mochi to run:

exec: sleep 12; echo done
then process poll until it finishes

If this works reliably, your OpenClaw toolchain (exec + process) is fine — and kimi-k2.5:cloud is the part emitting broken tool calls.

B) Switch back to Kimi cloud

/model ollama/kimi-k2.5:cloud

#

Run the same sleep 12 test. If it breaks again, that’s your answer.

If it still breaks: capture one real log snippet

Run this in Terminal while reproducing:

openclaw logs --follow

…and paste the few lines around the failure (especially any line that looks like embedded run ... tool= or “unknown tool”).

That will let us say with certainty whether:

it’s sandbox/tool policy blocking process, or
the model is outputting malformed tool calls (most likely with Kimi cloud right now).

If it turns out Kimi cloud can’t do proper tool calling, the only “fix” is: use Kimi for chat, but use a different model for tool-heavy runs (even if just temporarily via /model).

peak meteor Feb 25, 2026, 11:37 PM

#

im in telegram not discord

autumn coveBOT Feb 25, 2026, 11:38 PM

#

Got it — you chat with Mochi in Telegram, but you’re asking for help here. That’s fine: the tool failures are happening at the Gateway ↔ model layer, so Discord vs Telegram isn’t the core issue (Telegram just doesn’t have threads/bindings).

What I don’t trust is Mochi’s “2026.2.24 is fundamentally unstable / tools appear and disappear randomly” summary. The one thing we do trust is your gateway log pattern where the model sends a broken tool call (empty tool name), which becomes “Tool not found”.

Step 1: Confirm it’s really on the paid cloud Kimi model (in Telegram)

Send these as standalone messages to your bot in Telegram:

/new
/model status
/exec

Make sure /model status shows ollama/kimi-k2.5:cloud, and /exec shows host=gateway.

Step 2: A/B test to prove whether the model is the problem

Still in Telegram, do this:

#

Switch to a local Ollama model you already have installed (you showed qwen2.5-coder:7b exists):

/model ollama/qwen2.5-coder:7b

Ask Mochi: “Run sleep 12; echo done with exec, then poll it with process until it finishes.”

If that works on the local model but breaks again when you switch back to:

/model ollama/kimi-k2.5:cloud

…then the conclusion is: Kimi cloud is emitting malformed tool calls (so OpenClaw can’t reliably run tools with it), even though OpenClaw itself is configured correctly.

Step 3 (workaround if Kimi cloud is the culprit): use OpenAI-compat mode + disable streaming for that model

Some OpenAI-compatible backends only behave if you turn off streaming for tool calling. OpenClaw’s Ollama docs call this out explicitly:
https://docs.openclaw.ai/providers/ollama#legacy-openai-compatible-mode

#

On your Mac mini:

openclaw config set models.providers.ollama.baseUrl "http://127.0.0.1:11434/v1"
openclaw config set models.providers.ollama.api "openai-completions"
openclaw config set 'agents.defaults.models["ollama/kimi-k2.5:cloud"].params.streaming' false --strict-json
openclaw gateway restart

Then go back to Telegram and retry the sleep 12 exec + process poll test.

If any of the above still fails: paste one real log snippet

Run on the Mac while reproducing (Telegram message that triggers exec):

openclaw logs --follow

#

…and paste the 10–20 lines around the failure, especially anything like embedded run ... tool= or unknown tool.

That will tell us if it’s still “empty tool name from model” vs something else (sandbox policy, etc.).

peak meteor Feb 25, 2026, 11:45 PM

#

got this in telegram New session started · model: ollama/kimi-k2.5:cloud

autumn coveBOT Feb 25, 2026, 11:46 PM

#

Great — that confirms Telegram is on the right model: ollama/kimi-k2.5:cloud.

Now do the two checks that will tell us why tools fail:

1) Confirm exec defaults (in Telegram)

Send:

/exec

We want it to show host=gateway (not sandbox).

2) Run the minimal background+poll test (in Telegram)

Send a single message to Mochi like:

“Run sleep 12; echo done using exec (so it backgrounds), then use process poll on the sessionId until it finishes, and show me the output.”

#

Expected if tools are healthy:

exec returns quickly with a sessionId
process poll returns done

If it fails

Please paste exactly what Mochi prints for the tool error (don’t summarize).

And in parallel on the Mac mini, run:

openclaw logs --follow

Then paste the few lines around the failure (we’re looking for the tool= empty-name issue again).

Quick next move if Kimi cloud breaks but local works

If this test fails on Kimi cloud, do the A/B:

#

/model ollama/qwen2.5-coder:7b

Run the same sleep 12 test again. If local works and Kimi cloud fails, we’ll switch your ollama provider to OpenAI-compat + streaming:false for Kimi cloud as a workaround.

peak meteor Feb 25, 2026, 11:51 PM

#

Tools completely down. Cannot execute — exec tool unavailable.

All pending tasks blocked:

Pokemon cron update
Yahoo odds scraper execution
Agent health checks

Status: System unavailable since ~2 PM.

Awaiting recovery.

autumn coveBOT Feb 25, 2026, 11:52 PM

#

That message is almost certainly Mochi narrating, not OpenClaw reporting. The real signal is what you saw earlier in gateway logs:

embedded run tool end ... tool= (empty tool name)
That only happens when the model/provider emits a malformed tool call, so OpenClaw can’t route it → you’ll see “Tool not found / tool unavailable”.

Let’s pin down whether this is Kimi cloud tool-calling vs OpenClaw tool policy/sandbox.

1) Grab one real failure from the gateway (not Mochi’s summary)

On the Mac mini, run:

openclaw logs --follow

Then in Telegram, ask Mochi to do something that forces tools (e.g. your sleep 12; echo done exec + process poll).
Now paste the 10–30 log lines around the failure.

#

2) A/B test (takes 1 minute)

In Telegram:

/model ollama/qwen2.5-coder:7b

Run the same exec+poll test.

If qwen works but ollama/kimi-k2.5:cloud breaks → the paid Kimi cloud model (or its server-side tool-call format) is the culprit.
If both break → we look at sandbox/tool policy / gateway runtime.

3) If Kimi cloud is the culprit, try the OpenAI-compat workaround

Some backends only behave with tools when you go through /v1 + disable streaming:

#

openclaw config set models.providers.ollama.baseUrl "http://127.0.0.1:11434/v1"
openclaw config set models.providers.ollama.api "openai-completions"
openclaw config set 'agents.defaults.models["ollama/kimi-k2.5:cloud"].params.streaming' false --strict-json
openclaw gateway restart

(That’s straight from the Ollama provider docs warning about OpenAI-compat + streaming/tool calling.)

Docs: https://docs.openclaw.ai/providers/ollama#legacy-openai-compatible-mode

Post the openclaw logs --follow snippet from one failed attempt and the result of the qwen A/B test, and we’ll know exactly which bucket you’re in.

peak meteor Feb 25, 2026, 11:54 PM

#

23:53:46 warn tools {"subsystem":"tools"} agents.main.tools.allow allowlist contains unknown entries (web_search, memory_get, memory_search). These entries won't match any tool unless the plugin is enabled.
23:53:46 debug diagnostic {"subsystem":"diagnostic"} run registered: sessionId=b61a794c-b8a9-4383-8dcc-3ac7e114fd60 totalActive=1
23:53:46 debug agent/embedded {"subsystem":"agent/embedded"} embedded run prompt start: runId=9c481c4b-6c09-402c-8dfb-d0b213615224 sessionId=b61a794c-b8a9-4383-8dcc-3ac7e114fd60
23:53:46 debug agent/embedded {"subsystem":"agent/embedded"} embedded run agent start: runId=9c481c4b-6c09-402c-8dfb-d0b213615224
23:53:48 debug agent/embedded {"subsystem":"agent/embedded"} embedded run agent end: runId=9c481c4b-6c09-402c-8dfb-d0b213615224 isError=false
23:53:48 debug agent/embedded {"subsystem":"agent/embedded"} embedded run prompt end: runId=9c481c4b-6c09-402c-8dfb-d0b213615224 sessionId=b61a794c-b8a9-4383-8dcc-3ac7e114fd60 durationMs=2324
23:53:48 debug diagnostic {"subsystem":"diagnostic"} run cleared: sessionId=b61a794c-b8a9-4383-8dcc-3ac7e114fd60 totalActive=0
23:53:48 debug agent/embedded {"subsystem":"agent/embedded"} embedded run done: runId=9c481c4b-6c09-402c-8dfb-d0b213615224 sessionId=b61a794c-b8a9-4383-8dcc-3ac7e114fd60 durationMs=2987 aborted=false
23:53:48 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=main durationMs=2990 active=0 queued=0
23:53:48 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=session:agent:main:main durationMs=2996 active=0 queued=0

autumn coveBOT Feb 25, 2026, 11:55 PM

#

Those log lines don’t show any tool failure — they show a clean embedded run that finished in ~2.3s with isError=false, and no embedded run tool start / tool=exec / tool=process lines at all.

So in that specific run, OpenClaw didn’t “lose exec/process”; your model simply didn’t call any tool (and then Mochi likely explained it as “tools down”).

1) Verify whether OpenClaw is even offering `exec/process` to this session

On the Mac mini, run:

openclaw sandbox explain --session agent:main:main
openclaw config get tools.deny
openclaw config get tools.byProvider

What I’m looking for:

any deny/allowlist that removes exec or process
any tools.byProvider rule for ollama (or ollama/kimi-k2.5:cloud) that sets a minimal tool profile

#

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

2) Capture a “real” tool attempt in logs

When you reproduce in Telegram, tail logs and look specifically for tool lines:

openclaw logs --follow | egrep -i "tool start|tool end|unknown tool|tool=|exec|process"

If exec is actually being called, you’ll see embedded run tool start ... tool=exec.

3) If Kimi cloud still won’t call tools, do the A/B test

In Telegram:

/model ollama/qwen2.5-coder:7b

#

Ask it to run sleep 12; echo done via exec and then process poll.

If qwen works but kimi-k2.5:cloud doesn’t, then it’s not OpenClaw “tools degrading” — it’s the Kimi cloud model/server not producing valid tool calls consistently. In that case the pragmatic workaround is: switch to qwen only when you need tools, then switch back to Kimi for chat.

If you paste the output of sandbox explain + one filtered log snippet from a failed attempt, we can point to the exact config knob that’s blocking tools (or confirm it’s purely the model).

peak meteor Feb 25, 2026, 11:57 PM

#

got this Effective sandbox:
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

Docs: docs.openclaw.ai/sandbox

🦞 OpenClaw 2026.2.24 (df9a474) — End-to-end encrypted, drama-to-drama excluded.

Config path not found: tools.deny

🦞 OpenClaw 2026.2.24 (df9a474) — Hot reload for config, cold sweat for deploys.

Config path not found: tools.byProvider

autumn coveBOT Feb 25, 2026, 11:58 PM

#

That sandbox explain output is actually great news: OpenClaw is not blocking tools.

Sandbox mode: runtime: direct, mode: off → you’re not in “sandbox jail”
Sandbox tool policy allowlist includes: exec, process, sessions_spawn, etc. (and sandbox policy doesn’t even apply when mode=off)
The Config path not found: tools.deny / tools.byProvider lines just mean those keys aren’t set in your config (that’s fine).

So when Mochi says “exec tool unavailable / tools degrading”, it’s almost certainly because the Kimi cloud model is not producing valid tool calls (or it just isn’t calling tools at all), not because OpenClaw “lost” the tools.

Do this quick A/B (it will prove it in 60 seconds)

In Telegram, switch to a local model you already have:

/model ollama/qwen2.5-coder:7b

Then ask Mochi:

#

run sleep 12; echo done using exec, then process poll until finished

If this works on qwen but fails on ollama/kimi-k2.5:cloud, then the problem is Kimi cloud tool-calling, not OpenClaw.

If Kimi cloud is the problem, here are your realistic options

Option 1 (pragmatic): use Kimi for chat, switch to qwen only when you need tools

In Telegram, you can do:

/model ollama/kimi-k2.5:cloud for normal conversation
/model ollama/qwen2.5-coder:7b right before “run scripts / git / scraper / multi-step”

No token cost, and tools become reliable.

Option 2 (try this workaround): run the “cloud” model via Ollama’s OpenAI-compatible API + disable streaming

Some backends break function/tool calling when streaming is on. This forces a different path:

On the Mac mini:

#

openclaw config set models.providers.ollama.baseUrl "http://127.0.0.1:11434/v1"
openclaw config set models.providers.ollama.api "openai-completions"
openclaw config set 'agents.defaults.models["ollama/kimi-k2.5:cloud"].params.streaming' false --strict-json
openclaw gateway restart

Then retry the same sleep 12 exec+poll in Telegram.

(That workaround is exactly what the Ollama provider docs warn about: OpenAI-compat endpoints can require streaming off for tool calling.)

One cleanup item (optional, but helps avoid “random” behavior)

Earlier you had fallbacks pointing at ollama-cloud/.... If that provider isn’t configured, remove the fallbacks so it doesn’t bounce:

openclaw config set agents.defaults.model.fallbacks '[]' --strict-json

#

openclaw gateway restart

If you do the A/B test, tell me: does the exec+process test work on qwen2.5-coder:7b? That will immediately tell us whether we should focus on OpenClaw config vs Kimi cloud limitations.

peak meteor Feb 26, 2026, 12:01 AM

#

whats the exact command to run with exec please include all of it so i dont mess up

autumn coveBOT Feb 26, 2026, 12:02 AM

#

In Telegram, you don’t type JSON — just ask Mochi to do it. Copy/paste this message exactly:

Message to send to Mochi:

Run this with the exec tool (not in plain text):

command: sleep 12; echo done
yieldMs: 1000

Then immediately poll it with the process tool until it finishes, and paste the final output here (including the sessionId and exit code).

If you want the “super explicit” version (so Mochi can’t wiggle out of it), paste this instead:

Use exec with:

#

- command = sleep 12; echo done
- yieldMs = 1000
(no other flags)

Then use process with:
- action = poll
- sessionId = (the one returned by exec)
Repeat poll until status is complete. Show the final stdout/stderr and exit status.

And if you want to run a real long command after that, the pattern is always:

exec with yieldMs: 1000 (or background: true)
process poll using the returned sessionId

Docs for the workflow: https://docs.openclaw.ai/tools/exec

peak meteor Feb 26, 2026, 12:03 AM

#

got this error Ollama API error 404: {"error":"model 'qwen2.5-coder:3b' not found"}

autumn coveBOT Feb 26, 2026, 12:03 AM

#

That error is coming from Ollama itself, not OpenClaw:

Ollama API error 404: model 'qwen2.5-coder:3b' not found

Meaning: your Ollama server at http://127.0.0.1:11434 simply doesn’t have that model pulled (or the name is wrong).

Option A (fastest): use a model you already have

From your earlier models.providers.ollama.models list, you do have:

qwen2.5-coder:7b
gemma2:2b

So in Telegram send one of these:

/model ollama/qwen2.5-coder:7b

#

(or)

/model ollama/gemma2:2b

Option B: install the model you tried to use

On the Mac mini terminal:

ollama pull qwen2.5-coder:3b

Then in Telegram:

#

/model ollama/qwen2.5-coder:3b

If you’re not sure what you have installed

Run on the Mac mini:

ollama list

(or OpenClaw view)

openclaw models list

#

Once you’ve switched to an installed model, re-run the exec test message (sleep 12; echo done + process poll).

peak meteor Feb 26, 2026, 12:04 AM

#

we can just user terminal for this stuff?

autumn coveBOT Feb 26, 2026, 12:04 AM

#

Yes — for debugging (and honestly for anything “run a long script / git / scraper”), using the Mac mini terminal directly is totally fine and often faster/more reliable than making the model drive exec/process.

If your goal is: “I want OpenClaw to be able to do it”, then tools have to work. But if your goal is: “I just need it done”, terminal wins.

What you can do from Terminal (Mac mini)

See what Ollama models you actually have installed:

ollama list

Pull the model you tried to use:

ollama pull qwen2.5-coder:3b

Quick test that your shell can run long commands (no OpenClaw involved):

#

sleep 12; echo done

If you still want OpenClaw to run terminal commands

Then we should keep using the exec → process poll pattern, but first ensure:

you’re using a model that actually exists (qwen2.5-coder:7b is installed in your config list)
and that the model reliably emits tool calls (Kimi cloud may not)

If you tell me which one you want:

“Just do it now” → I’ll give you the exact terminal commands for Pokémon scraper / Yahoo odds / etc.
“Make Mochi do it via tools” → we’ll keep A/B testing Kimi cloud vs local model until tool calling is stable.

peak meteor Feb 26, 2026, 12:06 AM

#

only kimi-k2 is an option

#

I just want the tools to just work

autumn coveBOT Feb 26, 2026, 12:08 AM

#

If “only kimi-k2 is an option” means it’s the only model that shows up in /model, that’s usually just because it’s the only one you’ve added to your model picker allowlist (or the only one Ollama reports as tool-capable).

You’ve got 3 realistic paths:

A) Keep paying for Kimi Cloud, but run scripts in Terminal

If your priority is “get work done”, this is the most reliable. OpenClaw tool-calling with Kimi Cloud is flaky in your setup right now.

B) Add a local tool-runner model just for tools (free), keep Kimi Cloud for chat

You can keep Kimi Cloud as your default, but switch models only when you need exec/process.

On the Mac mini, check what’s installed:

ollama list

Pick one installed model (example from your earlier list):

#

/model ollama/qwen2.5-coder:7b

If /model still doesn’t show it, you can force it to appear in the picker by adding it to agents.defaults.models:

openclaw config set 'agents.defaults.models["ollama/qwen2.5-coder:7b"]' '{"alias":"qwen7b"}' --strict-json
openclaw gateway restart

Then /model should list it.

C) If you insist on only Kimi Cloud for everything

Then you’re basically at the mercy of whether ollama/kimi-k2.5:cloud emits valid tool calls. OpenClaw isn’t blocking tools (your sandbox explain proved that), so if Mochi keeps saying “Tool not found / exec unavailable”, it’s the model/backend not producing a usable tool call.

Quick confirmation

#

Run in Telegram:

/model status (should be ollama/kimi-k2.5:cloud)
then ask it to do the exec sleep 12; echo done + process poll test

If it still won’t tool-call, the workaround is: Terminal or a second model for tool work.

If you paste your ollama list output, I can tell you which of your installed models is worth trying as the “tool runner” (smallest/fastest) while keeping Kimi Cloud as the default.

#

You can’t make tools “just work” with a model that doesn’t reliably emit valid tool calls.

From what you’ve shown:

OpenClaw is not sandboxing you (runtime: direct, mode: off)
exec + process are allowed
but Kimi Cloud sometimes doesn’t call tools / emits malformed tool calls, and then you see “Tool not found / tool unavailable” even though OpenClaw is fine.

The most reliable way to get to “tools just work” without paying per-token is:

Make Kimi your chat model, but add a local Ollama model as automatic fallback for tool runs

When Kimi botches a tool call, OpenClaw will retry on the fallback model.

1) Make sure you have a local tool-runner model installed

On the Mac mini:

#

ollama pull qwen2.5-coder:7b

2) Add it to OpenClaw’s model allowlist/picker

openclaw config set 'agents.defaults.models["ollama/qwen2.5-coder:7b"]' '{"alias":"qwen7b"}' --strict-json

3) Set it as a fallback (keep Kimi as primary)

openclaw config set agents.defaults.model.fallbacks '["ollama/qwen2.5-coder:7b"]' --strict-json
openclaw gateway restart

4) In Telegram

Start fresh and try your tool task again:

#

/new

Now: you’ll still be on ollama/kimi-k2.5:cloud most of the time, but tool-heavy stuff won’t get stuck when Kimi fails tool calling.

If you truly want only Kimi Cloud and no fallback, then there’s no config switch that guarantees tool reliability—because OpenClaw can only execute tools that the model actually calls correctly.

If you want, paste your ollama list output and I’ll pick the best “tool runner” model for your machine (small/fast but tool-capable).

peak meteor Feb 26, 2026, 12:10 AM

#

im on 16gb I cant run 7b

autumn coveBOT Feb 26, 2026, 12:12 AM

#

16GB isn’t the issue for ollama/kimi-k2.5:cloud (cloud models don’t use your RAM like local models do).

The real issue is: if Kimi Cloud sometimes doesn’t emit tool calls, the agent can’t reliably use exec/process on its own. With “only Kimi K2” available, the way to make commands “just work” is to run them via Gateway commands that bypass the model.

Make shell commands work from Telegram (reliable)

This enables ! <cmd> and !poll in Telegram (host shell, background + polling handled by OpenClaw, not the model).

1) Get your Telegram numeric user id

Run on the Mac mini:

openclaw logs --follow

Then DM your bot “hi” in Telegram and look for from.id in the logs.

(Reference: https://docs.openclaw.ai/help/faq#telegram-what-goes-in-allowfrom)

#

2) Enable bash commands + elevated allowlist for Telegram

Replace 123456789 with your Telegram from.id:

openclaw config set commands.bash true --strict-json
openclaw config set tools.elevated.enabled true --strict-json
openclaw config set 'tools.elevated.allowFrom.telegram' '[123456789]' --strict-json
openclaw gateway restart

3) Use it in Telegram

Send:

! sleep 12; echo done

#

Then poll:

!poll

You can stop a running one with:

!stop

This gives you reliable long commands + polling even if Kimi is flaky at tool-calling.

If you want, paste the from.id line you see in logs (you can redact other stuff) and I’ll format the exact openclaw config set ... commands with your real value.

peak meteor Feb 26, 2026, 12:14 AM

#

what I am saying you are asking for me to run a local model that I cant use

autumn coveBOT Feb 26, 2026, 12:14 AM

#

I’m not asking you to run a local model as your solution.

The “try qwen locally” thing was just an A/B test to prove whether Kimi Cloud is the one emitting broken tool calls. If you can’t (or don’t want to) run local models on 16GB, skip that.

You’ve basically got two ways to make “commands/tools” reliable while still keeping your paid Kimi Cloud model:

Option 1 (most reliable): run shell commands via Telegram `! ...` (bypasses the model)

This does not require any local LLM. It just lets you run commands on the Mac mini from Telegram, with background + polling handled by OpenClaw.

Step A — find your Telegram numeric user id

On the Mac mini:

openclaw logs --follow

DM your bot “hi” in Telegram, and in the logs look for from.id: 123456789.

Step B — enable bash + allow only you (Telegram)

#

Replace 123456789 with your real Telegram from.id:

openclaw config set commands.bash true --strict-json
openclaw config set tools.elevated.enabled true --strict-json
openclaw config set 'tools.elevated.allowFrom.telegram' '[123456789]' --strict-json
openclaw gateway restart

Step C — use it in Telegram

Run:

! sleep 12; echo done

Poll:

#

!poll

Stop:

!stop

This gives you “long scripts / git / scraper” reliability even if Kimi’s tool-calling is flaky.

Important: only do this if your Telegram bot is locked down to you (otherwise it’s basically remote shell access).

Option 2: keep using agent tools (`exec/process`) but change the Ollama API mode to reduce tool-call flakiness

This still uses Kimi Cloud, but routes via the OpenAI-compatible endpoint and turns off streaming for that model (some backends only behave that way).

#

openclaw config set models.providers.ollama.baseUrl "http://127.0.0.1:11434/v1"
openclaw config set models.providers.ollama.api "openai-completions"
openclaw config set 'agents.defaults.models["ollama/kimi-k2.5:cloud"].params.streaming' false --strict-json
openclaw gateway restart

Then test again from Telegram: ask Mochi to run sleep 12; echo done with exec and poll via process.

If you tell me your Telegram from.id (just the number), I’ll paste back the exact 3 openclaw config set ... commands with it filled in so you can copy/paste safely.

peak meteor Feb 26, 2026, 12:15 AM

#

I just want to user terminial to troubleshoot this please

autumn coveBOT Feb 26, 2026, 12:16 AM

#

Sure — if you want to use Terminal only (no “ask Mochi to tool-call”), do this checklist on the Mac mini. Copy/paste exactly.

1) Confirm versions + gateway health

openclaw --version
openclaw gateway status
openclaw status --all
openclaw doctor

If gateway status says RPC probe: failed, that’s the first thing to fix.

2) Confirm Ollama is reachable + what models exist

curl -s http://127.0.0.1:11434/api/tags | head -c 300 && echo
ollama list

#

You should see kimi-k2.5:cloud in ollama list.

3) Confirm OpenClaw’s Ollama provider config is correct (native API)

openclaw config get models.providers.ollama.baseUrl
openclaw config get models.providers.ollama.api
openclaw models status

You want:

baseUrl = http://127.0.0.1:11434
api = ollama

4) Reproduce one failure while watching logs

In one terminal window:

#

openclaw logs --follow

In another window (or after), send a Telegram message to the bot that should force a tool run (like “run sleep 12; echo done with exec then poll”), then watch for lines containing:

unknown tool
tool=
embedded run tool start
Ollama API error

If you want filtering:

openclaw logs --follow | egrep -i "unknown tool|tool=|tool start|tool end|ollama api error|exec|process"

5) If you just want a reliable remote shell from Telegram (terminal-driven setup)

This bypasses model tool-calling entirely, but still lets you run commands safely (only you).

#

First, find your Telegram numeric from.id by DMing the bot while openclaw logs --follow is running.

Then enable bash commands:

openclaw config set commands.bash true --strict-json
openclaw config set tools.elevated.enabled true --strict-json
openclaw config set 'tools.elevated.allowFrom.telegram' '[PASTE_YOUR_TELEGRAM_ID]' --strict-json
openclaw gateway restart

Then in Telegram you can do:

! sleep 12; echo done
!poll

Paste the output of (1) and the filtered log snippet from (4) (just the relevant lines), and I’ll tell you exactly what’s broken (gateway health vs Ollama vs model tool-call formatting).

peak meteor Feb 26, 2026, 12:26 AM

#

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

Docs: docs.openclaw.ai/sandbox

🦞 OpenClaw 2026.2.24 (df9a474) — End-to-end encrypted, drama-to-drama excluded.

Config path not found: tools.deny

🦞 OpenClaw 2026.2.24 (df9a474) — Hot reload for config, cold sweat for deploys.

Config path not found: tools.byProvider
djryan@DJs-Mac-mini ~ % ollama list
NAME ID SIZE MODIFIED
gemini-3-flash-preview:cloud ebade0d31690 - 10 hours ago
kimi-k2.5:cloud 6d1c3246c608 - 10 days ago
djryan@DJs-Mac-mini ~ % openclaw --version
openclaw gateway status
openclaw status --all
openclaw doctor
2026.2.24

🦞 OpenClaw 2026.2.24 (df9a474) — Your terminal just grew claws—type something and let the bot pinch the busywork.

│
◇
Service: LaunchAgent (loaded)
File logs: /tmp/openclaw/openclaw-2026-02-25.log
Command: /opt/homebrew/Cellar/node/25.6.1_1/bin/node /opt/homebrew/Cellar/openclaw-cli/2026.2.24/libexec/lib/node_modules/openclaw/dist/index.js gateway --port 18789
Service file: ~/Library/LaunchAgents/ai.openclaw.gateway.plist
Service env: OPENCLAW_GATEWAY_PORT=18789

Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Gateway: bind=loopback (127.0.0.1), port=18789 (service args)
Probe target: ws://127.0.0.1:18789
Dashboard: http://127.0.0.1:18789/
Probe note: Loopback-only gateway; only local clients can connect.

Runtime: running (pid 76856, state active)
RPC probe: ok

Listening: 127.0.0.1:18789
Troubles: run openclaw status
Troubleshooting: https://docs.openclaw.ai/troubleshooting

autumn coveBOT Feb 26, 2026, 12:27 AM

#

Your Gateway looks healthy:

Runtime: running
RPC probe: ok
listening on 127.0.0.1:18789

So this is not “OpenClaw tools are down”. It’s either:

the model isn’t calling tools (most likely with kimi-k2.5:cloud), or
you’re trying to use host-shell features but elevated isn’t allowlisted.

The key line you pasted is:

Elevated … allowedByConfig: false

That means OpenClaw’s “run host commands from chat” path is blocked until you explicitly allow your Telegram user id.

#

If you want to troubleshoot from Terminal and still run commands from Telegram reliably

This bypasses the model’s tool-calling entirely.

Step 1 — find your Telegram numeric user id

Run in Terminal:

openclaw logs --follow

Then DM your bot “hi” in Telegram. In the log output, look for from.id (a number).

Step 2 — allow only you to run host shell commands

Replace 123456789 with your real from.id:

#

openclaw config set commands.bash true --strict-json
openclaw config set tools.elevated.enabled true --strict-json
openclaw config set 'tools.elevated.allowFrom.telegram' '[123456789]' --strict-json
openclaw gateway restart

Step 3 — use it in Telegram

Now you can run:

! sleep 12; echo done

Then:

#

!poll

This gives you “long commands + polling” even if Kimi Cloud is flaky at tool calling.

If you want the agent to call `exec/process` by itself

You only have cloud models installed (kimi-k2.5:cloud and gemini-3-flash-preview:cloud). If Kimi doesn’t emit tool calls reliably, tools won’t “just work” no matter what OpenClaw config you change.

Do this A/B (still terminal-driven validation):

In Telegram:

/model ollama/gemini-3-flash-preview:cloud

#

Ask it to “run sleep 12; echo done via exec and poll with process”.
In Terminal, watch for actual tool usage:

openclaw logs --follow | egrep -i "tool start|tool end|unknown tool|tool=exec|tool=process|ollama api error"

If you never see tool start … tool=exec, the model simply didn’t call tools.

If you paste the single log line that contains your Telegram from.id, I’ll format the exact openclaw config set ... commands with your real number filled in.

peak meteor Feb 26, 2026, 12:29 AM

#

I dont want to do anything with telegram... i just want to use terminal so I can just copy and paste to fix this... its been 3 hours here lets find a fix ASAP

#

also I cant use gemini cloud it doesnt work with olama i dont think

autumn coveBOT Feb 26, 2026, 12:31 AM

#

Yep. If you want Terminal-only, here’s the fastest “stop the bleeding” path: (1) update OpenClaw, (2) remove the broken fallbacks, (3) prove exec/process work without the model, then (4) if the model still won’t tool-call, switch the default cloud model to the one that does.

Copy/paste in this order.

0) Backup your config (always do this first)

cp ~/.openclaw/openclaw.json ~/.openclaw/openclaw.json.bak.$(date +%F-%H%M%S)

1) Update OpenClaw (you’re on 2026.2.24; don’t debug for hours on a possibly-buggy build)

Recommended update path per docs is re-running the installer:

#

curl -fsSL https://openclaw.ai/install.sh | bash -s -- --no-onboard

Then:

openclaw --version
openclaw doctor
openclaw gateway restart
openclaw gateway status

(You want RPC probe: ok again.)

Docs: https://docs.openclaw.ai/install/updating

#

2) Clean up your model config (remove dead fallbacks that cause “random” behavior)

You previously had fallbacks like ollama-cloud/... but you don’t have that provider configured.

Set fallbacks to empty:

openclaw config set agents.defaults.model.fallbacks '[]' --strict-json
openclaw gateway restart

3) Confirm your Ollama provider config is the native one (you already fixed this, but lock it in)

openclaw config set models.providers.ollama.baseUrl "http://127.0.0.1:11434"
openclaw config set models.providers.ollama.api "ollama"

#

openclaw gateway restart

4) Prove `exec` works without any LLM (this isolates “tools broken” vs “model not calling tools”)

The Gateway has an HTTP endpoint to invoke tools directly.

First, see if you have a gateway token:

openclaw config get gateway.auth.token

If it prints a token, export it:

#

export OPENCLAW_GATEWAY_TOKEN="$(openclaw config get gateway.auth.token)"

If it’s empty/undefined, generate one (safe):

openclaw doctor --generate-gateway-token
export OPENCLAW_GATEWAY_TOKEN="$(openclaw config get gateway.auth.token)"

Now run a background exec via /tools/invoke:

curl -sS http://127.0.0.1:18789/tools/invoke \
  -H "Authorization: Bearer $OPENCLAW_GATEWAY_TOKEN" \
  -H "Content-Type: application/json" \

#

  -d '{"tool":"exec","args":{"command":"sleep 2; echo OK_FROM_EXEC","yieldMs":1000}}'

If that returns a sessionId, poll it:

# replace SESSION_ID with the value you got back
curl -sS http://127.0.0.1:18789/tools/invoke \
  -H "Authorization: Bearer $OPENCLAW_GATEWAY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"tool":"process","args":{"action":"poll","sessionId":"SESSION_ID","timeout":2000}}'

If this works, then OpenClaw tools are fine — your problem is the cloud model not emitting tool calls reliably.

Docs: https://docs.openclaw.ai/gateway/tools-invoke-http-api

#

5) If the model is the problem: switch to the other cloud model you already have

Your ollama list shows you also have:

gemini-3-flash-preview:cloud

Set it as the default model (still cloud, no local RAM issue):

openclaw config set agents.defaults.model.primary "ollama/gemini-3-flash-preview:cloud"
openclaw gateway restart

If you want to switch back later:

#

openclaw config set agents.defaults.model.primary "ollama/kimi-k2.5:cloud"
openclaw gateway restart

If you paste the output of step 4 (the exec invoke + poll result), I can tell you immediately whether you’re dealing with an OpenClaw tool/runtime problem (rare, since your gateway is healthy) or purely a model/tool-calling problem (common with some “cloud behind ollama” setups).

#

Yeah, you can ignore Gemini Cloud for now.

Two separate things here:

Whether Ollama can run gemini-3-flash-preview:cloud at all (that’s Ollama Cloud)
Whether OpenClaw can use a model for tools reliably (the model must emit valid tool calls)

If /model only ever shows ollama/kimi-k2.5:cloud, that usually means Gemini Cloud is not being detected as tool-capable, so it wouldn’t help your exec/process situation anyway.

ASAP “I just need it to work” fix (Terminal-only, no Telegram, no model tool-calls)

You can run exec + process directly via the Gateway HTTP API. This completely bypasses Mochi/Kimi tool-calling.

1) Ensure you have a gateway token

openclaw doctor --generate-gateway-token
export OPENCLAW_GATEWAY_TOKEN="$(openclaw config get gateway.auth.token)"

#

2) Start a long-ish command (backgrounds fast)

curl -sS http://127.0.0.1:18789/tools/invoke \
  -H "Authorization: Bearer $OPENCLAW_GATEWAY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"tool":"exec","args":{"command":"sleep 12; echo OK_FROM_EXEC","yieldMs":1000}}'

Copy the sessionId from that response.

3) Poll it

curl -sS http://127.0.0.1:18789/tools/invoke \
  -H "Authorization: Bearer $OPENCLAW_GATEWAY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"tool":"process","args":{"action":"poll","sessionId":"PASTE_SESSION_ID_HERE","timeout":2000}}'

#

If this works, your OpenClaw tools are fine; the flakiness is 100% “Kimi Cloud not emitting tool calls consistently”.

Docs: https://docs.openclaw.ai/gateway/tools-invoke-http-api

If you still want Mochi+Kimi to use tools (best shot, still Terminal-only)

Try routing Ollama through the OpenAI-compatible endpoint and disabling streaming for Kimi (some backends only behave this way):

cp ~/.openclaw/openclaw.json ~/.openclaw/openclaw.json.bak.$(date +%F-%H%M%S)

openclaw config set models.providers.ollama.baseUrl "http://127.0.0.1:11434/v1"
openclaw config set models.providers.ollama.api "openai-completions"
openclaw config set 'agents.defaults.models["ollama/kimi-k2.5:cloud"].params.streaming' false --strict-json
openclaw gateway restart

#

If it still produces “Tool not found” after that, there isn’t a config knob that will force Kimi Cloud to tool-call correctly — you’d need either a different cloud model that’s tool-reliable, or keep using the /tools/invoke approach above for scripts.

If you paste the JSON output from the first exec curl (step 2), I’ll tell you exactly what to paste into the poll command (and we can run a real script next).

peak meteor Feb 26, 2026, 12:33 AM

#

for step 1 I cant upgrade like that i am using homebrew

autumn coveBOT Feb 26, 2026, 12:34 AM

#

Yep — since you installed via Homebrew (your gateway status shows /opt/homebrew/Cellar/openclaw-cli/2026.2.24/...), use brew to update.

Copy/paste this whole block in Terminal:

brew update

# see if an update even exists
brew outdated | grep -i openclaw-cli || echo "openclaw-cli not outdated (already latest)"

# upgrade (no-op if already latest)
brew upgrade openclaw-cli

# make sure the launchd service points at the current install
openclaw doctor
openclaw gateway install --force

#

openclaw gateway restart

# verify
openclaw --version
openclaw gateway status

If brew outdated says you’re not outdated, then you’re already on the newest Homebrew build — upgrading won’t change the “tools flaky with kimi-k2.5:cloud” behavior, and the fastest “terminal-only” way to run long commands reliably is the Gateway /tools/invoke HTTP API (no Telegram/model tool-calls involved).

peak meteor Feb 26, 2026, 12:36 AM

#

ok i did that now what do I do?

autumn coveBOT Feb 26, 2026, 12:36 AM

#

Now we do a terminal-only proof that OpenClaw’s tools (exec + process) work, independent of Kimi.

1) Confirm you’re actually on the new version + gateway is healthy

Paste the output of:

openclaw --version
openclaw gateway status

2) Generate/confirm a gateway token (needed for the HTTP tool-invoke test)

Run:

openclaw doctor --generate-gateway-token
openclaw config get gateway.auth.token

#

If that prints a token, set it in your shell:

export OPENCLAW_GATEWAY_TOKEN="$(openclaw config get gateway.auth.token)"

3) Run `exec` via the Gateway HTTP API (no Telegram/model involved)

Copy/paste:

curl -sS http://127.0.0.1:18789/tools/invoke \
  -H "Authorization: Bearer $OPENCLAW_GATEWAY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"tool":"exec","args":{"command":"sleep 5; echo OK_FROM_EXEC","yieldMs":1000}}'

This will return JSON containing a sessionId. Copy it.

#

4) Poll the background session

Replace SESSION_ID and run:

curl -sS http://127.0.0.1:18789/tools/invoke \
  -H "Authorization: Bearer $OPENCLAW_GATEWAY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"tool":"process","args":{"action":"poll","sessionId":"SESSION_ID","timeout":2000}}'

Run the poll command a couple times until it finishes.

What this tells us

If steps 3–4 work → OpenClaw tools are fine, and the remaining problem is Kimi Cloud not calling tools reliably (model limitation).
If steps 3–4 fail → we have a real tool/runtime problem (then paste the exact JSON error, and we fix that next).

Reply with the JSON output from step 3 and the first poll result from step 4.

peak meteor Feb 26, 2026, 12:38 AM

#

it says openclaw redacted when i ran number 2

autumn coveBOT Feb 26, 2026, 12:42 AM

#

That’s normal. OpenClaw redacts secrets in console output, so openclaw config get gateway.auth.token won’t print the real token.

Fastest Terminal-only way around it: set (rotate) the token to a value you know, then use that for /tools/invoke. Do not paste the token back here.

Rotate the gateway token (copy/paste)

TOKEN="$(openssl rand -hex 32)"
openclaw config set gateway.auth.mode token
openclaw config set gateway.auth.token "$TOKEN"
openclaw gateway restart

# keep it in your shell for the curl tests
export OPENCLAW_GATEWAY_TOKEN="$TOKEN"

(Important: openclaw doctor --generate-gateway-token only sets a token if it’s missing; rotating an existing one requires setting gateway.auth.token like above.)

#

Now re-run the tool test (no model involved)

curl -sS http://127.0.0.1:18789/tools/invoke \
  -H "Authorization: Bearer $OPENCLAW_GATEWAY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"tool":"exec","args":{"command":"sleep 5; echo OK_FROM_EXEC","yieldMs":1000}}'

Copy the returned sessionId, then:

curl -sS http://127.0.0.1:18789/tools/invoke \
  -H "Authorization: Bearer $OPENCLAW_GATEWAY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"tool":"process","args":{"action":"poll","sessionId":"SESSION_ID_HERE","timeout":2000}}'

Paste the JSON output from those curl calls (but not the token).

peak meteor Feb 26, 2026, 12:44 AM

#

for step 1 i got this Config token differs from service token. The daemon will use the old token after restart.
Run openclaw gateway install --force to sync the token.

autumn coveBOT Feb 26, 2026, 12:44 AM

#

Yep — that message is exactly what happens on macOS when the Gateway is running as a LaunchAgent: the service can keep using the old token from its installed service metadata/env until you re-install the service file.

Do this in Terminal (and don’t paste the token here):

openclaw gateway install --force
openclaw gateway restart
openclaw gateway status

Then re-export the token you just set (the known one you generated) in your current shell:

export OPENCLAW_GATEWAY_TOKEN="$TOKEN"

…and rerun the /tools/invoke curl test.

#

If you still get 401/unauthorized after that, paste:

openclaw gateway status
(and the curl response body, without the token)

peak meteor Feb 26, 2026, 12:47 AM

#

still no token given

autumn coveBOT Feb 26, 2026, 12:47 AM

#

openclaw is hiding the token on purpose (redaction), so you will not see it printed in the terminal. That’s why it feels like “no token given”.

Do one of these terminal-only paths:

Option A (recommended): set a token you control + use it (no need to ever “print” it)

Copy/paste this whole block:

# 1) Create a new token and save it locally (so you don't lose it between shells)
TOKEN_FILE="$HOME/.openclaw/gateway.token"
umask 077
TOKEN="$(/usr/bin/openssl rand -hex 32)"
printf "%s" "$TOKEN" > "$TOKEN_FILE"

# 2) Write token into OpenClaw config
openclaw config set gateway.auth.mode token

#

openclaw config set gateway.auth.token "$TOKEN"

# 3) Sync launchd service metadata + restart (important on macOS)
openclaw gateway install --force
openclaw gateway restart
openclaw gateway status

# 4) Export for curl calls in THIS shell
export OPENCLAW_GATEWAY_TOKEN="$TOKEN"
echo "Token saved to: $TOKEN_FILE (do not paste it into chat)"

Now run the tool test (this is the whole point):

#

curl -sS http://127.0.0.1:18789/tools/invoke \
  -H "Authorization: Bearer $OPENCLAW_GATEWAY_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"tool":"exec","args":{"command":"sleep 2; echo OK_FROM_EXEC","yieldMs":1000}}'

Paste the curl JSON output here (it won’t include your token).

If you open a new terminal later, reload the token with:

export OPENCLAW_GATEWAY_TOKEN="$(cat "$HOME/.openclaw/gateway.token")"

Option B (fastest for debugging): temporarily disable gateway auth on loopback

#

Since you’re bound to 127.0.0.1 only, you can do:

openclaw config set gateway.auth.mode none
openclaw gateway install --force
openclaw gateway restart

Then your curl becomes:

curl -sS http://127.0.0.1:18789/tools/invoke \
  -H "Content-Type: application/json" \
  -d '{"tool":"exec","args":{"command":"sleep 2; echo OK_FROM_EXEC","yieldMs":1000}}'

(After you’re done debugging, set auth back to token.)

#

Tell me which option you chose, and paste the curl response you get. That will confirm whether exec/process work at the Gateway level, independent of Kimi.

peak meteor Feb 26, 2026, 12:50 AM

#

got this error : curl -sS http://127.0.0.1:18789/tools/invoke
-H "Content-Type: application/json"
-d '{"tool":"exec","args":{"command":"sleep 2; echo OK_FROM_EXEC","yieldMs":1000}}'
{"ok":false,"error":{"type":"not_found","message":"Tool not available: exec"}}%

autumn coveBOT Feb 26, 2026, 12:53 AM

#

That {"type":"not_found","message":"Tool not available: exec"} from POST /tools/invoke is expected.

Why: /tools/invoke only exposes the Gateway “OpenClaw tools” (things like sessions_list, session_status, etc.). It does not expose the runtime tools exec / process over that HTTP endpoint, so it 404s even though exec works fine when a model calls it in-chat.

So: stop using /tools/invoke to test exec — it will never work.

Fastest fix that makes “run long scripts” work (no local model required)

Since Kimi Cloud is flaky at actually calling tools, bypass the model entirely and use OpenClaw’s built-in bash chat command (! ... / /bash ...). That runs on the Mac host and supports polling, without relying on Kimi to emit tool calls.

1) Get your Telegram numeric user id (one-time)

Terminal:

openclaw logs --follow

Then DM your bot “hi” in Telegram and look for from.id=123456789 in the logs.

2) Enable bash + allow only your Telegram id (Terminal-only config)

#

Replace 123456789 with your from.id:

openclaw config set commands.bash true --strict-json
openclaw config set tools.elevated.enabled true --strict-json
openclaw config set 'tools.elevated.allowFrom.telegram' '[123456789]' --strict-json

# macOS launchd needs a re-install to sync service metadata
openclaw gateway install --force
openclaw gateway restart

3) Use it (in Telegram)

Run:

! sleep 12; echo done

#

Then:

!poll

This gets you “long scripts / git / scraper” reliability immediately, even if kimi-k2.5:cloud keeps refusing to tool-call.

If you want, paste the single from.id line from your logs (just the number is enough) and I’ll rewrite the exact 3 commands with your real value filled in.

peak meteor Feb 26, 2026, 12:56 AM

#

can we remove the imessage skill im not using that yet

autumn coveBOT Feb 26, 2026, 12:56 AM

#

Yep. That log spam is coming from the iMessage channel trying to read ~/Library/Messages/chat.db. If you’re not using iMessage yet, just disable the channel in config.

Run in Terminal:

openclaw config set channels.imessage.enabled false --strict-json
openclaw gateway restart

(Optional sanity check)

openclaw config get channels.imessage
openclaw status --all

If you want to remove the whole iMessage config block (instead of just disabling it), you can do:

#

openclaw config unset channels.imessage
openclaw gateway restart

You can always re-enable later (either by re-running onboarding or setting channels.imessage.enabled true).

peak meteor Feb 26, 2026, 12:57 AM

#

okay thats done now what do we do

autumn coveBOT Feb 26, 2026, 12:58 AM

#

Good — with iMessage off, your logs won’t be drowning anymore.

Now we do the fastest path to “run long commands reliably” without depending on Kimi to emit tool calls:

1) Enable the host shell command from chat (`! ...`) and allow only you

A) Find your Telegram numeric user id

Run in Terminal:

openclaw logs --follow

Then DM your bot anything in Telegram (like “hi”). In the logs you’ll see from.id=123456789 (a number). Copy that number.

B) Put that number into config (Terminal)

Replace 123456789 with your actual id:

#

openclaw config set commands.bash true --strict-json
openclaw config set tools.elevated.enabled true --strict-json
openclaw config set 'tools.elevated.allowFrom.telegram' '[123456789]' --strict-json
openclaw gateway install --force
openclaw gateway restart

2) Test it

In Telegram, send:

! sleep 12; echo done

Then:

#

!poll

If that works, you’ve solved the “>5 seconds times out / can’t poll / background processes” pain immediately.

If you paste your from.id number here, I’ll give you the exact commands with it filled in so you can just paste once.

peak meteor Feb 26, 2026, 1:00 AM

#

I see a session Id but not a from.id

autumn coveBOT Feb 26, 2026, 1:00 AM

#

You’re looking at the wrong field.

sessionId=... is OpenClaw’s internal run/session id.
from.id is the Telegram sender’s numeric user id (what OpenClaw uses for allowlists).

Do this to make it obvious:

1) Run a filtered log follow (Terminal)

openclaw logs --follow | egrep -i "telegram|from\\.id|from\\.username|message\\.from|chat\\.id|update"

2) DM your bot in Telegram

Send “hi” (or anything).

You should then see a line containing something like:

from.id: 123456789

#

(or similar JSON with "from":{"id":123456789,...})

If you still don’t see it, two possibilities:

Telegram diagnostics aren’t being logged at your current log level, or
your bot isn’t actually receiving Telegram messages at the gateway you’re tailing.

Quick check (Terminal)

openclaw status --deep

If needed: temporarily turn on more Telegram log detail

In your current terminal session (one-off, doesn’t edit config):

OPENCLAW_LOG_LEVEL=debug openclaw logs --follow | egrep -i "telegram|from\\.id|update"

#

Once you get the numeric from.id, paste just the number here and I’ll give you the exact 3 openclaw config set ... commands with it filled in.

peak meteor Feb 26, 2026, 1:00 AM

#

what about this

#

diagnostic {"subsystem":"diagnostic"} run registered: sessionId=17d4c5e9-8d4d-4174-a7cb-05f242a0d6ee totalActive=1
00:59:41 debug agent/embedded {"subsystem":"agent/embedded"} embedded run prompt start: runId=fe3c6354-6ff5-4980-a54b-2dd2a280d086 sessionId=17d4c5e9-8d4d-4174-a7cb-05f242a0d6ee
00:59:41 debug agent/embedded {"subsystem":"agent/embedded"} embedded run agent start: runId=fe3c6354-6ff5-4980-a54b-2dd2a280d086
00:59:43 debug agent/embedded {"subsystem":"agent/embedded"} embedded run agent end: runId=fe3c6354-6ff5-4980-a54b-2dd2a280d086 isError=false
00:59:43 debug agent/embedded {"subsystem":"agent/embedded"} embedded run prompt end: runId=fe3c6354-6ff5-4980-a54b-2dd2a280d086 sessionId=17d4c5e9-8d4d-4174-a7cb-05f242a0d6ee durationMs=1579
00:59:43 debug diagnostic {"subsystem":"diagnostic"} run cleared: sessionId=17d4c5e9-8d4d-4174-a7cb-05f242a0d6ee totalActive=0
00:59:43 debug agent/embedded {"subsystem":"agent/embedded"} embedded run done: runId=fe3c6354-6ff5-4980-a54b-2dd2a280d086 sessionId=17d4c5e9-8d4d-4174-a7cb-05f242a0d6ee durationMs=2180 aborted=false
00:59:43 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=main durationMs=2183 active=0 queued=0
00:59:43 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=session:agent:main:telegram:direct:6471395025 durationMs=2191 active=0 queued=0
00:59:43 info gateway/channels/telegram {"subsystem":"gateway/channels/telegram"} telegram sendMessage ok chat=6471395025 message=1435

autumn coveBOT Feb 26, 2026, 1:01 AM

#

Depends what “this” is — paste the exact line you’re looking at.

Quick rule:

If it contains sessionId=... (or runId=...) → that’s not your Telegram user id.
What we need is your Telegram sender id, usually shown as from.id (a number).

Fastest Terminal-only way to get your Telegram `from.id` (no OpenClaw logs needed)

DM your bot something in Telegram (like “hi”), so there’s a fresh update.
On the Mac mini, run this (replace <BOT_TOKEN> with your bot token locally, don’t paste it here):

curl -s "https://api.telegram.org/bot<BOT_TOKEN>/getUpdates" | python3 - <<'PY'
import sys, json
data=json.load(sys.stdin)
# find the last message update that has a from.id

#

for upd in reversed(data.get("result", [])):
    msg = upd.get("message") or upd.get("edited_message") or upd.get("channel_post")
    if msg and "from" in msg and "id" in msg["from"]:
        print(msg["from"]["id"])
        break
PY

That printed number is what you put into:

openclaw config set 'tools.elevated.allowFrom.telegram' '[YOUR_ID]' --strict-json

If you paste the log line you meant by “this”, I’ll tell you whether it already contains the from.id or not.

#

Yes — that last line gives you what we need.

This is your Telegram chat id:

lane=session:agent:main:telegram:direct:6471395025
and also telegram sendMessage ok chat=6471395025

For DMs, that number is typically the same as your from.id and it’s good enough to lock down elevated access.

Now copy/paste this in Terminal (replace nothing — use your number):

openclaw config set commands.bash true --strict-json
openclaw config set tools.elevated.enabled true --strict-json
openclaw config set 'tools.elevated.allowFrom.telegram' '[6471395025]' --strict-json
openclaw gateway install --force

#

openclaw gateway restart

Then in Telegram, try:

! sleep 12; echo done

and poll:

!poll

If that works, you now have a reliable way to run long commands + polling (git, scrapers, etc.) without depending on Kimi Cloud’s tool-calling.

#

If it doesn’t, paste the exact Telegram error output from the bot after you send ! sleep 12; echo done.

peak meteor Feb 26, 2026, 1:03 AM

#

Approval required (id 896916fa). Approve to run; updates will arrive after completion.

autumn coveBOT Feb 26, 2026, 1:03 AM

#

Perfect — that means the ! ... host-shell path is working now. You just hit the exec approvals safety layer.

Approve it from chat (Telegram) with:

/approve 896916fa allow-once

If you don’t want to approve every time, you can do:

/approve 896916fa allow-always

After you approve, run:

#

!poll

…and you should see the done output when the command finishes.

(If you want, paste what command it’s asking to run, and I’ll tell you whether “allow-always” is a good idea or if you should keep it as allow-once.)

peak meteor Feb 26, 2026, 1:04 AM

#

got this error Failed to submit approval: Error: unknown approval id

autumn coveBOT Feb 26, 2026, 1:11 AM

#

That “unknown approval id” is happening because the message you saw only shows the short slug (896916fa). /approve needs the full approval UUID, not the slug.

Fast fix: turn on exec approval forwarding so Telegram receives a message that includes the full ID: <uuid>.

1) Enable approval forwarding (Terminal)

Copy/paste:

openclaw config set approvals.exec.enabled true --strict-json
openclaw config set approvals.exec.mode "session" --strict-json
openclaw gateway restart

(Optional but nice: limit to your main agent)

openclaw config set approvals.exec.agentFilter '["main"]' --strict-json

#

openclaw gateway restart

2) Re-run the command in Telegram

Send again:

! sleep 12; echo done

Now you should receive a new message that looks like:

🔒 Exec approval required
ID: 123e4567-e89b-12d3-a456-426614174000
...
Reply with: /approve <id> allow-once|allow-always|deny

#

3) Approve using the FULL ID (not the slug)

Copy the full UUID from that message and send:

/approve <FULL_UUID_HERE> allow-once

Then:

!poll

If you still don’t get the forwarded “🔒 Exec approval required” message after step 1, paste your openclaw config get approvals output.

peak meteor Feb 26, 2026, 1:12 AM

#

is it possible to just wipe everything and start over?

autumn coveBOT Feb 26, 2026, 1:14 AM

#

Yes — OpenClaw has a built-in “wipe local state and start over” command.

Safer first: see what would be deleted

Run:

openclaw reset --dry-run

If you truly want “nuke it from orbit” (config + creds + sessions + state dir + workspace)

This keeps the Homebrew-installed CLI, but wipes OpenClaw’s local data:

# optional backup (recommended)
cp -R ~/.openclaw ~/.openclaw.bak.$(date +%F-%H%M%S)

#

# full wipe
openclaw reset --scope full --yes --non-interactive

Then re-onboard (recreates config and reinstalls/re-syncs the daemon):

openclaw onboard --install-daemon

If you want a “medium reset” (often enough)

Wipes config + credentials + sessions, but keeps the workspace:

openclaw reset --scope config+creds+sessions --yes --non-interactive

#

openclaw onboard --install-daemon

If you tell me which one you want (full vs medium), I’ll tell you exactly what you’ll need to re-enter afterwards (Telegram bot token, Ollama Cloud setup, etc.).

peak meteor Feb 26, 2026, 1:14 AM

#

medium

autumn coveBOT Feb 26, 2026, 1:14 AM

#

Do the medium reset (config + creds + sessions), then re-onboard.

Copy/paste in Terminal:

# optional: backup your current config
cp ~/.openclaw/openclaw.json ~/.openclaw/openclaw.json.bak.$(date +%F-%H%M%S) 2>/dev/null || true

# wipe config + creds + sessions (keeps workspace)
openclaw reset --scope config+creds+sessions --yes --non-interactive

# re-run onboarding + re-install/sync the LaunchAgent
openclaw onboard --install-daemon

# verify gateway is healthy
openclaw gateway status

#

openclaw status --all

After onboarding, you’ll need to re-add:

your Telegram bot token (or redo Telegram setup in the wizard)
your Ollama/Ollama Cloud provider config (Kimi Cloud)

Once you’re back up, the first “sanity” test is just:

in Telegram: /new then try a short tool task
and in Terminal: openclaw logs --follow to confirm tool calls are actually happening (you’ll see embedded run tool start ... tool=exec when it’s real).

If you get stuck in the wizard at any prompt, paste the prompt text and I’ll tell you what to pick.

peak meteor Feb 26, 2026, 1:20 AM

#

would that fix my issue after we did the medium reset?

autumn coveBOT Feb 26, 2026, 1:20 AM

#

It can fix it, but only if your problem was caused by bad/stale config + session state (which it very likely was, given all the “sandbox vs gateway”, broken fallbacks, approvals config, iMessage noise, etc.).

What the medium reset actually does (per openclaw reset --scope config+creds+sessions):

deletes ~/.openclaw/openclaw.json (your config)
deletes OAuth creds store (channel/provider creds)
deletes session stores (so you start with clean sessions)
keeps your workspace + installed CLI

So after the reset, the key is: during openclaw onboard --install-daemon, configure only the minimum:

Telegram (so you can talk to the bot)
Ollama provider pointed at http://127.0.0.1:11434 with api: ollama
Select ollama/kimi-k2.5:cloud as the model

Then test tools with something simple:

in Telegram: ask it to run sleep 5; echo done (tool use)
in Terminal: openclaw logs --follow and confirm you see embedded run tool start ... tool=exec

#

But: if Kimi Cloud itself is the issue…

If after a clean reset Kimi Cloud still doesn’t emit tool calls reliably, a reset won’t magically change that. In that case the “real” fix is:

use the ! bash command path (reliable, but needs approvals), or
use a different model for tool-heavy tasks.

If you want a hard yes/no after the reset: paste the first 30 lines of your new openclaw status --all and the first tool failure log snippet (if any). That will tell us immediately whether it’s config/state vs model behavior.

peak meteor Feb 26, 2026, 1:21 AM

#

I have openclaw access not configured ask the bot owner to apporive with

#

for telegram sorry

autumn coveBOT Feb 26, 2026, 1:24 AM

#

That message is DM pairing, not “tools broken”.

After the medium reset, your Telegram DMs are in dmPolicy: pairing, so the bot won’t process anything until you approve your sender once.

Fix (Terminal-only)

In the chat where you got that message, copy the 8‑character Pairing code (it will say Pairing code: ABCD1234).
On the Mac mini run:

openclaw pairing list telegram
openclaw pairing approve telegram <PASTE_CODE_HERE> --notify

DM the bot again in Telegram — it should reply normally now.

Docs: https://docs.openclaw.ai/channels/pairing#approve-a-sender

#

If pairing list telegram shows nothing, paste the exact “Pairing code: …” block you received (you can redact other lines).

#

Yep — for Telegram pairing, it’s the same commands, just with telegram.

Do this on the Mac mini:

List pending pairing requests (so you can see the code + your id):

openclaw pairing list telegram

Approve the 8‑char code you were shown in Telegram:

openclaw pairing approve telegram <PAIRING_CODE_HERE> --notify

After that, DM the bot again in Telegram and it should start responding normally.

If pairing list telegram shows nothing, paste the Pairing code line you got in Telegram and we’ll approve it directly.

peak meteor Feb 26, 2026, 1:27 AM

#

openclaw pairing approve telegram <PAIRING_CODE_HERE> --notify doesnt work whats the correct command

autumn coveBOT Feb 26, 2026, 1:27 AM

#

The correct syntax is two positional args: <channel> <code>.

So it should look like this (replace the code, don’t include < > — in zsh those are redirection):

openclaw pairing approve telegram ABCD1234 --notify

Alternative equivalent form (sometimes easier to avoid argument confusion):

openclaw pairing approve --channel telegram ABCD1234 --notify

Before approving, you can confirm what’s pending:

#

openclaw pairing list telegram

If it still “doesn’t work”, paste the exact error output from the terminal (one line is fine).

peak meteor Feb 26, 2026, 1:28 AM

#

telegram is paired now

autumn coveBOT Feb 26, 2026, 1:28 AM

#

Nice — now you’re past the pairing gate.

Next, let’s confirm whether your original pain (“long commands / polling / background”) is fixed:

In Telegram, start clean:

/new

Test a long command via the bash command (this bypasses Kimi tool-calling flakiness):

! sleep 12; echo done

If it asks for approval, you’ll need to approve it (and we can then tweak approvals/allowlist so you don’t have to keep doing that).

Then poll:

#

!poll

If you paste what it replies after ! sleep 12; echo done (especially if it’s an approval prompt), I’ll tell you the fastest way to make it non-annoying while keeping it safe.

peak meteor Feb 26, 2026, 1:29 AM

#

it said bash is disabled

autumn coveBOT Feb 26, 2026, 1:30 AM

#

That’s just config — after the medium reset, commands.bash went back to the default (false), so ! ... is disabled again.

Run this on your Mac mini (Terminal):

openclaw config set commands.bash true --strict-json
openclaw config set tools.elevated.enabled true --strict-json
openclaw config set 'tools.elevated.allowFrom.telegram' '[6471395025]' --strict-json

# macOS LaunchAgent needs a re-install to sync service config
openclaw gateway install --force
openclaw gateway restart

Then in Telegram try:

#

! sleep 2; echo ok

If you’re not 100% sure 6471395025 is your Telegram DM id after the reset: run openclaw logs --follow, send any message to the bot in Telegram, and copy the number from the telegram:direct:<NUMBER> lane line.

peak meteor Feb 26, 2026, 1:31 AM

#

it asked for approval

autumn coveBOT Feb 26, 2026, 1:32 AM

#

Good — that means bash is enabled and working now. The approval prompt is the normal safety layer.

What to do right now

Approve once (safest):

If the message included a full approval ID: ... (a UUID), reply in Telegram with:

/approve <FULL_UUID> allow-once

Then:

!poll

If you only see a short id like `896916fa`

That’s the slug, not the full id, and /approve will fail. Turn on approval forwarding so Telegram shows the full UUID:

#

openclaw config set approvals.exec.enabled true --strict-json
openclaw config set approvals.exec.mode "session" --strict-json
openclaw gateway restart

Then rerun:

! sleep 12; echo done

and you’ll get a forwarded approval message that contains ID: <uuid> — use that in /approve ... allow-once.

If you paste the approval message text you received (you can redact the command if you want), I’ll tell you whether it has the full UUID or only the slug.

peak meteor Feb 26, 2026, 1:35 AM

#

got this 🔒 Exec approval required
ID: 2ada30e5-1c09-42fd-9cf4-d2ec3d666e13
Command: sleep 12; echo done
CWD: /
Host: gateway
Agent: main
Security: allowlist
Ask: on-miss
Expires in: 120s
Reply with: /approve <id> allow-once|allow-always|deny

autumn coveBOT Feb 26, 2026, 1:35 AM

#

Perfect — that’s the full approval ID. Approve it once:

In Telegram send:

/approve 2ada30e5-1c09-42fd-9cf4-d2ec3d666e13 allow-once

Then poll:

!poll

You should see done when it finishes.

If you want fewer approvals going forward

#

Right now you’re in Security: allowlist + Ask: on-miss, so anything with shell operators (;, &&, |, etc.) will usually require approval.

Two options:

Keep it safe and just approve once when needed (recommended).
Add a small allowlist entry so simple stuff like sleep/echo doesn’t prompt every time. You can do that from Terminal with:

openclaw approvals allowlist add --agent main "/bin/sleep"
openclaw approvals allowlist add --agent main "/bin/echo"

(Then restart isn’t usually necessary, but if it still prompts, do openclaw gateway restart.)

Run the approve + poll now and tell me what !poll returns.

peak meteor Feb 26, 2026, 1:37 AM

#

no active bash job

autumn coveBOT Feb 26, 2026, 1:38 AM

#

That’s expected with the approval flow.

What happened:

! sleep 12; echo done triggered an exec approval.
The !//bash command handler doesn’t track “approval‑pending” jobs as an “active bash job”, because it never got a sessionId back at start time.
So !poll has nothing to poll and says “no active bash job”.

The command should still run after you approve, and you should get an “Exec finished …” message when it completes.

Make `!poll` work (avoid approvals by allowlisting the binaries)

Since this is your box and you’re only allowing yourself on Telegram, add a couple safe allowlist entries so basic commands don’t prompt.

Run on the Mac mini:

#

openclaw approvals allowlist add --gateway --agent main "$(which sleep)"
openclaw approvals allowlist add --gateway --agent main "$(which echo)"

Then try again in Telegram:

! sleep 12; echo done

This time it should reply something like “bash started (session …)”. Then !poll will work.

Quick check

If you want to confirm the allowlist is on the gateway side:

#

openclaw approvals get --gateway

Also: did /approve ... allow-once reply with a ✅ success message? If it didn’t, paste that reply.

peak meteor Feb 26, 2026, 1:40 AM

#

I honestly think its working if it was able to get my emails

autumn coveBOT Feb 26, 2026, 1:40 AM

#

If it was able to read your emails, that’s a good sign that:

the gateway is healthy
basic tools + channel delivery are working again

The remaining “tools feel broken” part was mostly:

DM pairing/approvals/security gates (expected after reset)
Kimi Cloud sometimes not emitting tool calls (so it “talks about” tools instead of using them)

At this point I’d do two quick confirmations:

Long command path (reliable): in Telegram run:

! echo OK

If it prompts for approval too often, add allowlist entries for echo/sleep like we discussed.

#

Agent tool-calling (Kimi): ask Mochi something that forces file ops (read/write) and see if it actually calls tools or just narrates.

If you want, tell me which email integration you mean (Gmail? IMAP? something else) and what command you want the bot to be able to run reliably (git? scraper? cron). Then we can tighten just those approvals/allowlists so you’re not clicking “approve” all day.

peak meteor Feb 26, 2026, 1:41 AM

#

I am also using open router free this time

autumn coveBOT Feb 26, 2026, 1:42 AM

#

If you’re on OpenRouter free, expect exactly the kind of “sometimes tools work, sometimes it just talks / errors” behavior you were seeing.

Two reasons:

Free-tier models/endpoints are often rate-limited or inconsistent (so long multi-step tool chains fall apart).
Some models on OpenRouter are not great at tool calling (they’ll omit tool names, or just refuse to call tools and “explain” instead).

If your goal is “tools just work”

Make sure your primary model is your paid Ollama Cloud Kimi, and don’t let OpenRouter free be a fallback for tool-heavy work.

Check what you’re actually using:

In Telegram:
```
/model status
```
In Terminal:

#

  openclaw config get agents.defaults.model
  openclaw models status

If agents.defaults.model.fallbacks includes any openrouter/... entries, the bot can silently switch to OpenRouter during a run and then tools get flaky.

Quick “stability” setting (Terminal)

If you want, paste your openclaw config get agents.defaults.model output (it won’t include secrets), and I’ll tell you the exact one-liner to pin primary to Kimi and remove the OpenRouter free fallback.

peak meteor Feb 26, 2026, 1:43 AM

#

im going to try to switch to the kimi model again and see what happens

autumn coveBOT Feb 26, 2026, 1:43 AM

#

Do it — and verify it actually stuck.

In Telegram

Start fresh:

/new

Switch model explicitly:

/model ollama/kimi-k2.5:cloud

Confirm:

/model status

#

You want it to show ollama/kimi-k2.5:cloud as the active model (not openrouter).

Then run one simple tool test

Ask Mochi:

“Create a file tooltest.txt with hello and then read it back.”

If it actually uses write + read, we’re good. If it narrates / refuses / errors, paste the exact output + (if possible) the relevant lines from openclaw logs --follow.

If it keeps snapping back to OpenRouter, we’ll remove OpenRouter from your fallbacks in config so it can’t silently swap mid-run.

peak meteor Feb 26, 2026, 1:45 AM

#

its not there so Im going to run the command from ollama to add it

#

how do we remove openrouter/auto?

autumn coveBOT Feb 26, 2026, 1:49 AM

#

Yep — if ollama/kimi-k2.5:cloud isn’t showing up, do this from Terminal:

1) Make sure Ollama actually has the model

ollama list | grep -i kimi || true

If it’s missing, pull it:

ollama pull kimi-k2.5:cloud

2) Tell OpenClaw to use it as the default (no guessing, no picker needed)

openclaw models set ollama/kimi-k2.5:cloud
openclaw gateway restart

#

openclaw models status

3) In Telegram, verify it stuck

Send:

/new
/model status

If it still won’t appear in /model list, that’s usually because OpenClaw’s Ollama auto-discovery only lists models that report tool support. You can still run it as the default model (step 2), but it may not tool-call reliably — in that case use the ! ... bash path for long commands.

#

Yes — openrouter/auto is just a model ref that got set as your primary and/or a fallback. Remove it from both.

Run these in Terminal:

1) See where it’s coming from

openclaw models status
openclaw models fallbacks list

2) Set your primary back to Kimi Cloud

openclaw models set ollama/kimi-k2.5:cloud

3) Remove OpenRouter auto from fallbacks (if present)

#

openclaw models fallbacks remove openrouter/auto
# or just nuke all fallbacks:
# openclaw models fallbacks clear

4) Restart gateway

openclaw gateway restart
openclaw models status

Optional (if you want to disable OpenRouter entirely so it can’t be used at all):

openclaw config unset models.providers.openrouter
openclaw gateway restart

peak meteor Feb 26, 2026, 1:52 AM

#

how can I set it to use openrouter/openrouter/free for small task like chat and all that and then ollama/kimi-k2.5:cloud for heavy task?

autumn coveBOT Feb 26, 2026, 1:57 AM

#

You can’t make OpenClaw automatically “detect heavy vs light” and switch models based on task complexity (there’s no built-in router for that). But you can get 95% of what you want with a clean workflow:

Best setup: default = OpenRouter free, switch to Kimi when you need tools/heavy work

1) Create model aliases (so switching is easy)

Run in Terminal:

openclaw models aliases add chat openrouter/openrouter/free
openclaw models aliases add heavy ollama/kimi-k2.5:cloud

2) Set the default model to the “chat” one

openclaw models set chat
openclaw gateway restart

#

3) (Optional but recommended) Make Kimi a fallback when OpenRouter free flakes/rate-limits

openclaw models fallbacks clear
openclaw models fallbacks add heavy
openclaw gateway restart

This won’t switch because a task is “heavy” — it switches when the primary fails.

4) In Telegram: switch per-session when needed

Normal chat:
```
/model chat
```
When you’re about to run tools / long scripts / multi-step work:

#

  /model heavy

Verify any time with:

/model status

Important note

OpenRouter free is often fine for chat, but it’s exactly the kind of setup that can be inconsistent at tool-calling. So the rule of thumb is:

chat → openrouter/openrouter/free
tools/heavy → ollama/kimi-k2.5:cloud (or use ! ... bash commands)

If you run openclaw models status and paste the top part (primary + fallbacks), I can sanity-check that it’s pinned the way you expect.

peak meteor Feb 26, 2026, 2:01 AM

#

so I see this as an aliases OpenRouter -> openrouter/auto i dont ever want to switch to this, can it be removed or it has to be there because I have openrouter free?

autumn coveBOT Feb 26, 2026, 2:01 AM

#

You can remove it. It’s not required just because you have OpenRouter free.

What’s happening is: OpenClaw ships with (or you created) an alias like:

OpenRouter → openrouter/auto

That alias is just a convenience, and it can cause the model picker to jump to openrouter/auto if you select “OpenRouter”.

Remove the alias

First list aliases so you get the exact alias name:

openclaw models aliases list

Then remove it (example assumes the alias is literally OpenRouter):

#

openclaw models aliases remove OpenRouter

Restart not strictly required, but safe:

openclaw gateway restart

Also make sure it can’t be used as a fallback

openclaw models fallbacks remove openrouter/auto
# or clear all fallbacks if you prefer:
# openclaw models fallbacks clear

#

Keep OpenRouter free without `auto`

Set your chat alias to the exact model you want (example):

openclaw models aliases add chat openrouter/openrouter/free
openclaw models set chat
openclaw gateway restart

If you paste the output of openclaw models aliases list, I’ll tell you the exact aliases remove ... command with the right capitalization.

peak meteor Feb 26, 2026, 2:04 AM

#

OpenRouter -> openrouter/auto

autumn coveBOT Feb 26, 2026, 2:04 AM

#

Yep — you can remove that alias.

Run this in Terminal:

openclaw models aliases remove OpenRouter

Then (optional) make sure nothing still points at openrouter/auto:

openclaw models fallbacks remove openrouter/auto
openclaw models status

If you want a “safe” replacement alias so the picker still has something friendly:

#I cannot access tools with open claw

1) First: paste these (they’re the fastest way to pinpoint which bucket you’re in)

2) Why exec “works under ~5s” but not longer

3) Why sessions_spawn can be “completely broken”

4) One more quick check (often revealing)

5) If you see any “pairing required / 1008” type errors in logs

stderr: /Users/djryan/.openclaw/logs/gateway.err.log

Fix 1 (most likely): background sooner than the provider timeout

Fix 2: make sure process + sessions_spawn are actually allowed

Fix 3: your iMessage errors are unrelated, but they’re flooding your logs

Also: “Gateway already running locally” isn’t a problem

0) Make sure you restarted the gateway

1) Quick smoke test (tells us if exec+process are fundamentally working)

2) Your /exec defaults show host=sandbox — verify sandbox is actually healthy

3) sessions_spawn specifically: we need the actual failure message

4) iMessage log spam is separate (but you should fix/disable it)

Please run these and paste the output

Quick “just make exec come back” fix (safe default)

Fix it immediately (no sandbox): switch exec to run on the Mac host

Important safety note (since you’re on Discord)

If you do want sandbox mode

One more thing: your agent list looks fine

Next: verify long commands + background/poll works

Then: test sub-agent spawning (without relying on the model)

Security follow-up (important on Discord)

1) Prove where the error is coming from

2) Check if this Discord thread session is “sandboxed (non-main)”

3) Paste these 3 outputs

What the warning about web_search / memory_* means

The real fix: use a provider/API mode that actually supports tool calling

If you actually want “Kimi 2.5”, don’t run it through the Ollama provider

Quick sanity test after you adjust provider

Why the “unknown entries” warning appears

Fix path (pick one)

Option A (recommended if you want Kimi 2.5 reliably): use the Moonshot provider, not Ollama

Option B (if you insist on “cloud via ollama/openai-compat”): disable streaming for that model

Paste these 3 commands so I can tell you exactly what to change

Fix (recommended): use native Ollama API properly

If you intentionally want OpenAI-compatible mode (/v1)

Strong suggestion if your goal is “Kimi K2.5 cloud”

Do this (keeps using your paid kimi-k2.5:cloud)

Why this matters for your “tools don’t work” symptoms

One more thing: you have ollama-cloud/... in fallbacks

Billing reality check (so expectations are set)

Next steps (quick verification)

One more thing: remove that ollama-cloud/... fallback (it’s probably not configured)

Now do the “does it actually work?” checklist

Optional cleanup (recommended)

1) Stop provider failover from changing behavior mid-run

2) Prove whether the problem is “Kimi cloud tool-calling” vs OpenClaw tools

A) Switch to a local model you already have (just for the test)

B) Switch back to Kimi cloud

If it still breaks: capture one real log snippet

Step 1: Confirm it’s really on the paid cloud Kimi model (in Telegram)

Step 2: A/B test to prove whether the model is the problem

Step 3 (workaround if Kimi cloud is the culprit): use OpenAI-compat mode + disable streaming for that model

If any of the above still fails: paste one real log snippet

1) Confirm exec defaults (in Telegram)

2) Run the minimal background+poll test (in Telegram)

If it fails

Quick next move if Kimi cloud breaks but local works

1) Grab one real failure from the gateway (not Mochi’s summary)

2) A/B test (takes 1 minute)

3) If Kimi cloud is the culprit, try the OpenAI-compat workaround

1) Verify whether OpenClaw is even offering exec/process to this session

2) Capture a “real” tool attempt in logs

3) If Kimi cloud still won’t call tools, do the A/B test

Do this quick A/B (it will prove it in 60 seconds)

If Kimi cloud is the problem, here are your realistic options

Option 1 (pragmatic): use Kimi for chat, switch to qwen only when you need tools

Option 2 (try this workaround): run the “cloud” model via Ollama’s OpenAI-compatible API + disable streaming

One cleanup item (optional, but helps avoid “random” behavior)

Option A (fastest): use a model you already have

Option B: install the model you tried to use

If you’re not sure what you have installed

What you can do from Terminal (Mac mini)

If you still want OpenClaw to run terminal commands

A) Keep paying for Kimi Cloud, but run scripts in Terminal

B) Add a local tool-runner model just for tools (free), keep Kimi Cloud for chat

C) If you insist on only Kimi Cloud for everything

2) Why `exec` “works under ~5s” but not longer

3) Why `sessions_spawn` can be “completely broken”

Fix 2: make sure `process` + `sessions_spawn` are actually allowed

1) Quick smoke test (tells us if `exec`+`process` are fundamentally working)

2) Your `/exec` defaults show `host=sandbox` — verify sandbox is actually healthy

3) `sessions_spawn` specifically: we need the actual failure message

What the warning about `web_search` / `memory_*` means

If you intentionally want OpenAI-compatible mode (`/v1`)

Do this (keeps using your paid `kimi-k2.5:cloud`)

One more thing: you have `ollama-cloud/...` in fallbacks

One more thing: remove that `ollama-cloud/...` fallback (it’s probably not configured)

1) Verify whether OpenClaw is even offering `exec/process` to this session

Option 1 (most reliable): run shell commands via Telegram `! ...` (bypasses the model)

Option 2: keep using agent tools (`exec/process`) but change the Ollama API mode to reduce tool-call flakiness

If you want the agent to call `exec/process` by itself

4) Prove `exec` works without any LLM (this isolates “tools broken” vs “model not calling tools”)

3) Run `exec` via the Gateway HTTP API (no Telegram/model involved)

1) Enable the host shell command from chat (`! ...`) and allow only you

Fastest Terminal-only way to get your Telegram `from.id` (no OpenClaw logs needed)

If you only see a short id like `896916fa`

Make `!poll` work (avoid approvals by allowlisting the binaries)