Unable to read/write outside of workspace

[rustic ember]

I just performed a fresh install on a brand new workstation with Ubuntu 26.04 freshly loaded. I am attempting to allow openclaw access to select folders on the same machine, to monitor for specific files that I want to schedule tasks against. The install was successful, the gateway is up and reachable, my tools profile shows "coding", but for some reason I cannot get it to read and write files outside of it's own .openclaw directory. Looking at the docs, it looks like the coding profile should allow this, and I've even attempted to set it to "full" without success. When editing the json with allow fs and groups, the gateway fails to load successfully. Any help in enabling this function?

[strong kelp]

tx_jeeper, the important distinction is: tools.profile: "coding" enables the file tools, but it does not mean “ignore sandbox/workspace guards everywhere.”

From your screenshots:

• version appears to be 2026.5.12
• tools.profile is already "coding", which includes group:fs
• I don’t see an explicit tools.fs.workspaceOnly setting
• connected-no-operator-scope is about the Control UI/gateway operator connection, not the same thing as file-tool path access

I’d check the effective sandbox first:

openclaw --version
openclaw sandbox explain
openclaw config get tools.profile
openclaw config get tools.fs.workspaceOnly
openclaw config get tools.exec.applyPatch.workspaceOnly

[strong kelp]

openclaw config get agents.defaults.sandbox.mode
openclaw config validate

If you want normal local host filesystem access from the main agent, the usual baseline is:

openclaw config set tools.profile coding
openclaw config set tools.fs.workspaceOnly false
openclaw config set agents.defaults.sandbox.mode off
openclaw gateway restart

Then start a fresh session and test with an absolute path, e.g. “read /home/you/some-folder/test.txt”.

Two gotchas:

[strong kelp]

• apply_patch is workspace-only by default even when normal read/write/edit are not. If the failure is specifically from patching outside the workspace, that is controlled by tools.exec.applyPatch.workspaceOnly, not just tools.fs.workspaceOnly.
• If you edit openclaw.json by hand, the correct group name is "group:fs" inside an array, e.g. tools: { allow: ["group:fs", "group:runtime"] }. But with profile: "coding", you shouldn’t need to add that manually.

Docs:
https://docs.openclaw.ai/gateway/sandbox-vs-tool-policy-vs-elevated
https://docs.openclaw.ai/gateway/sandboxing
https://docs.openclaw.ai/gateway/configuration-reference#tools
https://docs.openclaw.ai/cli/config

If those commands still show workspaceOnly=false and sandbox off but absolute reads fail, paste the exact error text plus the output of openclaw sandbox explain and openclaw config validate. That’ll tell us which layer is actually blocking it.

[rustic ember]

I ran the following suggested commands for local host filesystem access, as recommended:
openclaw config set tools.profile coding
openclaw config set tools.fs.workspaceOnly false
openclaw config set agents.defaults.sandbox.mode off
openclaw gateway restart
All completed successfully.
Afterwards, I re-ran the prompt to create a blank file within /home/user/Documents and the agent confirmed it completed successfully. Looking within that directory, no such file exists.

[strong kelp]

That screenshot is useful: ll in /home/jonathan/Documents would show hello.txt if it existed, so this looks less like Linux permissions and more like the agent said “done” without a real filesystem write landing.

Two things to test next:

openclaw sandbox explain
openclaw config validate
openclaw logs --follow

Then in a fresh session ask something very explicit:

Use the write tool to create /home/jonathan/Documents/hello.txt with empty contents. After writing it, use the read or exec tool to verify it exists.

Or force the shell path:

[strong kelp]

Use exec to run: touch /home/jonathan/Documents/hello.txt && ls -l /home/jonathan/Documents/hello.txt

If the agent replies success but you do not see a visible write or exec tool call/result in the UI/logs, that’s model/tool-calling behavior, not filesystem config. Your earlier status screenshot looked like a local Ollama/Qwen-style model was active; those can be flaky with tool use and may confidently answer without actually calling the tool. For this kind of file operation, try a more tool-reliable model/runtime or check #models for current working setups: https://docs.openclaw.ai/concepts/models#model-discussions-community-notes

Also: because this was an existing conversation, don’t trust the old session state after changing sandbox config. Start a new session after the gateway restart, or reset/close the old one, then retest.

[rustic ember]

At this point I have:

1. Run the following commands as recommended.
   openclaw config set tools.profile coding
   openclaw config set tools.fs.workspaceOnly false
   openclaw config set agents.defaults.sandbox.mode off
   openclaw gateway restart

2. changed the model from qwen3.6 to gemma4:latest

run several variations of: Use the write tool to create /home/jonathan/Documents/hello.txt with empty contents. After writing it, use the read or exec tool to verify it exists.

monitoring the logs with: "openclaw logs --follow" sometimes I see that I get an error that it cannot write /home/jonathan/hello.txt, which is not the location that I requested it to be written to. Other times, I get an error in chat and nothing in the logs. The screenshot shows the latest error in chat, with nothing in the logs.

by all recommendations and settings that have been provided, this should be functioning. any other recommendations?

[strong kelp]

This screenshot is the key clue. The write tool is not being blocked by filesystem config here; it is failing validation before any filesystem write happens:

Validation failed for tool "write":
path: must have required properties path

Received arguments:
{
  "file": "/home/user/hello.txt",
  "content": ""
}

The tool expects path, but the model sent file. It also changed your requested path to /home/user/hello.txt. That’s model/tool-calling failure, not Ubuntu permissions and not tools.fs.workspaceOnly.

Since both qwen3.6 and gemma4:latest are local/Ollama-style models, I’d stop debugging filesystem policy for the moment and isolate model compliance:

[strong kelp]

1. Start a fresh session.
2. Use a known tool-reliable cloud/runtime setup temporarily.
3. Run exactly the same request.
4. Watch for the actual tool call arguments. A good write call should contain:

{
  "path": "/home/jonathan/Documents/hello.txt",
  "content": ""
}

If that works with a tool-reliable model, your OpenClaw config is fine and the local model is the problem. Local models can technically work, but many are still rough at structured tool calls: wrong parameter names, path drift, or claiming success after a failed tool call. #models is the right place for fresh working local-model reports: https://docs.openclaw.ai/concepts/models#model-discussions-community-notes

If you want one more local-only experiment, add a very blunt instruction to your workspace AGENTS.md: