Tools intermittent/"Tool not found"

[light garden]

Setup:

• Host: Hostinger VPS
• Deployment: Docker container
• OpenClaw version: 2026.2.23

It's a basic Hostinger Catalog deployment + ollama container providing kimi-k2.5.

OpenClaw is not able to execute any exec, read, write, etc.

openclaw gateway status returns
Config (cli): ~/.openclaw/openclaw.json
Config (service): ~/.openclaw/openclaw.json

Here part of openclaw.json:

"models": {
"mode": "merge",
"providers": {
"ollama": {
"baseUrl": "http://172.17.0.1:32768/v1",
"models": [
{
"id": "kimi-k2.5:cloud",
"name": "kimi-k2.5:cloud",
"reasoning": false,
"input": [
"text",
"image"
],
"cost": {
"input": 0,
"output": 0,
"cacheRead": 0,
"cacheWrite": 0
},
"contextWindow": 200000,
"maxTokens": 8192
}
]
}
}
},
"agents": {
"defaults": {
"model": {
"primary": "ollama/kimi-k2.5:cloud"
},
"models": {
"ollama/kimi-k2.5:cloud": {
"alias": "kimi-k2.5"
}
},
"memorySearch": {
"enabled": true,
"sources": [
"memory",
"sessions"
],
"experimental": {
"sessionMemory": true
},
"provider": "local"
},
"compaction": {
"memoryFlush": {
"enabled": true
}
},
"elevatedDefault": "ask"
},
"list": [
{
"id": "main",
"name": "main"
}
]
},
"tools": {
"allow": [],
"links": {
"enabled": true
},
"loopDetection": {
"enabled": false
},
"agentToAgent": {
"enabled": true
},
"elevated": {
"enabled": true
},
"exec": {
"host": "gateway",
"security": "full",
"ask": "off"
},
"fs": {
"workspaceOnly": false
}
},

[wary carbon]

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

[ember oar]

Two likely things are happening here:

1) Your Ollama provider is pointed at /v1 but not configured for the right API mode

OpenClaw’s Ollama provider prefers the native Ollama API (/api/chat) for reliable streaming + tool calling. If you point it at the OpenAI-compatible /v1 endpoint, you generally need to set the provider api explicitly.

Recommended fix (native Ollama API)

Change your provider to use the root (no /v1) and set api: "ollama":

{
  models: {
    providers: {
      ollama: {
        baseUrl: "http://172.17.0.1:32768",
        api: "ollama",

        // optional but recommended; any string works for local Ollama
        apiKey: "ollama-local",

        models: [
          { id: "kimi-k2.5:cloud", name: "kimi-k2.5:cloud", /* ... */ }
        ]
      }
    }
  }
}

Then restart:

openclaw gateway restart

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

If you must use the OpenAI-compatible endpoint

Set:

models: { providers: { ollama: { api: "openai-completions", baseUrl: "http://172.17.0.1:32768/v1" } } }

…and be aware some OpenAI-compatible stacks don’t support streaming + tools together. If tools still don’t fire, try turning streaming off for that model via:

{
  agents: {
    defaults: {
      models: {
        "ollama/kimi-k2.5:cloud": {

          streaming: false
        }
      }
    }
  }
}

(That streaming flag is supported in agents.defaults.models[...].)

2) The model may simply not be tool-capable (common with local models)

In OpenClaw, the model has to emit tool calls. If the model doesn’t support tool calling (or is flaky), it will “just talk” and never actually invoke exec/read/write.

Fast way to confirm what’s going on: paste the output of these from inside the container/VPS:

openclaw status --all
openclaw models status
openclaw logs --follow

