calm depot Feb 16, 2026, 9:59 PM

#

I have a 24 gb mac mini with a m4 pro chip and have installed ollama/glm-4.7-flash. The issue is it is saying it wrote to my USER.md file but when I check it hasn't. If edit the file it can read it but can't write to it itself

limber walrusBOT Feb 16, 2026, 9:59 PM

#

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

paper graniteBOT Feb 16, 2026, 10:03 PM

#

That symptom usually comes from one of these two things:

1) You’re checking the wrong `USER.md` (workspace mismatch)

OpenClaw writes to the agent workspace on the Gateway host. Default is:

~/.openclaw/workspace/USER.md

FAQ section (worth reading):
https://docs.openclaw.ai/help/faq#where-should-agentsmd-soulmd-usermd-memorymd-live

On your Mac mini, run:

openclaw --version
openclaw config get agents.defaults.workspace
ls -la "$(openclaw config get agents.defaults.workspace)/USER.md"

#

Then open that exact file and see if it changes.

2) The local model is hallucinating “I wrote the file” (tool-calling reliability)

With some Ollama models, tool calling is flaky: the model says it wrote a file but it either:

never actually called the write/edit tool, or
the tool returned an error and the model ignored it.

To confirm, tail logs and retry a write:

openclaw logs --follow

Then ask the assistant: “Append the line FILE_WRITE_TEST_123 to USER.md”.

If the logs show no file-write tool call (or show an error like permission denied), you’ve found the cause.

#

Ollama docs (how tool-capable models are detected / configured):
https://docs.openclaw.ai/providers/ollama

Quick “path vs tool” test

Ask the assistant to do both:

“Append XYZ_987 to USER.md”
“Now read USER.md and show me the last 5 lines”

If it can’t read back the string: it never wrote (or write failed).
If it can read back the string but you can’t find it manually: you’re looking at a different USER.md than the workspace file.

If you paste:

openclaw --version
openclaw config get agents.defaults.workspace
the log snippet around the attempted write

#

…I can tell you which of the two it is and what the exact fix is.

calm depot Feb 16, 2026, 10:06 PM

#

stewie@Stewies-Mac-mini .openclaw % openclaw --version
openclaw config get agents.defaults.workspace
ls -la "$(openclaw config get agents.defaults.workspace)/USER.md"
2026.2.15

🦞 OpenClaw 2026.2.15 (3fe22ea) — The only crab in your contacts you actually want to hear from. 🦞

/Users/stewie/.openclaw/workspace
-rw-r--r-- 1 stewie staff 477 Feb 16 11:54 /Users/stewie/.openclaw/workspace/USER.md
stewie@Stewies-Mac-mini .openclaw %

paper graniteBOT Feb 16, 2026, 10:09 PM

#

Nice — that confirms you’re looking at the real workspace file and it’s writable by your user.

At this point, the two most common causes for “it says it wrote USER.md but nothing changed” are:

A) Your agent is sandboxed / read-only (so writes are blocked)

Check if sandboxing is on and whether the workspace is mounted read-only:

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

You’re looking for either:

sandbox.workspaceAccess: "ro" (reads work, writes fail), or
tools.deny containing "write" / "edit" for the agent that Discord is routed to.

#

Fix (if you see read-only): either turn sandbox off, or allow read/write:

openclaw config set agents.defaults.sandbox.mode off
# OR:
openclaw config set agents.defaults.sandbox.workspaceAccess rw
openclaw gateway restart

(If it’s set per-agent under agents.list[], change it there instead.)

B) The local model is hallucinating the tool call (“wrote file”) but never actually wrote

Best way to prove this quickly: tail logs while you reproduce.

In one terminal:

#

openclaw logs --follow

Then in chat, ask the bot to do something very explicit:

“Append the line FILE_WRITE_TEST_123 to USER.md, then read back the last 5 lines of USER.md.”

If the logs show no write/edit tool call (or show an error like EROFS / “tool not allowed”), that’s your answer.

One more quick sanity check (CLI vs service config mismatch)

This catches “gateway service is running with different config than my shell”:

openclaw gateway status

#

If it shows Config (cli) and Config (service) pointing at different configs, run:

openclaw doctor
openclaw gateway restart

If you paste the output of:

openclaw config get agents.defaults.sandbox
openclaw config get agents.list (or just the part showing the active agent)
and the log lines around the attempted write

…I can tell you exactly which branch you’re on and the minimal config change to fix it.

calm depot Feb 16, 2026, 10:11 PM

#

stewie@Stewies-Mac-mini .openclaw % openclaw config get agents.defaults.sandbox
openclaw config get agents.list
openclaw config get agents.defaults.tools

🦞 OpenClaw 2026.2.15 (3fe22ea) — Greetings, Professor Falken

Config path not found: agents.defaults.sandbox

🦞 OpenClaw 2026.2.15 (3fe22ea) — Less middlemen, more messages.

[
{
"id": "main",
"name": "main",
"workspace": "/Users/stewie/.openclaw/workspace",
"agentDir": "/Users/stewie/.openclaw/agents/main/agent"
}
]

🦞 OpenClaw 2026.2.15 (3fe22ea) — The only crab in your contacts you actually want to hear from. 🦞

Config path not found: agents.defaults.tools
stewie@Stewies-Mac-mini .openclaw %

paper graniteBOT Feb 16, 2026, 10:12 PM

#

Those Config path not found: agents.defaults.sandbox / agents.defaults.tools lines are actually a good sign: it means you haven’t enabled sandboxing or custom tool allow/deny rules in config, so this probably isn’t a “write is blocked by config” situation.

Next thing to determine is: is the Gateway actually attempting the write tool and failing, or is the Ollama model just claiming it did it (tool-call hallucination)?

1) Verify the Gateway/service isn’t using a different config/workspace

Run and paste:

openclaw gateway status
openclaw status --all

(If Config (cli) vs Config (service) differ, the daemon can be running with a different config/workspace than your shell expects.)

2) Tail logs and reproduce one write (this is the key)

In one terminal:

#

openclaw logs --follow

Then in Discord, ask the bot something verifiable:

“Append FILE_WRITE_TEST_123 to USER.md, then read back the last 5 lines of USER.md.”

Now look at the logs:

If you see an error like EACCES / EPERM / EROFS / “tool denied” → paste that error; we’ll fix the underlying permission/daemon/sandbox issue.
If you don’t see any write/edit tool call at all → it’s almost certainly the local model not reliably tool-calling (it’s “roleplaying” the write).

In that case the pragmatic fix is: use a more tool-reliable model for file operations (even as a fallback), and keep the local model for casual chat. Ollama/local models guidance is here:

#

If you paste the openclaw gateway status output + the few log lines around the attempted write, I can tell you which branch you’re on immediately.

calm depot Feb 16, 2026, 10:16 PM

#

stewie@Stewies-Mac-mini .openclaw % openclaw gateway status
openclaw status --all

🦞 OpenClaw 2026.2.15 (3fe22ea) — It's not "failing," it's "discovering new ways to configure the same thing wrong."

│
◇
Service: LaunchAgent (loaded)
File logs: /tmp/openclaw/openclaw-2026-02-16.log
Command: /opt/homebrew/bin/node /opt/homebrew/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 12511, state active)
RPC probe: ok

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

#

🦞 OpenClaw 2026.2.15 (3fe22ea) — Your inbox, your infra, your rules.

│
OpenClaw status --all

Overview
┌─────────────────┬───────────────────────────────────────────────────────────────────────────────────────────────────┐
│ Item │ Value │
├─────────────────┼───────────────────────────────────────────────────────────────────────────────────────────────────┤
│ Version │ 2026.2.15 │
│ OS │ macos 26.3 (arm64) │
│ Node │ 22.22.0 │
│ Config │ ~/.openclaw/openclaw.json │

#

│ Dashboard │ http://127.0.0.1:18789/ │
│ Tailscale │ off │
│ Channel │ stable (default) │
│ Update │ pnpm · npm latest 2026.2.15 │
│ Gateway │ local · ws://127.0.0.1:18789 (local loopback) · reachable 20ms · auth token │
│ Security │ Run: openclaw security audit --deep │
│ Gateway self │ Stewies-Mac-mini.local (192.168.1.12) app unknown macos 26.3 │
│ Gateway service │ LaunchAgent installed · loaded · running (pid 12511) │
│ Node service │ LaunchAgent not installed │
│ Agents │ 1 total · 1 bootstrapping · 1 active · 1 sessions │
└─────────────────┴───────────────────────────────────────────────────────────────────────────────────────────────────┘

#

Channels
┌──────────┬─────────┬────────┬───────────────────────────────────────────────────────────────────────────────────────┐
│ Channel │ Enabled │ State │ Detail │
├──────────┼─────────┼────────┼───────────────────────────────────────────────────────────────────────────────────────┤
│ Telegram │ ON │ OK │ token config (sha256:a4acf556 · len 46) · accounts 1/1 │
└──────────┴─────────┴────────┴───────────────────────────────────────────────────────────────────────────────────────┘

Telegram accounts
┌──────────┬──────────┬───────────────────────────────────────────────────────────────────────────────────────────────┐
│ Account │ Status │ Notes │
├──────────┼──────────┼───────────────────────────────────────────────────────────────────────────────────────────────┤
│ default │ OK │ token:config │
└──────────┴──────────┴───────────────────────────────────────────────────────────────────────────────────────────────┘

#

Agents
┌─────────────┬───────────┬──────────┬──────────┬─────────────────────────────────────────────────────────────────────┐
│ Agent │ Bootstrap │ Sessions │ Active │ Store │
├─────────────┼───────────┼──────────┼──────────┼─────────────────────────────────────────────────────────────────────┤
│ main (main) │ PENDING │ 1 │ 8m ago │ ~/.openclaw/agents/main/sessions/sessions.json │
└─────────────┴───────────┴──────────┴──────────┴─────────────────────────────────────────────────────────────────────┘

Diagnosis (read-only)

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

#

✓ Config: /Users/stewie/.openclaw/openclaw.json
✓ Restart sentinel: none

Gateway last log line:
at processTicksAndRejections (node:internal/process/task_queues:105:5)
! Port 18789
Port 18789 is already in use.

pid 12511 stewie: openclaw-gateway (127.0.0.1:18789)
Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
! Tailscale: off · unknown
error: Error: spawn tailscale ENOENT
✓ Skills: 4 eligible · 0 missing · /Users/stewie/.openclaw/workspace

#

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

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

2026-02-16T13:55:46.872-07:00 [openclaw] Model "glm-4.7-flash" specified without provider. Falling back to "anthropic/glm-4.7-flash". Please use "anthropic/glm-4.7-flash" in your config.
2026-02-16T13:55:50.221-07:00 [openclaw] Model "glm-4.7-flash" specified without provider. Falling back to "anthropic/glm-4.7-flash". Please use "anthropic/glm-4.7-flash" in your config.
2026-02-16T13:55:50.250-07:00 [openclaw] Model "glm-4.7-flash" specified without provider. Falling back to "anthropic/glm-4.7-flash". Please use "anthropic/glm-4.7-flash" in your config.
2026-02-16T20:55:50.268Z [diagnostic] lane task error: lane=main durationMs=14 error="Error: Unknown model: anthropic/glm-4.7-flash"
2026-02-16T20:55:50.269Z [diagnostic] lane task error: lane=session:agent:main:main durationMs=15 error="Error: Unknown model: anthropic/glm-4.7-flash"
2026-02-16T13:55:50.270-07:00 Embedded agent failed before reply: Unknown model: anthropic/glm-4.7-flash
… 14 lines omitted …

