Exploring the Ollama Docker Sandbox Setup
AI coding agents are great right up until you stop and think about what they can actually reach. OpenCode, Claude Code, Codex, the whole crop of them, they all want a filesystem, a shell, and a network connection so they can do real work. On your laptop that means the same agent that just refactored a function can also read your SSH keys, your cloud credentials, and every other repo you have checked out. And if it talks to a hosted model, your source code leaves the machine on every single prompt.
There is a version of this that gives up neither the convenience nor the control. Run the agent inside a Docker Sandbox so it lives in an isolated microVM with nothing but your project folder mounted, and point it at Ollama running locally so the model never touches the internet. The opencode-ollama-sbx-template repo from Coding for Entrepreneurs is a tidy, minimal example of exactly this. It is worth walking through slowly, because the moving parts teach you a lot more than the line count would suggest.
The shape of the idea
Two processes, two trust zones.
The agent (OpenCode) runs inside a Docker Sandbox. That is a hard VM boundary, not a container namespace trick. It sees the directory you hand it and not much else.
The model (Ollama with qwen2.5-coder:7b) runs on your host, outside the sandbox. Inference happens on your own GPU or CPU, and not a single token goes to a cloud endpoint.
The clever bit is the wire between them. The sandboxed agent reaches back out to the host’s Ollama through host.docker.internal, which is the DNS name that resolves to your machine from inside the sandbox. So the agent is boxed in, the model is local, and the only traffic crossing the boundary is the prompt and the completion.
What you need
A working Docker setup with Sandboxes available, Ollama installed on the host, and that is basically it. On Mac and Windows the command is docker sandbox; on Linux and CI it is sbx. Same binary, different entry point, so do not get thrown when you see both spellings floating around.
Step 1: pull the model on the host
Before anything else, get the model onto your machine so Ollama can serve it:
ollama pull qwen2.5-coder:7b
This is a coding-tuned model with tool calling, which matters because OpenCode leans on tool calls to read files, run commands, and edit code. A 7B model is small enough to run comfortably on most modern laptops and still hold its own for everyday coding tasks.
Step 2: the Dockerfile
The template builds on top of Docker’s official OpenCode sandbox image, so you are not assembling the agent from scratch. You are just layering your config on top:
FROM docker.io/docker/sandbox-templates:opencode-docker
USER root
RUN mkdir -p /opt/opencode-ollama
COPY opencode.json /opt/opencode-ollama/opencode.json
RUN chown -R agent:agent /opt/opencode-ollama
ENV OPENCODE_CONFIG=/opt/opencode-ollama/opencode.json
USER agent
Nothing exotic happening here. It creates a directory, drops in a config file, hands ownership to the agent user that the base image already sets up, and points the OPENCODE_CONFIG environment variable at that file. The switch back to USER agent at the end means the agent does not run as root inside the box, which is exactly what you want.
Step 3: the bridge
This opencode.json is where the whole thing comes together. It tells OpenCode to treat your local Ollama as an OpenAI-compatible provider:
{
"$schema": "https://opencode.ai/config.json",
"provider": {
"ollama": {
"npm": "@ai-sdk/openai-compatible",
"name": "Ollama (host)",
"options": {
"baseURL": "http://host.docker.internal:11434/v1",
"apiKey": "ollama"
},
"models": {
"qwen2.5-coder:7b": {
"name": "Qwen 2.5 Coder 7B",
"tool_call": true,
"limit": {
"context": 32768,
"output": 8192
}
}
}
}
},
"model": "ollama/qwen2.5-coder:7b",
"small_model": "ollama/qwen2.5-coder:7b"
}
A few things worth pointing out. The baseURL is the line doing the heavy lifting: host.docker.internal:11434 is how the sandboxed agent finds Ollama back on the host, and /v1 is Ollama’s OpenAI-compatible API surface. The apiKey is a throwaway string because local Ollama does not check it, but the OpenAI-compatible client still expects the field to exist. And tool_call: true is what lets OpenCode actually drive the model as an agent rather than just chat with it.
Step 4: build and package
Build the image, then save it to a tarball so the sandbox runtime can ingest it:
docker build -t opencode-ollama-sbx:v1 .
docker image save opencode-ollama-sbx:v1 -o opencode-ollama-sbx.tar
Step 5: load it as a sandbox template
sbx template load opencode-ollama-sbx.tar
echo "*.tar" >> .gitignore
Starting sandboxd daemon...
Daemon started (PID: 9810, socket: /Users/ajeetraina/Library/Application Support/com.docker.sandboxes/sandboxes/sandboxd/sandboxd.sock)
Logs: /Users/ajeetraina/Library/Application Support/com.docker.sandboxes/sandboxes/sandboxd/daemon.log
Loading image from opencode-ollama-sbx.tar ...
Load complete.
╭──────────────────────────────────────────────────────────────────────────────────╮
│ Docker Sandboxes Update Available │
├──────────────────────────────────────────────────────────────────────────────────┤
│ v0.28.3 → v0.31.1 │
├──────────────────────────────────────────────────────────────────────────────────┤
│ Release notes https://github.com/docker/sbx-releases/releases/tag/v0.31.1 │
├──────────────────────────────────────────────────────────────────────────────────┤
│ To upgrade brew upgrade docker/tap/sbx │
╰──────────────────────────────────────────────────────────────────────────────────╯
ajeetraina@Ajeets-MacBook-Pro opencode-ollama-sbx-template % The .gitignore line is a small but smart touch. That tarball can run to gigabytes, and you do not want it accidentally committed. Add the ignore rule once and forget about it.
Step 6: verify, then run
Quick sanity check from the host to confirm Ollama is up and the model is actually sitting there:
curl "http://0.0.0.0:11434/api/tags"
If you see qwen2.5-coder:7b in the response, you are good. Now launch the agent inside the sandbox, pointed at your current directory:
sbx run --template opencode-ollama-sbx:v1 opencode .
...
Creating new sandbox 'opencode-opencode-ollama-sbx-template'...
INFO: Configuring Docker
OpenCode comes up inside the microVM, talks back to your local Ollama for every completion, and operates on the folder you handed it and nothing more.
Why this combination is worth your attention
It is easy to read this as a neat trick and move on, but the trust model underneath is the real story.
Most of the time when people talk about “running an agent safely” they pick one lever. Either they sandbox the agent and still send code to a cloud model, or they run the model locally and let the agent roam free on the host. This template pulls both levers at once. The agent cannot wander into your home directory because it is in a VM. Your code cannot leak to a third party because the model is on your own hardware. You give up neither.
That is the same principle behind a lot of the Sandboxes work: deny by default, mount only what the task needs, and keep the blast radius small. A local model just extends that thinking from the filesystem out to the network. Nothing privileged leaves the box, and nothing sensitive leaves the machine.
It also scales as a pattern. Swap qwen2.5-coder:7b for a bigger model if you have the hardware. Add a second provider block if you want a cloud fallback for the heavy lifting and keep the local model for the routine stuff. The template is small on purpose, which makes it a good base to build your own opinionated setup on top of.
Wrapping up
A few files, a couple of commands, and you have an AI coding agent that runs isolated and thinks locally. Credit to Coding for Entrepreneurs for the clean template. Clone it, pull a model, build the image, and try it on a real project. The best way to understand where the boundaries sit is to run it and watch what the agent can and cannot reach.