(Those are the “first 60 seconds” triage commands from the FAQ: https://docs.openclaw.ai/help/faq)

Quick safety note

You currently have tools.exec.security: "full" and tools.exec.ask: "off". That’s fine for a locked-down private bot, but make sure your channel allowlists are tight—otherwise you’ve basically given chat the ability to run arbitrary shell commands.

If you paste openclaw models status + the first tool-related error you see in openclaw logs --follow, I can tell you exactly whether this is (a) API-mode mismatch, (b) streaming/tool incompatibility, or (c) the model not producing tool calls.

[light garden]

"models": {
"mode": "merge",
"providers": {
"ollama": {
"baseUrl": "http://172.17.0.1:32768/v1",
"api": "ollama",

Diagnosis (read-only)

Gateway connection details:
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /data/.openclaw/openclaw.json
Bind: loopback

✓ Config: /data/.openclaw/openclaw.json
✓ Restart sentinel: none
✓ Port 18789
! Tailscale: off · unknown
error: Error: spawn tailscale ENOENT
✓ Skills: 6 eligible · 0 missing · /data/.openclaw/workspace
! Channel issues (2)

• telegram[default] config: Config allows unmentioned group messages (requireMention=false). Telegram Bot API privacy mode will block most group messages unless disabled. · fix: In BotFather run /setprivacy → Disable for this bot (then restart the gateway).
• whatsapp[default] auth: Not linked (no WhatsApp Web session). · fix: Run: openclaw channels login (scan QR on the gateway host).

Pasteable debug report. Auth tokens redacted.

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : ollama/kimi-k2.5:cloud
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (1) : kimi-k2.5 -> ollama/kimi-k2.5:cloud
Configured models (1): ollama/kimi-k2.5:cloud

Auth overview
Auth store : ~/.openclaw/agents/main/agent/auth-profiles.json
Shell env : off
Providers w/ OAuth/tokens (0): -

• nexos effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | nexos:default=missing
• ollama effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | ollama:default=dummy

OAuth/token status

• none

[ember oar]

That last bit of config explains it:

You currently have api: "ollama" + baseUrl: ".../v1".

In 2026.2.23, when model.api === "ollama", OpenClaw will call the native Ollama endpoints like:

• POST <baseUrl>/api/chat
• GET <baseUrl>/api/tags

So with your config it will effectively try:

• http://172.17.0.1:32768/v1/api/chat ← wrong path (usually 404)

Fix: pick ONE of these two valid combinations

Option A (recommended): native Ollama API

models: {
  providers: {
    ollama: {
      baseUrl: "http://172.17.0.1:32768",
      api: "ollama",
      apiKey: "ollama-local", // any string is fine
      models: [ /* your model def */ ]
    }
  }
}

Option B: OpenAI-compatible /v1 endpoint

models: {

  providers: {
    ollama: {
      baseUrl: "http://172.17.0.1:32768/v1",
      api: "openai-completions",
      apiKey: "ollama-local",
      models: [ /* your model def */ ]
    }
  }
}

Then restart:

openclaw gateway restart

Quick sanity checks (run inside the OpenClaw container)

curl -i http://172.17.0.1:32768/api/tags
curl -i http://172.17.0.1:32768/v1/models

• If /api/tags works → use Option A.
• If only /v1/models works → you’re not talking to real Ollama-native endpoints → use Option B.

If tools still don’t run after that

Then it’s almost certainly the model not emitting tool calls (common with some local/OpenAI-proxy setups). In that case, paste the first ~50 lines around a failed attempt from:

openclaw logs --follow

…and I’ll tell you whether it’s “model didn’t tool-call” vs “provider rejected tool schema” vs “tool policy filtered them out”.

[light garden]

models adapted:
"models": {
"mode": "merge",
"providers": {
"ollama": {
"baseUrl": "http://172.17.0.1:32768",
"api": "ollama",

Still: Tools (exec, read, write) randomly return "Tool not found" errors. The behavior is inconsistent - sometimes write works, other times it fails. Same with exec and read.

OpenClaw Gateway: Intermittent "Tool Not Found" Errors

Problem: Tools (exec, read, write) randomly return "Tool not found" errors. The issue is intermittent - tools work for a few minutes, then completely stop working.

Root Cause: WebSocket connection between agent session and gateway keeps dropping:

[ws] webchat disconnected code=1005 reason=n/a
[ws] webchat connected conn=xxx

After disconnection, tools become unavailable until a new message triggers reconnection.

Symptoms:

• ✅ Gateway process is running (logs show normal operation)
• ✅ Telegram provider works (sending messages)
• ❌ Tools unavailable for minutes at a time
• ❌ "Tool not found" on exec, read, write calls
• ❌ Connection restores briefly after new user message, then drops again

Environment:

• OpenClaw 2026.2.23 in Docker
• Hostinger VPS
• Tools worked briefly after config fixes, then connection dropped

Suspected Causes:

1. WebSocket timeout/keepalive issue
2. Gateway session management bug
3. Network instability between agent and gateway

Status: Currently unable to perform any tool operations consistently.
@ember oar

[ember oar]

[ws] webchat disconnected code=1005 is just the WebChat UI client (your browser/tab) dropping the Gateway WebSocket. That log line by itself should not make exec/read/write “disappear” on the Gateway — tools are registered server-side per run.

When you see intermittent “Tool not found” for core tools, it’s almost always one of these:

1. Tool policy is filtering tools for that session (sandbox / profile / allowlist), so the model calls something that isn’t in the active tool set.
2. The model is hallucinating tool names / emitting malformed tool calls (very common with local/Ollama-served models), so OpenClaw can’t dispatch them.

1) Rule out tool policy / sandboxing (fast)

Run these on the VPS (inside the container is fine) and paste output:

openclaw config get tools.profile
openclaw config get tools.allow
openclaw config get tools.deny
openclaw config get agents.defaults.sandbox
openclaw sandbox explain --session main

(If sandbox explain says the session is sandboxed and exec/read/write aren’t allowed there, that’s the smoking gun.)

Also: tools.allow: [] does not mean “deny all” — empty allowlist means “allow everything” (deny list still wins).

2) Capture one failure from logs (this will tell us which case it is)

Start:

openclaw logs --follow

Then reproduce until you hit the “Tool not found”, and paste the block around the failure (the lines that show the tool name it thinks is missing).

Key detail: which tool name is “not found”?

• If it’s something like bash, read_file, write_file, etc → that’s the model inventing tool names.
• If it’s literally read / write / exec → that points more toward tool filtering (policy) or a run being started in a tools-disabled mode.

3) Quick mitigation that often stabilizes local models

Reduce the tool surface area the model has to juggle by forcing a smaller base profile:

{
  tools: { profile: "coding" }
}

(or even more targeted:)

{
  tools: {
    byProvider: {
      "ollama": { profile: "coding" }

    }
  }
}

Restart after changes:

openclaw gateway restart

If you paste the openclaw sandbox explain --session main output + one log excerpt from a failure, we can pin it down precisely.

[light garden]

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

Sandbox-Status für diese Session

openclaw sandbox explain --session main

🦞 OpenClaw 2026.2.23 (b817600) — Because the right answer is usually a script.

Config path not found: tools.profile

🦞 OpenClaw 2026.2.23 (b817600) — Pairing codes exist because even bots believe in consent—and good security hygiene.

[]

🦞 OpenClaw 2026.2.23 (b817600) — The UNIX philosophy meets your DMs.

Config path not found: tools.deny

🦞 OpenClaw 2026.2.23 (b817600) — Your task has been queued; your dignity has been deprecated.

Config path not found: agents.defaults.sandbox

🦞 OpenClaw 2026.2.23 (b817600) — I don't just autocomplete—I auto-commit (emotionally), then ask you to review (logically).

Effective sandbox:
agentId: main
sessionKey: agent:main:main
mainSessionKey: agent:main:main
runtime: direct
mode: off scope: agent perSession: false
workspaceAccess: none workspaceRoot: /data/.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

@ember oar

[ember oar]

Your sandbox explain output is actually good news:

• sandbox mode = off (runtime: direct, mode: off)
• sandbox tool policy (even if it applied) would allow exec/read/write/edit/process
• so this is not “sandbox blocked the tool”

Also: [ws] webchat disconnected code=1005 is the WebChat UI client disconnecting from the Gateway WS. That shouldn’t make core tools disappear on the gateway.

What “Tool not found” usually means in OpenClaw

It’s almost always: the model emitted a tool call whose name does not exactly match the tool list for that run.

That can happen because:

1. Model tool-calling flakiness (local models often sometimes emit bash, run_command, read_file, different casing like Read, etc.)
2. You’re not testing the same session key (Discord channel/thread session vs main), and a group/channel tool restriction is applied only in that Discord channel (deny wins), so sometimes a different session has different tools.

Two quick checks that will pinpoint which one it is

A) Capture the exact missing tool name

Next time it fails, paste the exact line, e.g.:

• Tool not found: write (or whatever it says)

If it ever says something like bash, read_file, writeFile, run, etc → that’s 100% the model hallucinating tool names.

B) Make sure you’re inspecting the Discord session key, not main

Run:

openclaw sessions --active 180

Find the session key that corresponds to your Discord channel/thread (it won’t be agent:main:main). Then run:

openclaw sandbox explain --session "<that-session-key>"

And also check whether you have any Discord channel tool restrictions configured:

openclaw config get channels.discord.guilds

(We’re looking for any tools: { deny: [...] } under the relevant guild/channel.)

Practical mitigation (helps a lot with weaker tool-callers)

Right now you’re effectively on the “full” tool surface. Reduce it so the model has fewer tools/schemas to mess up:

{
  tools: { profile: "coding" }
}

Restart after change:

openclaw gateway restart

Docs on tool profiles: https://docs.openclaw.ai/tools

If you paste (1) the exact “Tool not found: …” text and (2) the openclaw sessions --active 180 output, I can tell you immediately whether this is model tool-calling instability or a per-channel tool denylist/session mismatch.

[light garden]

According to Openclaw:
OpenClaw + Ollama: Model sends empty tool names ("Tool not found")

Issue: When using kimi-k2.5 (via Ollama), tool calls fail with Tool not found (note the double space - empty tool name).

Root Cause: The model is sending tool calls without specifying the tool name:

• Expected: {"tool": "exec", "arguments": {...}}
• Actual: {"tool": "", "arguments": {...}} (empty string)

Environment:

• OpenClaw 2026.2.23
• Model: ollama/kimi-k2.5:cloud
• Tools profile: coding (already applied)
• WebSocket connection: Stable now (was disconnected earlier)

Symptoms:

• Text responses work fine
• Tool calls hang/timeout or return "Tool not found"
• Empty tool name in the dispatch error
• Happens intermittently but now consistently

Tried:

• ✅ Fixed WebSocket disconnection issues
• ✅ Set tools.profile: coding
• ✅ Config has ask: "off", security: "allowlist"
• ❌ Still getting empty tool names from model

Suspected cause: Model hallucination / incompatibility with OpenClaw's tool format when using local Ollama models.

[ember oar]

Yep — empty tool name (Tool not found with a double space) basically means OpenClaw received a tool-call block where the tool name is "" (or missing), so dispatch can’t match it to exec/read/write/....

Two important points from your outputs:

• Sandbox is OFF (runtime: direct, mode: off) and the default sandbox policy isn’t what’s blocking you anyway.
• So this is not “tool policy removed exec/read/write”. This is upstream: the model/Ollama response is malformed (or partially streamed).

Why this happens (most likely)

In OpenClaw 2026.2.23 the native Ollama adapter accumulates tool_calls from all streaming chunks and then turns them into tool calls. If the model (or Ollama) emits an intermediate chunk like:

"tool_calls":[{"function":{"name":"","arguments":{...}}}]

…and later emits a correct one, OpenClaw can still end up with the empty-name call in the final aggregated list → “Tool not found”.

That’s consistent with “intermittent → now consistent”.

Workarounds (pick one)

A) Switch to OpenAI-compatible mode and disable streaming (often fixes partial tool-call weirdness)

{
  models: {
    providers: {
      ollama: {
        baseUrl: "http://172.17.0.1:32768/v1",
        api: "openai-completions"
      }
    }
  },
  agents: {
    defaults: {
      models: {

        "ollama/kimi-k2.5:cloud": {
          streaming: false
        }
      }
    }
  }
}

Then:

openclaw gateway restart

(If your /v1 endpoint doesn’t support tools+streaming reliably, streaming:false is the key part.)

B) Use a model that’s known to behave with tool calling in Ollama

A bunch of local models just… don’t reliably do tools (or do it “sometimes”), especially if you manually added them to the catalog. Quick test: swap the primary model to something else tool-capable and see if the issue disappears — that confirms it’s model-side.

C) If you want to help get this fixed upstream: capture the raw Ollama stream

Run a forced-tool-call prompt against /api/chat and paste the chunks where tool_calls.function.name is empty. That would be ideal for a GitHub issue, because it proves whether it’s:

• the model returning empty names, or
• OpenClaw needing to ignore/merge partial tool_calls chunks.

If you post one excerpt of openclaw logs --follow around the failure (the exact raw error line that includes the empty tool name), I can tell you which branch to take immediately.

[light garden]

13:26:10 debug agent/embedded {"subsystem":"agent/embedded"} embedded run agent end: runId=e343d8e5-1931-4874-bfd9-705fb93ca419 isError=false
13:26:10 debug agent/embedded {"subsystem":"agent/embedded"} embedded run prompt end: runId=e343d8e5-1931-4874-bfd9-705fb93ca419 sessionId=22d02b88-edc9-494d-829b-aeca23123a92 durationMs=58181
13:26:10 debug diagnostic {"subsystem":"diagnostic"} run cleared: sessionId=22d02b88-edc9-494d-829b-aeca23123a92 totalActive=0
13:26:10 debug agent/embedded {"subsystem":"agent/embedded"} embedded run done: runId=e343d8e5-1931-4874-bfd9-705fb93ca419 sessionId=22d02b88-edc9-494d-829b-aeca23123a92 durationMs=58270 aborted=false
13:26:10 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=main durationMs=58274 active=0 queued=0
13:26:10 debug diagnostic {"subsystem":"diagnostic"} lane task done: lane=session:agent:main:main durationMs=58276 active=0 queued=0