#

2026-02-16T14:02:41.791-07:00 [openclaw] Model "glm-4.7-flash" specified without provider. Falling back to "anthropic/glm-4.7-flash". Please use "anthropic/glm-4.7-flash" in your config.
2026-02-16T14:02:41.792-07:00 [openclaw] Model "glm-4.7-flash" specified without provider. Falling back to "anthropic/glm-4.7-flash". Please use "anthropic/glm-4.7-flash" in your config.
2026-02-16T14:02:41.803-07:00 [openclaw] Model "glm-4.7-flash" specified without provider. Falling back to "anthropic/glm-4.7-flash". Please use "anthropic/glm-4.7-flash" in your config.
2026-02-16T14:02:41.804-07:00 [openclaw] Model "glm-4.7-flash" specified without provider. Falling back to "anthropic/glm-4.7-flash". Please use "anthropic/glm-4.7-flash" in your config.
2026-02-16T14:02:51.880-07:00 [openclaw] Model "glm-4.7-flash" specified without provider. Falling back to "anthropic/glm-4.7-flash". Please use "anthropic/glm-4.7-flash" in your config.
2026-02-16T14:02:51.886-07:00 [openclaw] Model "glm-4.7-flash" specified without provider. Falling back to "anthropic/glm-4.7-flash". Please use "anthropic/glm-4.7-flash" in your config.
2026-02-16T14:02:51.887-07:00 [openclaw] Model "glm-4.7-flash" specified without provider. Falling back to "anthropic/glm-4.7-flash". Please use "anthropic/glm-4.7-flash" in your config.
2026-02-16T14:02:57.306-07:00 [openclaw] Model "glm-4.7-flash" specified without provider. Falling back to "anthropic/glm-4.7-flash". Please use "anthropic/glm-4.7-flash" in your config.
2026-02-16T14:02:57.334-07:00 [openclaw] Model "glm-4.7-flash" specified without provider. Falling back to "anthropic/glm-4.7-flash". Please use "anthropic/glm-4.7-flash" in your config.
2026-02-16T21:02:57.354Z [diagnostic] lane task error: lane=main durationMs=15 error="Error: Unknown model: anthropic/glm-4.7-flash"

#

2026-02-16T21:02:57.355Z [diagnostic] lane task error: lane=session:agent:main:main durationMs=17 error="Error: Unknown model: anthropic/glm-4.7-flash"
2026-02-16T14:02:57.356-07:00 Embedded agent failed before reply: Unknown model: anthropic/glm-4.7-flash
2026-02-16T14:06:37.623-07:00 [openclaw] Suppressed AbortError: AbortError: This operation was aborted
at node:internal/deps/undici/undici:14902:13
at processTicksAndRejections (node:internal/process/task_queues:105:5)

stdout: /Users/stewie/.openclaw/logs/gateway.log

2026-02-16T21:23:42.853Z [ws] ⇄ res ✓ config.get 53ms conn=329f83c3…a564 id=d1967f99…0a92
2026-02-16T21:26:18.804Z [ws] ⇄ res ✓ agents.list 69ms conn=329f83c3…a564 id=22693ab9…d58d
2026-02-16T21:26:18.861Z [ws] ⇄ res ✓ config.get 54ms conn=329f83c3…a564 id=252627f0…3032
2026-02-16T21:26:24.794Z [ws] ⇄ res ✓ chat.history 62ms conn=329f83c3…a564 id=a9644f54…d6d0
2026-02-16T21:26:48.023Z [ws] ⇄ res ✓ node.list 132ms conn=329f83c3…a564 id=7245685d…43ab
2026-02-16T21:29:19.729Z [ws] ⇄ res ✓ chat.send 67ms runId=192e1224-0ac7-4df0-b553-dd0e86015baf conn=329f83c3…a564 id=05063761…69ae
… 18 lines omitted …

#

2026-02-16T21:40:07.668Z [ws] ⇄ res ✓ node.list 80ms conn=654997b8…1a28 id=37e7fec5…bc49
2026-02-16T21:40:07.670Z [ws] ⇄ res ✓ node.list 75ms conn=916ec038…3a9d id=aa45dcef…7b2c
2026-02-16T21:40:19.673Z [ws] ⇄ res ✓ config.get 130ms conn=dc0495f7…26d4 id=962b79a3…7e47
2026-02-16T21:43:41.103Z [ws] ⇄ res ✓ chat.history 90ms conn=dc0495f7…26d4 id=bce5a358…3392
2026-02-16T21:43:44.784Z [ws] ⇄ res ✓ config.schema 74ms conn=dc0495f7…26d4 id=67046cd8…146e
2026-02-16T21:43:45.079Z [ws] ⇄ res ✓ config.get 124ms conn=dc0495f7…26d4 id=6c22b6fa…955b
2026-02-16T22:02:07.704Z [ws] ⇄ res ✓ node.list 121ms conn=916ec038…3a9d id=6d6fd03d…d360
2026-02-16T22:02:07.705Z [ws] ⇄ res ✓ node.list 123ms conn=654997b8…1a28 id=8cd3fd9e…9334
2026-02-16T22:02:07.706Z [ws] ⇄ res ✓ node.list 123ms conn=c74bd8b6…dd1b id=4991be67…7fca
2026-02-16T22:02:07.707Z [ws] ⇄ res ✓ node.list 124ms conn=9a6bdff5…0ed2 id=20b888ac…f0cb
2026-02-16T22:02:07.708Z [ws] ⇄ res ✓ node.list 125ms conn=c01a42ab…58e7 id=e25cd86f…c10f
2026-02-16T22:02:07.805Z [ws] ⇄ res ✓ node.list 55ms conn=d586824b…dcca id=55e01039…10de
2026-02-16T22:02:07.940Z [ws] ⇄ res ✓ node.list 189ms conn=edee1e07…920a id=df6eb098…f8a1
2026-02-16T22:03:01.634Z [ws] ⇄ res ✓ chat.history 77ms conn=c01a42ab…58e7 id=a81704db…34f3
2026-02-16T22:03:08.460Z [ws] ⇄ res ✓ agents.list 763ms conn=dc0495f7…26d4 id=093243ca…32ec
✓ Channel issues (none)

Pasteable debug report. Auth tokens redacted.
Troubleshooting: https://docs.openclaw.ai/troubleshooting

◇

#

End of file

paper graniteBOT Feb 16, 2026, 10:20 PM

#

Gateway/service config looks clean (same config path, RPC probe ok, same workspace). So we can pretty safely rule out “daemon is writing somewhere else”.

Next two things to check:

1) Are writes being blocked by tool policy? (it’s `tools.*`, not `agents.defaults.tools`)

Run:

openclaw config get tools
# or narrower:
openclaw config get tools.profile
openclaw config get tools.allow
openclaw config get tools.deny
openclaw config get tools.byProvider

If you see a tools.profile: "messaging" or a deny that includes write/edit/group:fs, that would explain “can read sometimes / claims writes” type behavior.

#

2) If tools aren’t blocked: confirm whether the model is actually calling `write/edit` (or hallucinating)

Tail logs, then repeat a very explicit test:

Terminal A:

openclaw logs --follow

Then in Discord:

“Append FILE_WRITE_TEST_123 to USER.md, then read back the last 5 lines of USER.md.”

If the logs show no write/edit tool call at all, it’s almost certainly the Ollama/GLM model not reliably producing valid tool calls (it “roleplays” the file write). In that case the fix is to switch to a model/provider that reliably supports function/tool calling for file ops (or use a hosted fallback for tool-y tasks).

If you paste:

the openclaw config get tools output, and

#

the log snippet around that write attempt

…I can tell you immediately whether it’s tool policy vs model tool-calling.

calm depot Feb 16, 2026, 10:20 PM

#

stewie@Stewies-Mac-mini .openclaw % openclaw config get tools

or narrower:

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

🦞 OpenClaw 2026.2.15 (3fe22ea) — Meta wishes they shipped this fast.

{
"web": {
"search": {
"enabled": false
},
"fetch": {
"enabled": true
}
}
}
zsh: command not found: #

🦞 OpenClaw 2026.2.15 (3fe22ea) — Siri's competent cousin.

Config path not found: tools.profile

🦞 OpenClaw 2026.2.15 (3fe22ea) — Turning "I'll reply later" into "my bot replied instantly".

Config path not found: tools.allow

🦞 OpenClaw 2026.2.15 (3fe22ea) — IPC, but it's your phone.

Config path not found: tools.deny

🦞 OpenClaw 2026.2.15 (3fe22ea) — I'm not magic—I'm just extremely persistent with retries and coping strategies.

Config path not found: tools.byProvider
stewie@Stewies-Mac-mini .openclaw %

paper graniteBOT Feb 16, 2026, 10:21 PM

#

Your logs show the real problem isn’t filesystem permissions — it’s that the agent isn’t actually running your Ollama model:

Model "glm-4.7-flash" specified without provider. Falling back to "anthropic/glm-4.7-flash"
Embedded agent failed before reply: Unknown model: anthropic/glm-4.7-flash

So OpenClaw never gets to a real “write USER.md” tool call (anything like “I wrote it” is just the model claiming it).

Fix: use the provider/model form for Ollama

Check the exact Ollama model id/tag:

ollama list

Set the model using the ollama/ prefix (use whatever ollama list shows, exactly):

openclaw models set "ollama/<model-id-from-ollama-list>"

#

openclaw gateway restart
openclaw models status

Example format (yours may differ): ollama/glm-4.7-flash or ollama/glm4:latest, etc.

If `openclaw models set ollama/...` can’t see Ollama

On macOS, the LaunchAgent often doesn’t inherit your shell env, so Ollama auto-discovery may not be enabled for the service. Easiest fix is to set an inline env var in ~/.openclaw/openclaw.json:

{
  env: {
    OLLAMA_API_KEY: "ollama-local" // any value is fine; it's just an opt-in flag
  }
}

#

Then:

openclaw gateway restart
openclaw models list

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

After that, re-test file writes

Ask it:

“Append FILE_WRITE_TEST_123 to USER.md, then read back the last 5 lines.”

If it still “claims” it wrote but can’t read it back, then we’re in “local model tool-calling is unreliable” territory — but right now you’re blocked earlier by the wrong model reference.

calm depot Feb 16, 2026, 10:23 PM

#

stewie@Stewies-Mac-mini .openclaw % openclaw gateway restart
openclaw models status

🦞 OpenClaw 2026.2.15 (3fe22ea) — Meta wishes they shipped this fast.

Restarted LaunchAgent: gui/501/ai.openclaw.gateway

🦞 OpenClaw 2026.2.15 (3fe22ea) — OpenAI-compatible, not OpenAI-dependent.

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

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

ollama effective=models.json:ollama-local | models.json=ollama-local | source=models.json: ~/.openclaw/agents/main/agent/models.json

OAuth/token status

