How I Built a Jail for My OpenClaw Agent and Run It for Free

Two problems with OpenClaw and how I fixed both in one weekend.

If you have been following AI in 2026, you already know OpenClaw. It crossed 350k stars on GitHub, people call it “Claude with hands,” and it genuinely lives up to the hype. You message it on WhatsApp or iMessage, it runs shell commands, controls your browser, reads and writes files. Real tasks. Real results.

But here is what nobody tells you when you install it. OpenClaw runs directly on your machine with shell access and full file write permissions. The agent can read, write, and delete your actual files. One misunderstood instruction and it is quietly “cleaning up” a folder you have spent years building. And every request you send routes through a cloud API, which adds up fast when you are running automation tasks regularly.

I was using it to automate my content workflow and I was nervous every time I ran it. So I fixed both problems. Here is the exact setup I built to sandbox OpenClaw properly and run it completely free.

Step 1: Put It in a Jail (Docker Container)

Create walls around it.

I stopped running OpenClaw natively on my Mac and moved it into a Docker container. The agent still thinks it has a full system. It does not. Everything it can reach is walled off from my actual machine.

I did not write the Docker configuration myself. I just dropped this prompt into Antigravity, my IDE agent:

“Create a Dockerized jail for OpenClaw. Mount my ./projects directory as READ-ONLY. Connect it to Ollama at host.docker.internal:11434 running minimax-m2:cloud. Include a one-way sync script.”

A few minutes later I had a working docker-compose.yml and sync script. Done.

Step 2: Give It Context, Not Control (Read-Only Mirror)

The agent can see everything but cannot change it.

The agent needs context to be useful. My sync script copies my active project folders into the container before each session so OpenClaw can read my code, my writing history, five years of context. But those volumes are mounted with the :ro flag in docker-compose. Read only. The agent can see everything and change nothing.

If it hallucinates and tries to overwrite a file, it hits Permission Denied at the filesystem level. No prompt, no malicious skill, nothing can override a filesystem permission. That is not a policy. That is a hard wall.

Step 3: Run It for Free (Minimax M2 via Ollama)

Instead of burning cloud API credits, I wired the jail to Minimax M2 running locally through Ollama. The model runs on my machine, every request stays local, and there is no bill, though there is a limit to it. Here is the config block that makes it work inside the container:

json

{
  "models": {
    "providers": {
      "ollama": {
        "baseUrl": "http://host.docker.internal:11434/v1",
        "apiKey": "ollama",
        "api": "openai-completions",
        "models": [{"id": "minimax-m2:cloud", "name": "minimax-m2:cloud"}]
      }
    }
  },
  "agents": {
    "defaults": {
      "workspace": "/app/workspace",
      "model": {"primary": "ollama/minimax-m2:cloud"}
    }
  }
}

The host.docker.internal hostname lets the container reach your host machine’s Ollama instance even though the container itself is fully isolated. Pull the model once with ollama pull minimax-m2:cloud and every request after that is free.

Two months in: privacy leaks zero, accidental deletions zero, API cost zero. Build the box first. Then put the agent in it.

Now I have a specialized agent that knows everything about my previous code but gets Permission Denied if it tries to break anything. And since it uses Minimax M2 via Ollama, my API bill is zero (again, limited use).

Hope this helps someone else sleep better while their agents run!