[ember oar]

That log excerpt just shows the run finishing cleanly — it doesn’t include the actual “Tool not found” line yet. But given you’re seeing Tool not found with an empty name (double space), that’s basically always:

the model/Ollama returned a tool_call where function.name is "" / missing
→ OpenClaw can’t dispatch it to exec/read/write.

A couple concrete things from your outputs:

1) You’re not actually on tools.profile: "coding" right now

openclaw config get tools.profile returned “Config path not found”, which means it’s unset (default = unrestricted / “full-ish”).

So first, actually set it:

openclaw config set tools.profile coding
openclaw gateway restart

That reduces the tool surface/schema the model has to deal with, which can make flaky tool-callers behave better.

Docs: https://docs.openclaw.ai/tools (tool profiles)

2) Prove whether the empty tool name is coming from Ollama (recommended repro)

Run this directly against your Ollama and see what tool_calls[].function.name looks like:

curl -N http://172.17.0.1:32768/api/chat \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "kimi-k2.5:cloud",
    "stream": true,
    "messages": [{"role":"user","content":"Call the exec tool with {\"command\":\"echo hi\"} and nothing else."}],
    "tools": [{
      "type":"function",

      "function":{
        "name":"exec",
        "description":"run a shell command",
        "parameters":{
          "type":"object",
          "properties":{"command":{"type":"string"}},
          "required":["command"]
        }
      }
    }]
  }'

If you see any streamed chunk containing something like:

"tool_calls":[{"function":{"name":"","arguments":{...}}}]

…then it’s model/Ollama output, not OpenClaw policy.

3) Temporary “minimum tool schema” test (optional, but very telling)

If tools.profile: coding still doesn’t help, temporarily cut tools down to just FS+runtime:

tools: {
  allow: ["group:fs", "group:runtime"],
}

Restart gateway and retry. If that fixes it, it strongly suggests kimi-k2.5 is choking on larger tool catalogs/schemas and starts emitting malformed tool calls.

(After the test you can remove/expand again.)

4) If it’s confirmed: this is a real incompat/bug → please file an issue

At that point the “fix” is either:

• switch to a different Ollama model for tool runs, or
• OpenClaw needs to harden the Ollama tool-call parsing (e.g. drop tool_calls with empty function.name instead of trying to dispatch them).

If you file a GitHub issue, include:

• OpenClaw version (2026.2.23)
• your models.providers.ollama config
• one failing log line showing Tool not found
• ideally 1–2 raw /api/chat NDJSON lines where function.name is empty

Issues: https://github.com/openclaw/openclaw/issues

If you paste the exact log line that contains Tool not found (the one with the double-space), I can tell you whether it’s coming from tool dispatch vs upstream provider parsing.