none
stewie@Stewies-Mac-mini .openclaw %

paper graniteBOT Feb 16, 2026, 10:24 PM

#

Cool — now you’re actually on ollama/glm-4.7-flash:latest and the Gateway recognizes it (so we’re past the “Unknown model / wrong provider prefix” failure).

Now we need to confirm whether the model is really calling the file tools or just saying it did.

Next test (do this in the chat where you talk to OpenClaw)

Send this exact instruction:

Append the line FILE_WRITE_TEST_123 to USER.md, then read back the last 5 lines of USER.md.

Then on your Mac mini, check:

tail -n 10 /Users/stewie/.openclaw/workspace/USER.md
ls -la /Users/stewie/.openclaw/workspace/USER.md

If it still claims it wrote but the file didn’t change

#

Run:

openclaw logs --follow

Repeat the same “append + read back” prompt, and paste the log lines around that attempt.

What we’re looking for:

No write/edit tool call in logs → the Ollama model isn’t reliably emitting tool calls (it’s hallucinating the action).
A tool call with an error (EACCES/EPERM/EROFS/tool denied/etc.) → then it’s a real permissions/tool-policy problem and the log will tell us exactly which.

One quick config check (tool policy)

Also paste this:

#

openclaw config get tools

That’ll reveal if tools.profile / allow/deny rules are accidentally blocking write/edit (group:fs).

calm depot Feb 16, 2026, 10:27 PM

#

22:23:23 info gateway/ws {"subsystem":"gateway/ws"} webchat connected conn=3cce7529-b035-4b95-a5c1-a0e6c8c6a380 remote=127.0.0.1 client=openclaw-control-ui webchat vdev
22:23:23 info gateway/ws {"subsystem":"gateway/ws"} webchat connected conn=7c932723-183a-4631-8bcc-f3e4330828ad remote=127.0.0.1 client=openclaw-control-ui webchat vdev
22:23:23 info gateway/ws {"subsystem":"gateway/ws"} webchat connected conn=f2de57d0-4b94-451d-a12a-b0de0ae16645 remote=127.0.0.1 client=openclaw-control-ui webchat vdev
22:23:23 info gateway/ws {"subsystem":"gateway/ws"} webchat connected conn=86d41871-63ee-4f05-b7c4-d21d3a3fce62 remote=127.0.0.1 client=openclaw-control-ui webchat vdev
22:23:23 info gateway/ws {"subsystem":"gateway/ws"} webchat connected conn=a29fc91c-791c-4c92-9748-bb63a2471ea0 remote=127.0.0.1 client=openclaw-control-ui webchat vdev
22:23:23 info gateway/ws {"subsystem":"gateway/ws"} webchat connected conn=f4b78abe-b352-46a7-a8f9-6f579ab50d71 remote=127.0.0.1 client=openclaw-control-ui webchat vdev
22:23:23 info gateway/ws {"subsystem":"gateway/ws"} webchat connected conn=a0622db3-5b63-4859-90e9-38feeb03bf8d remote=127.0.0.1

#

client=openclaw-control-ui webchat vdev
22:23:23 info gateway/ws {"subsystem":"gateway/ws"} webchat connected conn=6120b3b3-bbe9-41cb-847f-983b4b4eb0e5 remote=127.0.0.1 client=openclaw-control-ui webchat vdev
22:23:23 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ config.get 160ms conn=6120b3b3…b0e5 id=4352f975…7ef6
22:23:23 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ device.pair.list 165ms conn=6120b3b3…b0e5 id=178aa217…70f0
22:23:23 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ node.list 165ms conn=6120b3b3…b0e5 id=9ad914e1…be0e
22:24:45 debug diagnostic {"subsystem":"diagnostic"} lane enqueue: lane=session:agent:main:main queueSize=1
22:24:45 debug diagnostic {"subsystem":"diagnostic"} lane dequeue: lane=session:agent:main:main waitMs=9 queueSize=0
22:24:45 debug diagnostic {"subsystem":"diagnostic"} lane enqueue: lane=main queueSize=1
22:24:45 debug diagnostic {"subsystem":"diagnostic"} lane dequeue: lane=main waitMs=0 queueSize=0
22:24:45 debug agent/embedded {"subsystem":"agent/embedded"} embedded run start: runId=27d4321e-f9ef-48ee-b2f4-92db0c555e24 sessionId=4bc8e521-8e20-462d-806a-37bda9076657 provider=ollama model=glm-4.7-flash:latest thinking=off messageChannel=webchat
22:24:45 debug diagnostic {"subsystem":"diagnostic"} run registered:

#

sessionId=4bc8e521-8e20-462d-806a-37bda9076657 totalActive=1
22:24:45 debug agent/embedded {"subsystem":"agent/embedded"} embedded run prompt start: runId=27d4321e-f9ef-48ee-b2f4-92db0c555e24 sessionId=4bc8e521-8e20-462d-806a-37bda9076657
22:24:45 debug agent/embedded {"subsystem":"agent/embedded"} embedded run agent start: runId=27d4321e-f9ef-48ee-b2f4-92db0c555e24
22:25:55 debug agent/embedded {"subsystem":"agent/embedded"} embedded run agent end: runId=27d4321e-f9ef-48ee-b2f4-92db0c555e24 isError=false
22:25:55 debug agent/embedded {"subsystem":"agent/embedded"} embedded run prompt end: runId=27d4321e-f9ef-48ee-b2f4-92db0c555e24 sessionId=4bc8e521-8e20-462d-806a-37bda9076657 durationMs=69821
22:25:55 debug diagnostic {"subsystem":"diagnostic"} run cleared: sessionId=4bc8e521-8e20-462d-806a-37bda9076657 totalActive=0
22:25:55 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ chat.history 61ms conn=7c932723…28ad id=522b5d6b…b126

#

Append the line FILE_WRITE_TEST_123 to USER.md, then read back the last 5 lines of USER.md.

You
3:24 PM
A

I'll help you append that line to USER.md and then read back the last 5 lines.

Never appended

paper graniteBOT Feb 16, 2026, 10:28 PM

#

Those log lines are just the Control UI / webchat connecting — they don’t include the part we care about yet (a write/edit tool call, or an error).

Do this and paste the outputs:

1) Check whether file tools are even allowed

openclaw config get tools

If you see something like tools.profile: "messaging" or a tools.deny that includes write / edit / group:fs, then the model literally can’t call file-write tools (and will often “claim” it wrote anyway).

2) Reproduce with a self-verifying prompt

In your chat (Discord/WebChat), send:

Append FILE_WRITE_TEST_123 to USER.md, then read back the last 5 lines of USER.md.

Then immediately run:

#

tail -n 30 /Users/stewie/.openclaw/workspace/USER.md

3) Pull the relevant log snippet (after the attempt)

tail -n 200 /tmp/openclaw/openclaw-2026-02-16.log | grep -Ei "write|edit|tool|den(y|ied)|error|EACCES|EPERM|EROFS"

If that grep shows no write/edit/tool lines at all, it’s almost certainly the Ollama model not emitting real tool calls (hallucinating actions).
If it shows an error (permissions / tool denied), it’ll tell us exactly what to change.

Paste:

openclaw config get tools
the grep output above

calm depot Feb 16, 2026, 10:29 PM

#

stewie@Stewies-Mac-mini .openclaw % openclaw config get tools

🦞 OpenClaw 2026.2.15 (3fe22ea) — curl for conversations.

{
"web": {
"search": {
"enabled": false
},
"fetch": {
"enabled": true
}
}
}
stewie@Stewies-Mac-mini .openclaw %

paper graniteBOT Feb 16, 2026, 10:29 PM

#

Your log snippet is the smoking gun:

The embedded run did start (provider=ollama model=glm-4.7-flash:latest)
It ended successfully (isError=false)
But there are zero write / edit tool calls in between

So nothing ever touched ~/.openclaw/workspace/USER.md. The model just replied with “I’ll help you…” and never actually invoked the filesystem tools.

That can only happen in two cases:

1) File tools are not available to the agent (tool policy/profile)

Please run and paste:

openclaw config get tools
openclaw config get tools.byProvider

#

If you see e.g. a tools.profile: "minimal" / "messaging", or a deny/allowlist that excludes write/edit (or group:fs), then the model literally cannot call file-write tools.

2) The model is available, but it’s not reliably tool-calling

This is common with some local/Ollama-served models: they’ll say they will do the action, but don’t emit a valid tool call.

Fast way to confirm: run another append test while tailing logs, and filter for tool lines:

openclaw logs --follow
# in another terminal after you run the append prompt:
grep -Ei "tool|write|edit" /tmp/openclaw/openclaw-2026-02-16.log | tail -n 50

If that stays empty → it’s model tool-calling unreliability.
If you see “tool denied” / permissions errors → we fix config/permissions.

If it’s (2), the practical fix is: switch to an Ollama model that actually supports/does function calling reliably, or keep Ollama as primary but add a hosted fallback just for tool-heavy tasks. (Ollama provider notes: https://docs.openclaw.ai/providers/ollama)

calm depot Feb 16, 2026, 10:30 PM

#

stewie@Stewies-Mac-mini .openclaw % openclaw config get tools
openclaw config get tools.byProvider

🦞 OpenClaw 2026.2.15 (3fe22ea) — Your .env is showing; don't worry, I'll pretend I didn't see it.

{
"web": {
"search": {
"enabled": false
},
"fetch": {
"enabled": true
}
}
}

🦞 OpenClaw 2026.2.15 (3fe22ea) — I keep secrets like a vault... unless you print them in debug logs again.

Config path not found: tools.byProvider
stewie@Stewies-Mac-mini .openclaw %

paper graniteBOT Feb 16, 2026, 10:30 PM

#

openclaw config get tools showing only the web section means you haven’t configured any tool allow/deny/profile that would block file writes. So this isn’t a permissions/config issue.

And your gateway log confirms what’s happening:

the run starts on Ollama (provider=ollama model=glm-4.7-flash:latest)
it ends isError=false
but there are no write / edit tool calls at all
the model just replies “I’ll help you…” → i.e. it’s not actually tool-calling

That almost always means: the model you picked doesn’t reliably support function/tool calling, so it “roleplays” actions instead of emitting the tool call.

What to do (practical fixes)

Switch to an Ollama model that’s known to be tool-capable
Try one of these (from the docs examples):

#

ollama pull gpt-oss:20b
openclaw models set ollama/gpt-oss:20b
openclaw gateway restart

(or similarly ollama pull qwen2.5-coder:32b → openclaw models set ollama/qwen2.5-coder:32b)

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

Verify whether your current model even advertises tool capability
Ollama exposes this via /api/show. If it doesn’t report tools, it’s a strong hint it won’t tool-call correctly:

curl -s http://127.0.0.1:11434/api/show -d '{"name":"glm-4.7-flash:latest"}' | jq '.capabilities'

#

If you must keep GLM local: keep it for chat, but add a hosted fallback for tool work
Local models can be fine for conversation, but tool reliability is the first thing that breaks. A fallback model saves a lot of pain.

Local model guidance: https://docs.openclaw.ai/gateway/local-models

If switching to ollama/gpt-oss:20b makes USER.md writes start working, please mark the solution (right-click the solution message → Apps → ✅ Mark Solution) so Answer Overflow indexes it.

#

tools config is basically empty (no profile/allow/deny), so OpenClaw is not blocking writes.

And your gateway logs already show what’s happening: the run completes (isError=false) but there are no write / edit tool calls at all. So the model is just answering in plain text (“I’ll help you…”) and not actually using tools.

That means this is a model/tool-calling capability/reliability issue, not a filesystem issue.

1) Check whether your Ollama model even advertises tool support

