openclaw - 💡(How to fix) Fix [Feature]: Add “session” or "rw_session" mode to workspaceAccess to allow fine‑grained session‑local write permissions [1 comments, 2 participants]

Summary

I propose to add a new "session" (or "rw_session") value to workspaceAccess to enable read-write access only to session‑specific workspace directories, avoiding the need for complex external proxies while maintaining security.

Problem to solve

The current workspaceAccess options are:

• "none" → no write access at all
• "ro" → read‑only
• "rw" → write access to the entire workspace

For many use cases (e.g. saving session outputs, logs, or scratch files), "rw" is too permissive, while "none"/"ro" are too restrictive.

Workarounds like custom Docker‑socket proxies to enable scoped writing are complex, brittle, and risk breaking compatibility with future OpenClaw versions if Docker API usage or sandboxing changes.

Proposed solution

New value for workspaceAccess:

• "session" (or "rw_session"):
  • Read-write access only to the session‑specific workspace (e.g. /workspace/sessions/<id> or equivalent).
  • Rest of the workspace remains ro or none as configured.

Example openclaw.json:

{
  "agents": {
    "defaults": {
      "sandbox": {
        "mode": "all",
        "workspaceAccess": "session"
      }
    }
  }
}

or per‑channel:

{
  "channels": [
    {
      "id": "telegram",
      "session": {
        "workspaceAccess": "session"
      }
    }
  ]
}

Implementation: map to a bind‑mount like:

/home/node/.openclaw/sandboxes/<session-id>:/workspace:rw

Alternatives considered

Docker‑socket proxy (e.g. socat + custom script) to override mount permissions, but it is:

• Complex: requires additional containers, socket mounts, custom proxy logic
• Brittle: conflicts with gateway timeouts and Docker API changes
• Maintenance burden: breaks on OpenClaw updates, needs constant patching
• Security risk: harder to audit than native workspaceAccess controls

Impact

• Affected users/systems/channels:
  Users that rely on per‑session outputs (logs, scratch files, code generation, model outputs) in channels like Telegram, WhatsApp, or web, when the workspace is set to "none" or "ro".
• Severity:
  Blocks workflow when the agent must write session‑scoped files but cannot due to "none"/"ro", forcing workarounds that are not officially supported and may break.
• Frequency:
  Intermittent but recurring when users switch between "none"/"ro" for security and "rw" for functionality, or when they try to add custom proxy layers without breaking existing channels.
• Consequence:
  • Developers must build and maintain external Docker‑socket proxies (socat, custom scripts, wrappers) to enable writing, which:
    • increase system complexity and maintenance overhead,
    • risk breaking on OpenClaw updates as Docker API usage or sandboxing evolves,
    • reduce security and auditability compared to integrated workspace controls.
  • Without a supported way to allow session‑local writes, users are forced into an all‑or‑nothing choice:
    • "rw" (too broad) or
    • "none"/"ro" (too restrictive),
      which harms both security posture and usability.
• Security / reliability impact:
  • Session‑scoped writing follows least‑privilege and sandbox best practices, improving security.
  • Removes fragile proxy hacks, reducing timeout conflicts, zombie processes, and compatibility risks across OpenClaw versions.

Evidence/examples

Current workspaceAccess documentation shows only "none", "ro", "rw":

• Agent workspace docs
• Sandboxing docs

Related issues:

• #2154 – workspaceAccess permission issues
• #1608 – Docker socket permissions in sandbox
• #29933 – Docker socket mount needed for isolation

Additional information

Implementation could hook into existing sandbox mount logic:

• detect workspaceAccess: "session"
• create session‑scoped bind‑mount /home/node/.openclaw/sandboxes/<id>:/workspace:rw
• enforce write restrictions outside the session scope