[light garden]

{"model":"kimi-k2.5:cloud","remote_model":"kimi-k2.5","remote_host":"https://ollama.com:443","created_at":"2026-02-26T13:33:06.065453044Z","message":{"role":"assistant","content":"","tool_calls":[{"id":"functions.exec:0","function":{"index":0,"name":"exec","arguments":{"command":"echo hi"}}}]},"done":false}

[ember oar]

That NDJSON line is super useful — and it actually shows the opposite of the “empty tool name” theory:

"tool_calls":[{"function":{"name":"exec","arguments":{"command":"echo hi"}}}]

So kimi-k2.5 can emit a valid tool name (at least in the minimal 1-tool test). That means the intermittent Tool not found is almost certainly triggered only in the real OpenClaw run, where the model sees a much larger tool catalog + schemas, and sometimes produces a malformed tool call (empty/whitespace name, wrong key, etc.) during streaming.

1) First: you still haven’t actually set tools.profile

Your earlier output:

• openclaw config get tools.profile → Config path not found

…means it’s unset right now.

Set it via CLI (don’t edit JSON by hand for this test):

openclaw config set tools.profile coding
openclaw gateway restart
openclaw config get tools.profile

You want the last command to print coding.

2) If it still happens: reduce tool list even harder (diagnostic + workaround)

This removes “message/channels/etc.” tools from the model’s view and often stops tool-call corruption:

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

(You can undo later by setting tools.allow back to [].)

3) Confirm whether Ollama ever emits empty tool names under streaming

Run your curl test but grep for empty names:

curl -N http://172.17.0.1:32768/api/chat \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "kimi-k2.5:cloud",
    "stream": true,
    "messages": [{"role":"user","content":"Call the exec tool with {\"command\":\"echo hi\"} and nothing else."}],
    "tools": [{
      "type":"function",
      "function":{
        "name":"exec",
        "description":"run a shell command",
        "parameters":{"type":"object","properties":{"command":{"type":"string"}},"required":["command"]}

      }
    }]
  }' | jq -r 'select(.message.tool_calls) | .message.tool_calls[].function.name' | cat -n

If you ever see a blank line in that numbered output, Ollama/model is emitting an empty name in-stream.

4) If empty names only happen with OpenClaw (not with the minimal curl)

Then it’s likely: tool schema size/shape is triggering kimi-k2.5 to produce broken tool_calls. In that case, the best “keep using kimi” workaround is the stricter tools.allow above (or run a different model for tool sessions).

If you can paste the actual OpenClaw log line that contains the error text (the one that prints Tool not found), I can tell from the surrounding context whether it’s:

• malformed tool_calls coming from the Ollama stream, or
• something being dropped/rewritten during transcript/tool-call sanitization.

[light garden]

