openclaw - 💡(How to fix) Fix Feature request: finer-grained FS permissions beyond tools.fs.workspaceOnly [1 participants]

Summary

When an agent enables tools.fs.workspaceOnly: true, filesystem access becomes too coarse-grained: the agent cannot read files outside its workspace, even in legitimate cases where read-only access to shared/global paths is needed.

This can break practical workflows such as:

• reading globally installed skills from ~/.agents/skills / ~/.openclaw/skills
• accessing shared reference files outside the agent workspace
• using multi-workspace setups where an agent needs safe read-only visibility into shared resources

Problem

Right now, tools.fs.workspaceOnly appears to act as a single switch for:

• read
• write
• edit
• apply_patch

So if we want to keep writes constrained to the workspace, but still allow narrowly scoped reads outside the workspace, there is no obvious built-in config for that.

In practice this leads to awkward workarounds:

• duplicating files into each workspace
• copying shared skills into per-agent workspaces
• disabling workspaceOnly entirely, which broadens both read and write access more than desired

Real-world example

In a multi-agent OpenClaw setup, a researcher agent with:

tools: {
  fs: { workspaceOnly: true }
}

was unable to reliably use globally installed skills such as Tavily skills, because the agent could not safely access paths outside its own workspace. Using symlinks inside the workspace was also insufficient in some cases, because skill discovery validates resolved realpaths and rejects targets outside the configured root.

The only workable workaround was to physically copy skill directories into the agent workspace.

Why this matters

workspaceOnly is a useful safety guard, but the current behavior is too binary for real multi-agent systems:

• security wants narrow write scope
• operations often need broader read scope

These two needs are different, but currently coupled.

Suggested improvements

Consider introducing finer-grained filesystem controls, for example:

Option A: separate read/write policy

tools: {
  fs: {
    workspaceOnlyWrite: true,
    workspaceOnlyRead: false,
  }
}

Option B: extra read-only allowlist

tools: {
  fs: {
    workspaceOnly: true,
    extraReadRoots: [
      "~/.agents/skills",
      "~/.openclaw/skills"
    ]
  }
}

Option C: per-agent read-only mounts / allowed roots

A mechanism similar to sandbox binds / mounts, but specifically for FS tool read access and skill discovery.

Expected outcome

This would let operators:

• keep writes strictly inside agent workspaces
• allow safe read-only access to shared/global resources
• avoid brittle duplication and symlink workarounds
• improve multi-agent operability without weakening safety too much

Notes

This feels especially important for:

• shared skill libraries
• global prompt/resource stores
• multi-agent knowledge or reference directories
• deployments that intentionally separate workspaces for safety