Skip to content

sandbox: keep workspaceAccess none workspaces writable #37634

@whyuds

Description

@whyuds

Summary

When agents.defaults.sandbox.workspaceAccess is set to "none", OpenClaw gives each sandboxed session its own isolated workspace under ~/.openclaw/sandboxes/..., which matches the expected isolation model. However, that isolated /workspace ends up mounted read-only, so tools that need to write inside the sandbox workspace stop working.

This makes "none" behave closer to "ro" in practice, even though the agent workspace is still intentionally hidden.

Expected behavior

workspaceAccess: "none" should mean:

  • the main agent workspace is not mounted into the sandbox
  • each sandboxed session gets an isolated workspace under ~/.openclaw/sandboxes/...
  • that isolated sandbox workspace is writable

Actual behavior

Inside the sandbox, /workspace is mounted from the per-session sandbox workspace, but it is read-only:

/workspace <- /home/whyuds/.openclaw/sandboxes/agent-main-feishu-direct-ou_83bb-2d8ddca6 (rw=false)

As a result, many tools that rely on writing into the sandbox workspace cannot be used when workspaceAccess is "none".

Why this seems like a regression

This appears related to commit 903e4dff3 (fix(sandbox): make /workspace bind mount read-only when workspaceAccess is not rw).

That change made /workspace read-only for both "ro" and "none":

  • rw: /workspace writable
  • ro: /workspace read-only
  • none: /workspace read-only

But for "none", /workspace points at the isolated sandbox workspace rather than the main agent workspace, so making it read-only breaks the expected isolated-but-writable workflow.

Reproduction

  1. Configure sandboxing so the session is sandboxed and workspaceAccess is "none"
  2. Start a sandboxed session
  3. Inspect the sandbox mounts or try any tool that writes to /workspace
  4. Observe that /workspace is backed by ~/.openclaw/sandboxes/... but is read-only

Suggested direction

Keep workspaceAccess: "none" isolated from the main agent workspace, but make the isolated sandbox /workspace writable. Only workspaceAccess: "ro" should force /workspace read-only.

Related fix PR: #37276

Metadata

Metadata

Assignees

No one assigned

    Labels

    P1High-priority user-facing bug, regression, or broken workflow.clawsweeper:fix-shape-clearClawSweeper found a clear likely implementation shape for this issue.clawsweeper:needs-maintainer-reviewClawSweeper marked this issue as needing maintainer review before automation.clawsweeper:needs-product-decisionClawSweeper marked this issue as needing a product or behavior decision.clawsweeper:needs-security-reviewClawSweeper marked this issue as needing security-sensitive review.clawsweeper:no-new-fix-prClawSweeper does not recommend queueing a new automated fix PR for this issue.clawsweeper:source-reproClawSweeper found a high-confidence source-level issue reproduction.impact:securitySecurity boundary, credential, authz, sandbox, or sensitive-data risk.impact:session-stateSession, memory, transcript, context, or agent state can drift or corrupt.issue-rating: 🦞 diamond lobsterVery strong issue quality with high-confidence source-level or clear reproduction.

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions