tools not working. - wrong "tools": { "profile":
✅Solved
Since the last update, I have been trying to fix my tools. My bot is unable to use them properly. This is straight out of the chat window:
"Despite my explanation, I just used callauto again instead of write. This appears to be a systematic issue with my current configuration or the model.
What happens is:
out of chat:
I say I will use write → I use callauto
I say I will use read → I use functionsread"
After starting a new session, creating, reading and writing a file seems to work. However, deleting the file does not work and immediately brings it back to the broken state where it tries to use callauto.
The bot even recognizes the problem itself in its reasoning output: "callauto does not exist. I must use exec." – but keeps calling it anyway. The only fix is to start a completely new session, which then breaks again on the next exec/delete call.
out of chat:
Reasoning: callauto does not exist. I must use exec.
Reasoning: I must use exec, not callauto.
Reasoning: I should use exec, not callauto. I need to use the tools correctly.
Reasoning: The user aborted the previous execution ("/abort").
System info:
OpenClaw version: 2026.3.2
OS: Linux 6.8.0-101-generic (x64)
Node: 22.22.0
Model: nvidia-nim/moonshotai/kimi-k2.5 (api: openai-completions)
Fallbacks: z-ai/glm-4.7, openrouter/qwen/qwen3-coder:free, openrouter/openai/gpt-oss-120b:free, openrouter/z-ai/glm-4.5-air:free
What I tried:
Clearing all sessions and starting fresh → helps temporarily
Switching api from openai-completions to openai-responses → breaks all providers with 404
using a differen model does not change a thing.
tools.profile is set to "full"
sandbox explain shows all tools in the allow list (exec, read, write, edit, browser, canvas etc.)
workspaceAccess: rw is set
Question:
Is this a known serialization bug with openai-completions + Kimi K2.5 via NVIDIA NIM? The tool IDs seem to get corrupted after the first exec call, causing the model to lose track of the correct tool names.
"Despite my explanation, I just used callauto again instead of write. This appears to be a systematic issue with my current configuration or the model.
What happens is:
out of chat:
I say I will use write → I use callauto
I say I will use read → I use functionsread"
After starting a new session, creating, reading and writing a file seems to work. However, deleting the file does not work and immediately brings it back to the broken state where it tries to use callauto.
The bot even recognizes the problem itself in its reasoning output: "callauto does not exist. I must use exec." – but keeps calling it anyway. The only fix is to start a completely new session, which then breaks again on the next exec/delete call.
out of chat:
Reasoning: callauto does not exist. I must use exec.
Reasoning: I must use exec, not callauto.
Reasoning: I should use exec, not callauto. I need to use the tools correctly.
Reasoning: The user aborted the previous execution ("/abort").
System info:
OpenClaw version: 2026.3.2
OS: Linux 6.8.0-101-generic (x64)
Node: 22.22.0
Model: nvidia-nim/moonshotai/kimi-k2.5 (api: openai-completions)
Fallbacks: z-ai/glm-4.7, openrouter/qwen/qwen3-coder:free, openrouter/openai/gpt-oss-120b:free, openrouter/z-ai/glm-4.5-air:free
What I tried:
Clearing all sessions and starting fresh → helps temporarily
Switching api from openai-completions to openai-responses → breaks all providers with 404
using a differen model does not change a thing.
tools.profile is set to "full"
sandbox explain shows all tools in the allow list (exec, read, write, edit, browser, canvas etc.)
workspaceAccess: rw is set
Question:
Is this a known serialization bug with openai-completions + Kimi K2.5 via NVIDIA NIM? The tool IDs seem to get corrupted after the first exec call, causing the model to lose track of the correct tool names.
Solution
Here’s the “single answer” summary for anyone who hits this again:
- The moment the agent needs to run a command (delete a file →
- tool calls start showing
- tool results show
- after that, the session never recovers (even though the model’s reasoning says “I must use exec”).
Your logs showed an invalid tool-call turn:
- The assistant message had
- but its
Symptom
- New session:readwrite- The moment the agent needs to run a command (delete a file →
exec rm …- tool calls start showing
call_auto_1- tool results show
toolName: "unknown"Tool not found- after that, the session never recovers (even though the model’s reasoning says “I must use exec”).
What’s actually happening (root cause)
This is not “OpenClaw forgot tool names” or “tool IDs got corrupted”.Your logs showed an invalid tool-call turn:
- The assistant message had
stopReason: "toolUse"- but its
contenttoolCallfunctionCall
The AI that actually does things. Emails, calendar, home automation - all from your favorite chat app. New shell, ready to help. The lobster way.
131,281Members
Resources
Was this page helpful?
