openclaw - 💡(How to fix) Fix [Feature]: Granular `tool.fs.workspaceOnly` configuration per tool [1 participants]

Summary

tool.fs.workspaceOnly is currently a single global boolean for filesystem tools.
When set to true, it restricts all fs-related tools (including read operations) to the workspace root. In real-world setups, this is too coarse-grained. We often need:

• strict restrictions for write/edit/patch operations, but
• selective read access outside workspace (e.g. shared/global skill directories).

Problem to solve

With the current all-or-nothing behavior:

• If workspaceOnly = true: safety is good for writes, but valid read use cases break.
• If workspaceOnly = false: reads work, but write/edit protections are weakened. This creates a security-vs-usability tradeoff that should not be necessary.

Proposed solution

Please support per-tool (or per-operation) workspace policy, for example:

• read / read_file
• search
• write / write_file
• edit / apply_patch A possible direction:

{
  "tools": {
    "fs": {
      "workspaceOnly": {
        "default": true,
        "read": false,
        "search": false,
        "write": true,
        "edit": true,
        "apply_patch": true
      }
    }
  }
}

Alternatives considered

• per-tool allow/deny outside workspace
• optional allowlisted external paths for read/search

Impact

This would enable safer practical deployments:

• keep write/edit strictly confined to workspace
• allow controlled read access to shared resources (skills, docs, templates, etc.)
• avoid custom plugin-level workarounds for a common policy need

Evidence/examples

No response

Additional information

Thanks for considering this enhancement.