openclaw - 💡(How to fix) Fix [Feature]: Allow writable custom binds with workspaceAccess: "none" for least-privilege sandbox access [1 participants]

Summary

Allow sandboxed agents to edit explicitly writable custom bind mounts while workspaceAccess remains "none".

Problem to solve

I want to keep the main agent workspace isolated so the sandbox cannot write broadly to the real workspace, but I still need the agent to modify a small, explicit subset of real files.

My target model is:

• workspaceAccess: "none" so /workspace remains the isolated sandbox working area
• explicit docker.binds for only the files/directories the agent actually needs
• writable binds for selected persona/bootstrap/project/memory files
• read-only binds for sensitive or historical data such as session logs/history

Today this is blocked in practice for two reasons:

1. In the current implementation, normal file tools appear to require workspaceAccess: "rw" for writes, even if the resolved target is on a writable custom bind.
2. The overall bind behavior is difficult to use for least-privilege access to real files, especially when those files live under the normal OpenClaw state tree.

That forces an undesirable choice:

• either use workspaceAccess: "rw" and grant broad write access to the real workspace
• or use workspaceAccess: "none" and lose the ability to modify the specific real files the agent actually needs through normal file tooling

Proposed solution

Support a least-privilege sandbox mode where:

• workspaceAccess: "none" keeps /workspace isolated and disposable
• custom binds remain the source of truth for explicitly exposed real files/directories
• if a custom bind is mounted :rw, normal file tools (write, edit, apply_patch, etc.) can modify files on that bind
• if a custom bind is mounted :ro, file tools can read it but cannot modify it
• writes outside writable binds remain blocked
• /workspace remains read-only or sandbox-local according to existing workspaceAccess: "none" semantics
• no reserved-target override is needed as long as custom binds target neutral paths such as /persona, /projects, /memory, /history

Example desired config shape:

{
  agents: {
    defaults: {
      sandbox: {
        mode: "all",
        scope: "session",
        workspaceAccess: "none",
        docker: {
          dangerouslyAllowExternalBindSources: true,
          binds: [
            "/home/user/.openclaw/workspace/AGENTS.md:/persona/AGENTS.md:rw",
            "/home/user/.openclaw/workspace/SOUL.md:/persona/SOUL.md:rw",
            "/home/user/.openclaw/workspace/HEARTBEAT.md:/persona/HEARTBEAT.md:rw",
            "/home/user/.openclaw/workspace/projects:/projects:rw",
            "/home/user/.openclaw/workspace/memory:/memory:rw",
            "/home/user/.openclaw/agents/main/sessions:/history/sessions:ro"
          ]
        }
      }
    }
  }
}

Desired behavior:

• the agent can modify /persona/, /projects/, and /memory/*
• the agent can read but not modify /history/sessions/*
• the agent cannot broadly write to the real workspace
• the main sandbox working directory stays isolated

Alternatives considered

Alternatives considered

• workspaceAccess: "rw"
  • Works functionally, but grants much broader write access than desired.
• workspaceAccess: "none" with exec-only writes through shell commands
  • Reduces friction in some cases, but does not solve the core least-privilege sandboxing need.

Impact

Affected: operators using Docker sandboxes who want real-file access without broad real-workspace write permissions Severity: High for hardened/self-hosted deployments Frequency: Always when trying to combine isolation with selective persistence Consequence: Either overexpose the real workspace with rw, or accept a sandbox that cannot edit the specific persistent files it needs

Evidence/examples

Related docs and issues suggest this is adjacent to existing user needs:

• Sandbox docs describe docker.binds as a way to mount additional host paths: docs.openclaw.ai/gateway/sandboxing (https://docs.openclaw.ai/gateway/sandboxing)
• Related issue about binds outside allowed roots / per-session directories: #57271 (https://github.com/openclaw/openclaw/issues/57271)
• Related issue about sandbox write behavior / permissions: #59613 (https://github.com/openclaw/openclaw/issues/59613)
• Related issue about sandbox file access with host absolute workspace paths: #57230 (https://github.com/openclaw/openclaw/issues/57230)

A likely implementation path would be to make file-tool write authorization depend on the resolved target mount’s writability, not only on workspaceAccess === "rw".

Additional information

This request is specifically about a safer least-privilege model:

• keep the default working area isolated
• expose only explicitly approved real files
• preserve RO/RW semantics per bind
• avoid forcing broad writes to the canonical workspace just to let the agent update a few persistent files