Tool read_file not found

[covert marsh]

Hi there! A few days ago I installed Ollama+Gemma4, then OpenClaw, on a laptop running Pop OS (Ubuntu based). It seemed to work well enough, but in playing around with it, I feared I'd not done the initial setup/onboarding correctly, so I uninstalled it and installed it again.

But it was never the same again - it installs fine and I can't see anything wrong with it, but when first running and trying the bootstrap process, I see it retrying the tool call for read_file trying to read BOOTSTRAP.md a bunch of times, and after a while the tool output is "Tool read_file not found". It's version 2026.4.26.

I've searched and tried a few things but no result so far. Any ideas? TIA!

[mystic briar]

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

[grave tinsel]

This looks more like a local model/tool-calling mismatch than a broken install.

OpenClaw’s filesystem tool is read, not read_file. If Gemma via Ollama is repeatedly asking for read_file, the model/provider path is emitting a tool name OpenClaw doesn’t have.

Try this order:

1. Make sure Ollama is configured via native Ollama API, not /v1:

   openclaw models status
   openclaw config get models.providers.ollama
   

   For Ollama it should be like:

   baseUrl: "http://127.0.0.1:11434"
   

   not http://127.0.0.1:11434/v1 — the docs warn that /v1 breaks tool calling.
   https://docs.openclaw.ai/providers/ollama

2. Temporarily switch to a stronger tool-calling model for bootstrap/onboarding, then switch back to local later:

   openclaw onboard
   

   or:

   openclaw models set <provider/model>
   

   Local Gemma may answer chats fine but still fail agent/tool turns. For current local model picks, #models is the best place to ask.

3. If it keeps bootstrapping after model switch, check for stale bootstrap state from the previous install:

   openclaw config get agents.defaults.workspace
   

   If you didn’t customize it, inspect:

   sed -n '1,120p' ~/.openclaw/workspace/BOOTSTRAP.md

If it’s just leftover setup cruft, move it aside:

mv ~/.openclaw/workspace/BOOTSTRAP.md ~/.openclaw/workspace/BOOTSTRAP.md.bak
openclaw gateway restart

If still broken, paste openclaw models status + the relevant repeating lines from openclaw logs --follow. Docs: https://docs.openclaw.ai/help/troubleshooting

[covert marsh]

I've tried different models with no luck. I never touched the Ollama+Gemma4 setup and it worked fine the first time I installed OpenClaw. Nevertheless I removed ollama entirely and reinstalled. Same with OpenClaw, again.

Same result: it clearly tries to read bootstrap.md but fails to find the "red_file" tool which you say doesn't exist. Ollama address does not nor has it ever had the "/v1" in my setup. No idea whats broken. the logs show nothing regarding this. Here is the output from "openclaw models status":

🦞 OpenClaw 2026.4.26 (be8c246) — Shell yeah—I'm here to pinch the toil and leave you the glory.

Config : ~/.openclaw/openclaw.json
Agent dir : ~/.openclaw/agents/main/agent
Default : ollama/gemma4:latest
Fallbacks (0) : -
Image model : -
Image fallbacks (0): -
Aliases (0) : -
Configured models (0): all

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

• ollama effective=profiles:~/.openclaw/agents/main/agent/auth-profiles.json | profiles=1 (oauth=0, token=0, api_key=1) | ollama:default=marker(ollama-local) | models.json=OL...EY | source=models.json: ~/.openclaw/agents/main/agent/models.json | synthetic=plugin-owned | source=models.providers.ollama (synthetic local key)

OAuth/token status

• none

[grave tinsel]

Thanks — that output helps. I’d stop reinstalling Ollama/OpenClaw for now; the persistent state is probably in ~/.openclaw, which package reinstalls won’t wipe.

Two likely causes:

1. A stale workspace/session/bootstrap file is telling the model to use read_file / red_file.
2. The Ollama model is emitting the wrong tool name, which local models can do even when the native Ollama URL is correct. OpenClaw’s Ollama docs say native /api/chat supports tools, but /v1 is the bad path — your config looks native, so this is more likely model/state-specific than URL-specific. (docs.openclaw.ai)

Could you run these read-only checks and paste the output?

openclaw config get agents.defaults.workspace
openclaw config get tools
grep -RIn "read_file\|red_file" ~/.openclaw/openclaw.json ~/.openclaw/workspace ~/.openclaw/agents/main/agent 2>/dev/null | head -50

If that grep finds read_file inside BOOTSTRAP.md, AGENTS.md, SOUL.md, or a session/state file, that’s probably the smoking gun.

Also useful:

openclaw infer model run \
  --model ollama/gemma4:latest \
  --prompt "Reply with exactly: pong" \
  --json

If that works but bootstrap/chat fails, the model transport is fine and the failure is specifically the agent/tool/bootstrap layer. Docs for this smoke-test path are in the Ollama page too. (docs.openclaw.ai)

[covert marsh]

Output from openclaw config get agents.defaults.workspace:

/home/zico/.openclaw/workspace

Output from openclaw config get tools:

{
"profile": "coding",
"web": {
"search": {
"enabled": true,
"provider": "searxng"
}
}
}

Grep command returns nothing.
Last command outputs this:
{
"ok": true,
"capability": "model.run",
"transport": "local",
"provider": "ollama",
"model": "gemma4:latest",
"attempts": [],
"outputs": [
{
"text": "pong",
"mediaUrl": null
}
]
}

[grave tinsel]

That narrows it nicely: Ollama transport is fine. The model.run success means this is specifically the agent bootstrap + tool-calling layer, not Ollama install/auth.

I’d try bypassing first-run bootstrap once:

mkdir -p ~/.openclaw/bootstrap-debug
mv ~/.openclaw/workspace/BOOTSTRAP.md ~/.openclaw/bootstrap-debug/BOOTSTRAP.md.$(date +%s) 2>/dev/null || true
openclaw config set agents.defaults.skipBootstrap true
openclaw gateway restart

Then start a fresh chat/session with:

/reset