Type: Feature Request
Category: feature-request
Severity: Critical

Problem Statement

OpenClaw's core architecture includes partial security mechanisms (network binding, Token/password auth, Scope authorization, tool policy allowlists, path sandbox), but these are fragmented, inconsistently applied, and not enforced in the plugin/skill subsystem. All 31+ plugins share a single Node.js process with no process isolation, no memory isolation, and no filesystem isolation. A vulnerability in any single plugin compromises the entire system — including all credentials, data stores, and 250+ SDK APIs. The existing sandbox design (e.g., clawd/sandbox.js path restrictions) has known bypass vulnerabilities (ECO-009). Most critically, there are no user-friendly default presets — requiring users to manually configure security, which most users (especially non-technical ones) never do.

This issue consolidates all sandbox and isolation deficiencies across the ecosystem:

• Former CSD-001 (No Plugin Sandbox Isolation)
• Former CSD-002 (Cross-Plugin Credential Exposure via Shared process.env)
• ECO-004 (Plugin Lateral Movement via Shared Process Model)
• ECO-005 (Credential Exposure via Shared Environment)
• ECO-009 (Sandbox Path Traversal — existing sandbox bypass)
• ECO-014 (Cross-Plugin Credential Leak)
• ECO-040 (Coding Agent Resource Exhaustion)
• ECO-045 (Agent Resource Exhaustion Loops)
• ECO-050 (Unrestricted Tool Execution)

Current State

Architectural Root Cause

OpenClaw loads all 31+ plugins via the jiti (Just-In-Time TypeScript) dynamic loader into a single Node.js process. Every plugin has unrestricted access to:

• process.env — all 25+ service credentials (Slack, Telegram, OpenAI, Discord, Nostr, blockchain private keys, WeChat AES keys, etc.)
• Full filesystem — no mount isolation
• All network connections — no outbound filtering
• 250+ SDK APIs — no per-plugin capability restrictions
• All other plugins' memory space — no V8 Isolate boundaries

Existing Partial Sandbox

The clawd/sandbox.js implements basic path restrictions for the sandbox:// URL scheme, but:

• Path traversal bypass exists (ECO-009, CVSS 9.3)
• No process-level isolation
• No credential scoping
• No network restrictions
• Not applied to plugins or skills
• Linux-only — no macOS or Windows equivalent

User Impact

Non-technical users ("beginners") have no way to configure sandbox policies. There are no preset security levels, no guided setup, and no defaults that provide meaningful protection. The result is that security is effectively opt-in and zero users opt in.

Impact Analysis

• Affected Components: All 31+ extensions, all bundled skills, all community plugins, all ClawHub skills (4,525+)
• Attack Surface: Any plugin vulnerability becomes system-wide. Cross-plugin lateral movement is trivial (ECO-004). Single credential read grants access to all 25+ integrated services (ECO-005, ECO-014).
• CVSS Impact: Addresses 9 ECO vulnerabilities with CVSS scores ranging 7.0-9.8, plus the CSD-001/002 architectural defect chain
• Related Issues: CSD-003, CSD-004, CSD-005, CSD-006, CSD-008, ECO-004, ECO-005, ECO-009, ECO-014, ECO-040, ECO-045, ECO-050

Proposed Solution

Design Principles

1. Secure by Default: New installations ship with a reasonable sandbox preset enabled — users must opt DOWN, not opt UP
2. Multi-Platform: Abstract sandbox primitives behind a unified configuration layer; map to platform-native isolation mechanisms
3. Tiered Presets: 3-4 named security levels that non-technical users can select with a single setting
4. Progressive Enforcement: Start with the lightest viable isolation, allow upgrading without architecture changes

Multi-Platform Sandbox Architecture

Abstraction Layer

A unified SandboxManager that exposes platform-agnostic capabilities:

Platform-Native Implementations

IPC Communication Model

Sandboxed plugins communicate with the host via a standardized IPC channel:

• Transport: Unix domain socket (Linux/macOS) or Named Pipe (Windows), with stdio JSON-RPC as universal fallback
• Protocol: JSON-RPC 2.0 over the transport
• SDK Proxy: The host process provides a proxy SDK that marshals API calls across the IPC boundary. Plugins see the same SDK interface; the proxy enforces capability checks before forwarding.

Tiered Preset System

Default: standard — provides meaningful protection without breaking most plugins. Users select their level via:

# ~/.config/openclaw/config.yaml
security:
  sandbox_level: standard  # minimal | standard | strict | paranoid

Plugin Capability Manifest

Each plugin declares its requirements in manifest.yaml:

name: my-plugin
sandbox:
  env:
    require: [OPENAI_API_KEY, MY_PLUGIN_TOKEN]
  fs:
    read: ["./data/**", "/tmp/openclaw/**"]
    write: ["./output/**"]
  net:
    allow: ["api.openai.com:443", "discord.com:443"]
  tools:
    allow: [read, write, message_send]
    deny: [exec, shell]
  commands:
    register: ["/mycommand"]
  http:
    routes: ["/api/myplugin/*"]
    auth: required  # required | optional | none
  resources:
    max_memory: 256MB
    max_cpu_time: 30s

Plugins without a manifest run under the preset's default restrictions. Plugins requesting capabilities beyond the active preset level are either blocked or require explicit user approval.

Implementation Phases

Migration Strategy

1. Ship Phase 1 with minimal as default (backward compatible)
2. After Phase 2+3, switch default to standard
3. Existing plugins auto-generate manifest from observed behavior during a "learning" period
4. Grace period: plugins without manifest run with warnings, then restricted after N releases

Related Issues

Merged into this issue: Former CSD-001 (No Plugin Sandbox), Former CSD-002 (Cross-Plugin Credential Exposure)

Directly addressed ECOs: ECO-004, ECO-005, ECO-009, ECO-014, ECO-040, ECO-045, ECO-050

Architectural dependencies: CSD-003 (code signing works with manifest), CSD-004 (hook integrity benefits from process isolation), CSD-005 (command namespace isolation via manifest), CSD-006 (HTTP auth enforcement via manifest), CSD-008 (instruction isolation via sandbox context separation)