Run Sandboxed for Unknown Skills

First time in sandbox mode, everything breaks. The skill can't read files, can't write, can't run commands. Annoying? Yes. Exactly how it should work.

Friction Is a Feature

When you install a skill from ClawHub, you're trusting code you didn't write to run on your machine. The sandbox grants nothing by default. Every capability becomes a deliberate choice.

What the Sandbox Does

OpenClaw uses Docker to create isolated execution. When sandboxed:

• Filesystem isolation — only sees directories you explicitly mount
• Process isolation — commands run inside the container, not your host
• Network controls — restrict or block network access
• Resource limits — CPU and memory capped

A malicious skill inside a sandbox can thrash all it wants. It can't touch your SSH keys, browser history, or anything you didn't share.

When to Use It

• New skills from ClawHub — trial period before full access
• Unknown authors — no track record? Sandbox it
• Broad capability claims — "manages files, sends emails, handles finances"? Let's see what it does in an empty temp directory
• Anything that feels off — trust your instincts

How to Configure It

In openclaw.json:

{
  "sandbox": {
    "enabled": true,
    "image": "openclaw/sandbox:latest",
    "mounts": [
      "~/workspace:/workspace:rw",
      "~/Downloads:/downloads:ro"
    ],
    "network": "bridge"
  }
}

Use :ro for read-only, :rw for read-write. Start restrictive, add access as needed — not the other way around.

The Trade-offs

• Setup time — Docker needs to be running
• Slower startup — container init adds latency
• Permission config — explicit directory mapping required
• Some skills won't work — deep system access can't be sandboxed

Real trade-offs. But the alternative is running unknown code with full access because it's convenient. That's how breaches happen.

Run unknown skills sandboxed. Watch what they try to access. Promote to native only when confident. It's not paranoia — it's hygiene.