13:46:15 debug diagnostic {"subsystem":"diagnostic"} lane enqueue: lane=session:agent:main:main queueSize=1
13:46:15 debug diagnostic {"subsystem":"diagnostic"} lane dequeue: lane=session:agent:main:main waitMs=1 queueSize=0
13:46:15 debug diagnostic {"subsystem":"diagnostic"} lane enqueue: lane=main queueSize=1
13:46:15 debug diagnostic {"subsystem":"diagnostic"} lane dequeue: lane=main waitMs=1 queueSize=0
13:46:15 debug agent/embedded {"subsystem":"agent/embedded"} embedded run start: runId=6d11775f-8234-4eb1-b2c2-a65f1fa1a492 sessionId=22d02b88-edc9-494d-829b-aeca23123a92 provider=ollama model=kimi-k2.5:cloud thinking=off messageChannel=webchat
13:46:15 warn tools {"subsystem":"tools"} tools.profile (coding) allowlist contains unknown entries (apply_patch). These entries won't match any tool unless the plugin is enabled.
13:46:25 error diagnostic {"subsystem":"diagnostic"} lane task error: lane=main durationMs=10566 error="Error: session file locked (timeout 10000ms): pid=28 /data/.openclaw/agents/main/sessions/22d02b88-edc9-494d-829b-aeca23123a92.jsonl.lock"
13:46:25 error diagnostic {"subsystem":"diagnostic"} lane task error: lane=session:agent:main:main durationMs=10569 error="Error: session file locked (timeout 10000ms): pid=28 /data/.openclaw/agents/main/sessions/22d02b88-edc9-494d-829b-aeca23123a92.jsonl.lock"
13:46:25 error Embedded agent failed before reply: session file locked (timeout 10000ms): pid=28 /data/.openclaw/agents/main/sessions/22d02b88-edc9-494d-829b-aeca23123a92.jsonl.lock

[ember oar]

That log is the real culprit — it’s not “tool not found” anymore, it’s:

Error: session file locked (timeout 10000ms): pid=28 .../22d02b88-....jsonl.lock

When the agent can’t write to the session transcript (*.jsonl), the whole run fails before any tools (exec/read/write) can reliably happen.

Why this happens a lot in Docker

OpenClaw’s session lock is literally a *.jsonl.lock file containing { pid, createdAt }.

In containers, PIDs get reused after restarts (often very quickly). So you can end up with:

• an old lock file from a previous container run
• a new gateway process that also happens to be pid=28

→ the lock looks “alive”, so OpenClaw refuses to delete it (it only auto-cleans “stale” locks after ~30 minutes), and you get this 10s timeout loop.

Fix (safe)

1. Stop the gateway/container first (important).
2. Move (don’t delete) that one lock file out of the sessions directory.
3. Start the gateway again.

Example (inside the container):

# stop the gateway first (or docker stop the container)
openclaw gateway stop

mkdir -p /data/.openclaw/lock-backup
mv /data/.openclaw/agents/main/sessions/22d02b88-edc9-494d-829b-aeca23123a92.jsonl.lock \
   /data/.openclaw/lock-backup/

openclaw gateway start

(If you can’t use openclaw gateway stop/start in your container setup, do the equivalent by stopping/starting the container, but do the mv while it’s stopped.)

Quick confirmation

Before moving it, check what’s in the lock file:

cat /data/.openclaw/agents/main/sessions/22d02b88-edc9-494d-829b-aeca23123a92.jsonl.lock
ps -p 28 -o pid,cmd

If pid=28 is just your current gateway process, that’s exactly the “PID reuse” situation.

Also: this warning is harmless

tools.profile (coding) allowlist contains unknown entries (apply_patch)

apply_patch only exists when the OpenAI-only apply_patch tool is enabled, so on Ollama you’ll see that warning. It doesn’t break exec/read/write.

---

If the lock file keeps reappearing even without restarts / without multiple containers, that’s a real bug or a stuck write path — then I’d grab a longer openclaw logs --follow excerpt around the first time it creates the lock and file a GitHub issue.

[light garden]

I switched away from the kimi-k2.5:cloud model to glm-5:cloud which now works without any more tool issues.

[ember oar]

Nice — that lines up with what we were circling:

• The session lock error was a separate “gateway can’t persist transcript” failure mode.
• But the really nasty “tool call weirdness” is model-dependent, and kimi-k2.5 is clearly flaky for tool calling in your setup, while glm-5:cloud behaves.

If you want a stable config going forward, I’d do two things:

1. Keep glm-5:cloud as the tool-capable default (and optionally keep kimi as a chat-only fallback/alternate agent).
2. If you ever see the lock error again, run:

openclaw doctor --fix

It will remove stale session lock files automatically (that’s what it’s for).

If this fixed it, please mark the solution message in the thread (right‑click → Apps → ✅ Mark Solution) so Answer Overflow indexes it.