Running OpenClaw on bare metal is risky. Learn how to wrap your agent in a Docker container to prevent accidental file system destruction.
Why an Agent Needs a Sandbox
OpenClaw runs with the same permissions as the process that launches it. When you give an autonomous agent a shell, file access, and a mandate to act on your behalf, a single misread instruction can translate into deleted directories, overwritten configuration, or unintended writes across your home folder. On bare metal, there is nothing between the agent's mistakes and your real data.
A Docker container gives you a clean boundary. The agent operates inside a filesystem you define, sees only the resources you hand it, and cannot reach the rest of your machine unless you explicitly connect it. If something goes wrong, you throw the container away and start again instead of restoring from backups.
Building the Container
Start from a minimal base image and install only what OpenClaw needs to run. A smaller image means a smaller attack surface and fewer tools the agent could misuse. Copy the agent in, set a dedicated non-root user, and make that user the default so the process never runs with elevated privileges inside the container.
Keep the image itself immutable. Anything the agent generates during a run should land in a mounted working directory, not in the image layers. That separation lets you rebuild the environment from the Dockerfile at any time and keeps your build reproducible.
Constraining What the Agent Can Touch
The container is only as safe as its configuration. The goal is to grant the agent exactly the access it needs for a task and nothing more. Mount a single project directory as its workspace rather than exposing large parts of your host, and treat every additional capability as something you justify before adding.
- Scoped mounts: Bind only the specific working directory the agent should edit, and mount reference material read-only so it cannot alter your source of truth.
- Non-root user: Run the agent as an unprivileged user so a runaway command inside the container still cannot escalate.
- Resource limits: Cap memory and CPU so a stuck loop cannot starve the host.
- Network control: Disable networking entirely for offline tasks, or allow only the endpoints the agent genuinely needs.
Each of these is a dial. Tighten them for untrusted or exploratory runs, and loosen them deliberately when a task requires more.
Working With the Sandbox Day to Day
The point of containerizing OpenClaw is not to run it once and forget it, but to make risky work routine. Treat containers as disposable: spin one up for a task, let the agent do its work in the mounted directory, review the changes on your host, and discard the container afterward. Because the important output lives in your bind mount, tearing down the container costs you nothing.
This workflow also makes failures cheap to reproduce. If the agent corrupts its own workspace, you reset to a known state instead of untangling damage on your real system. The container becomes a place where mistakes are expected and contained, which is exactly what you want when you hand meaningful autonomy to a tool that acts before you can review every step.