Sandbox vs Network Isolation

This page exists because the word sandbox sounds like the answer to every security problem, and in our case it is not.

Our setup is very specific: OpenClaw runs in Docker inside a dedicated Proxmox VM, and the main thing we want to avoid is OpenClaw sitting directly on the VM with normal visibility of the local network. The priority is network isolation of the main service, not tool isolation inside helper containers.

Official reference: OpenClaw sandboxing

The Short Version

We keep OPENCLAW_SANDBOX disabled in this deployment.

The reason is simple: SANDBOX can isolate some tool executions, but it does not isolate the main OpenClaw service from the LAN. The control we actually need is at the network layer, which is why this docs set focuses on Proxmox firewall rules, UFW, and Docker DOCKER-USER filtering.

If the goal is “do not let the main OpenClaw service see or reach the local network,” SANDBOX is the wrong primary control.

Why We Do Not Use It Here

There are three practical reasons.

  1. It does not solve the problem we care about. In this setup, the problem is not “where does a tool run?” The problem is “what can the main OpenClaw service reach on the network?” SANDBOX does not change that.

  2. It pushes us toward mounting docker.sock. To launch sandbox containers, OpenClaw needs access to the Docker daemon. In practice that means exposing /var/run/docker.sock to the container, which gives it a level of control over the host that we explicitly do not want in this profile.

  3. It adds complexity without improving the main isolation boundary. Even if sandboxed tool containers run with no network, the main gateway process still follows the deployment’s normal network path. So we would be adding moving parts while leaving the real risk in the same place.

That is why, for this project, we prefer a simpler rule: keep OpenClaw containerized, keep it away from the LAN with firewall policy, and do not give it Docker daemon access.

What We Use Instead

Instead of relying on SANDBOX, we isolate the deployment itself.

That means:

  1. The Proxmox VM firewall blocks LAN and private-range traffic.
  2. UFW on the VM applies a deny-by-default host policy.
  3. DOCKER-USER prevents Docker networking from bypassing the host policy.

This is the control path that matters for our use case, because it limits what the main OpenClaw service can actually see and reach.

That does not mean we stop using useful tools.

We can still use things like fetch_webpage when the job is to read external documentation or pull in a specific page as context. We can also use subagents for long or parallel tasks when they make sense. Those features help with workflow and research. They are not the thing that isolates the main OpenClaw service from the LAN.

OpenClaw’s subagent docs are here: Subagents.

For the full implementation, see the secure deployment guide.

When I Would Revisit SANDBOX

I would reconsider SANDBOX if this deployment starts to allow things like model-driven code execution, file modification, or workflows that process untrusted artifacts.

In that scenario, SANDBOX can still be useful as an extra layer around tool execution. Even then, I would treat it as a complement to the network isolation layers above, not as a replacement for them.