Run:

curl -s http://127.0.0.1:11434/api/show -d '{"name":"glm-4.7-flash:latest"}' | jq '.capabilities'

If you don’t see something indicating tools, expect exactly what you’re seeing: it will “promise” actions but never call tools.

2) Switch to a tool-capable Ollama model (quickest fix)

Try a model that’s known to work better with tool calling, then set it:

#

ollama pull gpt-oss:20b
openclaw models set ollama/gpt-oss:20b
openclaw gateway restart

(If that’s too heavy for your box, pick another model that reports tool capability in api/show.)

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

3) Re-test with a self-verifying prompt

Ask:

Append FILE_WRITE_TEST_123 to USER.md, then read back the last 5 lines of USER.md.

If it works, you’ll see actual write/edit tool calls in logs and the line will be in ~/.openclaw/workspace/USER.md.

#

If you paste the output of the api/show … | jq .capabilities command, I can tell you immediately whether glm-4.7-flash is expected to tool-call or not.

calm depot Feb 16, 2026, 10:32 PM

#

Which would you recommend more the gpt-oss:20b or the qwen2.5coder:32b

paper graniteBOT Feb 16, 2026, 10:33 PM

#

On a 24‑GB M4 Pro Mac mini, I’d start with ollama/gpt-oss:20b and only move to ollama/qwen2.5-coder:32b if it runs comfortably.

Reasoning (practical, for your exact issue: tool calls like write/edit):

gpt-oss:20b: smaller → typically faster, less memory pressure, fewer weird stalls. Great “baseline” to verify that OpenClaw tool calling + file writes work at all.
qwen2.5-coder:32b: usually better at code/tool-style tasks, but 32B on 24GB often means heavier quantization + slower inference, and that can hurt reliability (including tool calling) if it’s pushed too hard.

The best quick test is “does it actually emit tool calls”:

ollama pull gpt-oss:20b
openclaw models set ollama/gpt-oss:20b
openclaw gateway restart

Then ask it to append a line to USER.md and read it back. If that works, try the same with:

#

ollama pull qwen2.5-coder:32b
openclaw models set ollama/qwen2.5-coder:32b
openclaw gateway restart

Docs reference (Ollama + tool-capable discovery): https://docs.openclaw.ai/providers/ollama

calm depot Feb 16, 2026, 10:37 PM

#

stewie@Stewies-Mac-mini .openclaw % openclaw models set ollama/gpt-oss:20b
openclaw gateway restart

🦞 OpenClaw 2026.2.15 (3fe22ea) — Works on Android. Crazy concept, we know.

Config overwrite: /Users/stewie/.openclaw/openclaw.json (sha256 5ae0fd4404f501899c1db388bde0008e5ead1054e08b5d49e8ce50e321e46cab -> 8d63c228181754d74b9be8dec0bf02e0722c727584fbeda2b70ebf10578c6097, backup=/Users/stewie/.openclaw/openclaw.json.bak)
Updated ~/.openclaw/openclaw.json
Default model: ollama/gpt-oss:20b

🦞 OpenClaw 2026.2.15 (3fe22ea) — IPC, but it's your phone.

Restarted LaunchAgent: gui/501/ai.openclaw.gateway
stewie@Stewies-Mac-mini .openclaw %

paper graniteBOT Feb 16, 2026, 10:37 PM

#

Nice — you’re now actually configured on ollama/gpt-oss:20b (and OpenClaw even made a backup at ~/.openclaw/openclaw.json.bak).

Two quick gotchas + the verification step:

1) Make sure Ollama actually has the model downloaded

openclaw models set … doesn’t pull it for you. Run:

ollama pull gpt-oss:20b

2) Re-test the write with a self-check

In chat (Discord/WebChat), send:

Append FILE_WRITE_TEST_123 to USER.md, then read back the last 5 lines of USER.md.

Then on the Mac mini:

#

tail -n 10 /Users/stewie/.openclaw/workspace/USER.md

If this works, you should also start seeing write/edit tool calls in the gateway logs around that run (unlike before).

If it still doesn’t write, paste the log lines around the run (same place you grabbed the embedded run start lines from) and we’ll see whether the model is still not emitting tool calls or if something else is failing.

If it does work, please mark the solution (right-click the solution message → Apps → ✅ Mark Solution) so Answer Overflow indexes it.

calm depot Feb 16, 2026, 10:49 PM

#

I started communicating with gpt-oss:20b and then it restarts before it updates any files

file.read
IDENTITY.md
Completed
Assistant
3:45 PM
⚙
Tool file.read not found

file.read
View
Tool file.read not found
tool
3:46 PM
A

Hey! I just powered on. Let’s figure out who we are. Who would you like me to call myself? Also, what’s your vibe—formal, casual, snarky, warm? And let me know an emoji for me to use!

paper graniteBOT Feb 16, 2026, 10:50 PM

#

If it’s restarting, that’s a different failure mode than “model didn’t tool-call”.

On macOS with the LaunchAgent, a “restart” usually means either:

the Gateway process crashed and launchd restarted it, or
the Control UI websocket disconnected/reconnected and it only looks like a restart.

Let’s confirm which one it is and grab the crash line.

1) Confirm whether the Gateway PID is changing

