Read/Write Access for local-only OpenClaw

[ionic bough]

I think I must be dumb because I've been fighting this for hours now. I cannot get any agents to read any local files or even workspace files with the exception of the .md files, it won't list off what's in the workspace directory (I know what's in there but I need to see if it has read/write access)

I've been trying out qwen3.5/gemma4 to see how they work for me as I'm trying to develop an AI-featured discord bot. The bot itself seems to be working already, it's more the fact that I can't get this to read/write to a local space to store information as needed.

[thin echo]

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

[hidden cosmos]

You’re probably not dumb. That screenshot reads like the model is talking about tools instead of actually calling them, which usually means either the tools are not exposed to that session, or the local model isn’t reliably tool-calling.

First thing: what does this show?

openclaw --version
openclaw status --all
openclaw models status

The checks I’d do next:

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

[hidden cosmos]

openclaw config get agents.defaults.workspace
openclaw exec-policy show

For local workspace read/write, you generally want a coding-capable tool profile, for example:

openclaw config set tools.profile coding

If you are using an explicit allowlist, make sure it includes filesystem + runtime tools, not only messaging:

{
  tools: {

[hidden cosmos]

    allow: ["group:fs", "group:runtime", "group:web", "group:memory"],
  }
}

Also check you didn’t deny the important bits:

tools: { deny: ["exec", "read", "write", "apply_patch"] }

would block exactly the behavior you’re testing.

A good prompt to test is very literal:

Use the exec tool to run pwd and ls -la. Then use the read tool to read AGENTS.md.

[hidden cosmos]

If the reply says “I can’t browse files” instead of showing tool output, that’s model/tool-call failure or the tools are hidden from the session.

One more important local-model gotcha: if this is Ollama, use the native Ollama URL, not the OpenAI-compatible /v1 URL. The docs call out that http://host:11434/v1 can break tool calling; use baseUrl: "http://host:11434" instead.

Docs:
https://docs.openclaw.ai/concepts/agent-workspace
https://docs.openclaw.ai/tools/exec
https://docs.openclaw.ai/tools
https://docs.openclaw.ai/providers/ollama

If you paste the version + those config outputs, we can narrow it down fast. 🦞

[hidden cosmos]

That version is current enough to rule out a lot of older workspace bugs: OpenClaw 2026.5.18 (50a24a1).

Next useful bit is the tool/profile config. Please run:

openclaw config get tools.profile
openclaw config get tools.allow
openclaw config get tools.deny
openclaw config get agents.defaults.workspace
openclaw exec-policy show

If tools.profile is missing or not coding, set it:

openclaw config set tools.profile coding

[hidden cosmos]

openclaw gateway restart

Then test with a very direct prompt:

Use the exec tool to run pwd and ls -la. Then read AGENTS.md.

If it still answers with “I can’t access files” instead of calling tools, the next suspect is the local model/tool-calling path, especially if it’s Ollama through a /v1 OpenAI-compatible URL.

[hidden cosmos]

This status looks healthy from the workspace side:

• Gateway reachable
• Discord OK
• Agent active
• Workspace detected at C:\Users\area5\.openclaw\workspace
• Skills/tools: 16 eligible · 0 missing
• No channel issues

So this is probably not “OpenClaw can’t see the workspace.” It’s more likely tool policy or the model not issuing tool calls.

Please run these next:

openclaw config get tools.profile
openclaw config get tools.allow

[hidden cosmos]

openclaw config get tools.deny
openclaw config get agents.defaults.model
openclaw config get models.providers.ollama
openclaw exec-policy show

If tools.profile is empty/missing, do:

openclaw config set tools.profile coding
openclaw gateway restart

Then in Discord, test with this exact wording:

Use the exec tool. Run pwd and ls -la in the workspace. Do not explain limitations; call the tool.

[hidden cosmos]

If it still refuses or describes tools instead of using them, that points at the local model. For Ollama specifically, make sure your provider config uses native Ollama, e.g. baseUrl: "http://127.0.0.1:11434", not http://127.0.0.1:11434/v1. The /v1 route is known to break tool calling.

[ionic bough]

full access for tools. tools.allow&deny config path not found.

[hidden cosmos]

Yep, that output is actually useful: this is not a workspace permission/config problem.

What your screenshots show:

• tools.profile = full
• tools.allow / tools.deny missing just means “unset”, not blocked
• exec policy is security=full ask=off
• workspace is detected
• Ollama config is using native http://127.0.0.1:11434, not the broken /v1 path

So OpenClaw is giving the session enough access. The failure is almost certainly the model: ollama/qwen3.5:4b is describing what it could do instead of emitting valid tool calls.

Two quick ways to prove it:

1. Temporarily switch the session to a known strong tool-calling model, then send the exact same prompt:

   Use the exec tool to run pwd and ls -la.

[hidden cosmos]

2. If you want to stay local-only, try a much stronger local model and ask in #models for current local tool-calling recommendations. Small 4B-ish models can chat fine but fail badly at agentic tool use.

You can also run:

openclaw models status
openclaw logs --follow

Then send the bad prompt again. If logs show a normal model response with no tool call, that confirms it’s model behavior, not permissions.

Docs for the relevant bits:
https://docs.openclaw.ai/tools
https://docs.openclaw.ai/tools/exec
https://docs.openclaw.ai/concepts/models#model-discussions-community-notes

[hidden cosmos]

That second screenshot confirms the key part: your active/default model is still ollama/qwen3.5:4b.

The first screenshot is the model refusing in prose, but it also admits tools exist: read, write, exec, etc. That means OpenClaw is exposing tools; the model is choosing not to call them.

Try switching away from the 4B model for this session. Your config screenshot showed qwen3.5:9b is also configured, so try that first:

openclaw models set ollama/qwen3.5:9b
openclaw gateway restart

Then test with one extremely explicit message:

Use the exec tool now. Run exactly: pwd && ls -la
After the tool result, summarize the output.

[hidden cosmos]

If the 9B model still gives the same “I do not have direct access” prose, the local Ollama model path is not reliable enough for tool calling in this setup. At that point I’d use a cloud/stronger tool-calling model for the bot-building work, or ask in #models for current local-only tool-calling recommendations.

One small prompt workaround you can add to AGENTS.md may help, but it will not fix a model that cannot emit valid tool calls:

When asked to inspect, list, read, or write workspace files, use the available read/write/exec tools directly. Do not claim you lack filesystem access if those tools are available.

This is model behavior now, not permissions.

[ionic bough]

I've tried three different models and they all state the same. Stating something about webchat capabilities = none

[hidden cosmos]

If three models all say the exact same “WebChat capabilities / none” thing, I’d stop treating this as model choice for a moment. Two likely causes:

1. You’re continuing a poisoned session history where the earlier assistant already said “I can’t access files”, so each new model repeats that.
2. The specific session you’re testing has no runtime tools, even though global config says full.

Please test both directly:

/tools
/status

Run those in the same WebChat/Discord thread where the failure happens. /tools is a command, not a model response, so it tells us what OpenClaw actually exposes to that session.

Then start fresh:

[hidden cosmos]

/reset

or:

/new

After that, send only this:

Use the exec tool now. Run exactly: pwd && ls -la

If /tools says “No tools are available for this agent right now”, then we need to debug runtime tool inventory/session binding. If /tools lists exec, read, write, etc., but the model still says WebChat has no capabilities in a fresh session, that’s a tool-call formatting/provider issue.

[hidden cosmos]

Docs: https://docs.openclaw.ai/web/webchat and https://docs.openclaw.ai/tools/slash-commands

[hidden cosmos]

This screenshot is the smoking claw: /tools says tools are available, including Exec, Read, Edit, etc.

But your /status still says the active session model is:

ollama/qwen3.5:4b

From your earlier config screenshot, the 9b entry had supportsTools: true; the 4b entry did not. So even if you changed the default elsewhere, this current session is still running the 4B model.

Switch the current session or start a new one with the 9B model:

/model ollama/qwen3.5:9b

or:

[hidden cosmos]

/new ollama/qwen3.5:9b

Then confirm:

/status

It should show Model: ollama/qwen3.5:9b, not 4b.

Then test:

Use the exec tool now. Run exactly: pwd && ls -la

[hidden cosmos]

If it still refuses after /status shows the 9B model, run openclaw logs --follow while sending that prompt. We want to see whether Ollama returns an actual tool call or just plain text.

[ionic bough]

Where do I run exec tool at?

[hidden cosmos]

Perfect, that confirms the runtime tool inventory is fine: exec, read, write, dir_list, file_fetch, file_write, etc. are all available.

At this point there are only two meaningful suspects left:

1. The current session is still on a non-tool-capable model. Check /status after switching. It must show the model you expect.
2. The model/provider response is plain text instead of a structured tool call.

Please do this exact sequence in the same chat:

/new ollama/qwen3.5:9b
/status
Use the exec tool now. Run exactly: pwd && ls -la

If it still refuses, grab logs during the failed turn:

[hidden cosmos]

openclaw logs --follow

The thing to look for is whether the model response contains an actual tool call or just the “WebChat capabilities” text. Since /tools proves tools are present, a plain-text refusal means the model is not using the tool API.

[hidden cosmos]

You don’t run exec in PowerShell directly. exec is an agent tool, so you ask the OpenClaw chat/agent to use it.

In the same Discord/WebChat conversation, send:

Use the exec tool now. Run exactly: pwd && ls -la

OpenClaw should then show a tool run/result in the chat. If the assistant replies with advice like “run this in your terminal” or “I don’t have access,” then the model failed to call the tool.

PowerShell is only for OpenClaw CLI commands like:

openclaw status --all
openclaw logs --follow
openclaw models set ollama/qwen3.5:9b

[hidden cosmos]

So: CLI commands go in PowerShell; exec tool requests go to the agent chat.

[ionic bough]

i see. doing that now.

[hidden cosmos]

Nice, that means the important part is fixed: the agent did call the exec tool.

The “No output” part is now a command/shell detail, not a permissions issue. Since you’re on Windows, try a PowerShell-native command:

Use the exec tool now. Run exactly: Get-Location; Get-ChildItem -Force

or:

Use the exec tool now. Run exactly: dir

If that returns a directory listing, read/write access is working. Then test file read/write with something harmless:

[hidden cosmos]

Use the exec tool to create a file named tool-test.txt in the workspace containing "hello from OpenClaw", then list the file and read it back.

Also, if the UI lets you expand the “JSON · 4 lines” tool input, it may show what shell/working directory was actually used.

[hidden cosmos]

Yep, that’s working now. It’s in:

C:\Users\area5\.openclaw\workspace

and it listed the workspace files/directories: .git, .openclaw, ameslan-review, AGENTS.md, MEMORY.md, etc.

So the remaining thing was how to ask the agent to use tools, plus making sure the active model/session was actually tool-capable. For read/write, try the harmless final check:

Use the exec tool to create a file named tool-test.txt in the workspace containing "hello from OpenClaw", then list it and read it back.

If that succeeds, you’ve got local workspace read/write through the agent. Glad we pinned it down. 🦞

[ionic bough]

It seems to be functioning now. Thank you!

[hidden cosmos]

Glad that helped! 🎉

If this fixed it, please right-click the solution message → Apps → ✅ Mark Solution. That helps Answer Overflow index it for the next person who gets stuck on tool access. 🦞