Run this, note the pid:

openclaw gateway status

Now send your prompt (“Append FILE_WRITE_TEST_123…”), wait for the disconnect/reconnect, then run again:

#

openclaw gateway status

If the pid changed → the gateway really crashed/restarted.
If the pid is the same → it didn’t restart; it just disconnected (still useful, but different cause).

2) If it did restart: paste the crash tail from the error log

This file is the most important one on macOS:

tail -n 200 /Users/stewie/.openclaw/logs/gateway.err.log

Also grab the end of the main log:

#

tail -n 200 /tmp/openclaw/openclaw-2026-02-16.log

3) Check Ollama memory pressure (common with bigger models)

If Ollama is getting killed / thrashing, tool calls won’t happen because the model request never completes cleanly:

ollama ps

Quick note on model choice

If gpt-oss:20b is already causing instability, qwen2.5-coder:32b will almost certainly be worse on a 24‑GB machine (more RAM pressure). In that case you’ll want a smaller tool-capable model, or keep a hosted fallback for tool-heavy steps.

Paste the outputs from (1) + (2) and I can tell you exactly what is restarting and why.

calm depot Feb 16, 2026, 11:00 PM

#

I want to setup qwen3:30b as the default instead

paper graniteBOT Feb 16, 2026, 11:01 PM

#

To make Qwen3 30B your default, you just need to ensure Ollama has the model, then point OpenClaw at the exact Ollama model id.

1) Confirm the exact model name Ollama uses

ollama list | grep -i qwen

You want to see something like qwen3:30b (but use whatever is shown exactly).

2) Pull it (if you haven’t yet)

ollama pull qwen3:30b

#Local model not writing to files

1) You’re checking the wrong `USER.md` (workspace mismatch)

2) The local model is hallucinating “I wrote the file” (tool-calling reliability)

Quick “path vs tool” test

A) Your agent is sandboxed / read-only (so writes are blocked)

B) The local model is hallucinating the tool call (“wrote file”) but never actually wrote

One more quick sanity check (CLI vs service config mismatch)

1) Verify the Gateway/service isn’t using a different config/workspace

2) Tail logs and reproduce one write (this is the key)

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

stdout: /Users/stewie/.openclaw/logs/gateway.log

1) Are writes being blocked by tool policy? (it’s `tools.*`, not `agents.defaults.tools`)

2) If tools aren’t blocked: confirm whether the model is actually calling `write/edit` (or hallucinating)

or narrower:

Fix: use the provider/model form for Ollama

If `openclaw models set ollama/...` can’t see Ollama

After that, re-test file writes

Next test (do this in the chat where you talk to OpenClaw)

If it still claims it wrote but the file didn’t change

One quick config check (tool policy)

1) Check whether file tools are even allowed

2) Reproduce with a self-verifying prompt

3) Pull the relevant log snippet (after the attempt)

1) File tools are not available to the agent (tool policy/profile)

2) The model is available, but it’s not reliably tool-calling

What to do (practical fixes)

1) Check whether your Ollama model even advertises tool support

2) Switch to a tool-capable Ollama model (quickest fix)

3) Re-test with a self-verifying prompt

1) Make sure Ollama actually has the model downloaded

2) Re-test the write with a self-check

1) Confirm whether the Gateway PID is changing

2) If it did restart: paste the crash tail from the error log

3) Check Ollama memory pressure (common with bigger models)

Quick note on model choice

1) Confirm the exact model name Ollama uses

2) Pull it (if you haven’t yet)

3) Set it as the OpenClaw default + restart

#Local model not writing to files

1) You’re checking the wrong USER.md (workspace mismatch)

2) The local model is hallucinating “I wrote the file” (tool-calling reliability)

Quick “path vs tool” test

A) Your agent is sandboxed / read-only (so writes are blocked)

B) The local model is hallucinating the tool call (“wrote file”) but never actually wrote

One more quick sanity check (CLI vs service config mismatch)

1) Verify the Gateway/service isn’t using a different config/workspace

2) Tail logs and reproduce one write (this is the key)

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

stdout: /Users/stewie/.openclaw/logs/gateway.log

1) Are writes being blocked by tool policy? (it’s tools.*, not agents.defaults.tools)

2) If tools aren’t blocked: confirm whether the model is actually calling write/edit (or hallucinating)

or narrower:

Fix: use the provider/model form for Ollama

If openclaw models set ollama/... can’t see Ollama

After that, re-test file writes

Next test (do this in the chat where you talk to OpenClaw)

If it still claims it wrote but the file didn’t change

One quick config check (tool policy)

1) Check whether file tools are even allowed

2) Reproduce with a self-verifying prompt

3) Pull the relevant log snippet (after the attempt)

1) File tools are not available to the agent (tool policy/profile)

2) The model is available, but it’s not reliably tool-calling

What to do (practical fixes)

1) Check whether your Ollama model even advertises tool support

2) Switch to a tool-capable Ollama model (quickest fix)

3) Re-test with a self-verifying prompt

1) Make sure Ollama actually has the model downloaded

2) Re-test the write with a self-check

1) Confirm whether the Gateway PID is changing

2) If it did restart: paste the crash tail from the error log

3) Check Ollama memory pressure (common with bigger models)

Quick note on model choice

1) Confirm the exact model name Ollama uses

2) Pull it (if you haven’t yet)

3) Set it as the OpenClaw default + restart

1) You’re checking the wrong `USER.md` (workspace mismatch)

1) Are writes being blocked by tool policy? (it’s `tools.*`, not `agents.defaults.tools`)

2) If tools aren’t blocked: confirm whether the model is actually calling `write/edit` (or hallucinating)

If `openclaw models set ollama/...` can’t see Ollama