Using Docker sbx with Claude Code and Ollama
A practical guide to running secure, local AI development environments with sandboxed isolation — Ollama on your machine, code in a sandbox, without leaving your infrastructure.
· 2 min read
A practical guide to running secure, local AI development environments with sandboxed isolation.
Cloud-based LLM APIs bring cost volatility and data sovereignty risks – proprietary code leaves your control the moment it hits an external endpoint. Also running unattended agents locally introduces its own risks, while overly restrictive permissions create friction that slows development.
The answer is to build a fully offline, local AI development environment where models run on your machine, code executes in a secure sandbox, network policies block unwanted outbound traffic, and Claude Code delivers agentic workflows without leaving your infrastructure.
🚀 Step-by-Step Setup #
Phase 1: Establish Network Policies for Local LLM Access #
Before creating your sandbox, you must grant Claude Code permission to connect to the local Ollama service at localhost and host.docker.internal.
Run these two policy commands first:
sbx policy allow network localhost:11434
sbx policy allow network host.docker.internal:11434These policies ensure that any sandbox you create will be able to communicate with your local Ollama instance at its default HTTP API port.
Phase 2: Create Your Local Claude Sandbox #
Now create a disposable, secure container specifically for Claude Code’s development work.
sbx create claude .This creates an isolated environment for claude code based on your current directory structure. You can list available sandboxes anytime with:
sbx listPhase 3: Execute Claude in Your Sandbox #
The initial execution requires setting up the correct Ollama model environment variables before running Claude Code. Run this complete setup block to configure everything needed for local LLM usage:
sbx exec -it <your-sandbox-name-here> bash -c "
export ANTHROPIC_AUTH_TOKEN=ollama;
export ANTHROPIC_API_KEY='';
export ANTHROPIC_BASE_URL=http://host.docker.internal:11434;
export ANTHROPIC_MODEL=qwen3.5:4b-mlx;
export ANTHROPIC_DEFAULT_OPUS_MODEL=qwen3.5:4b-mlx;
export ANTHROPIC_DEFAULT_SONNET_MODEL=qwen3.5:4b-mlx;
export ANTHROPIC_DEFAULT_HAIKU_MODEL=qwen3.5:4b-mlx;
export CLAUDE_CODE_SUBAGENT_MODEL=qwen3.5:4b-mlx;
export CLAUDE_CODE_EFFORT_LEVEL=medium;
exec claude --allow-dangerously-skip-permissions
"I’m using qwen3.5:4b-mlx for local development as it balances memory restrictions with speed and accurancy. Replace those at will.
And since we are in a sandbox, there’s no need to ask for permissions before running any tool as there are the network and path restrictions in place, so a rogue agent is unable to wreak your system or leak your secrets.
Phase 4: Verify Your Sandbox is Working Properly #
Before doing development work, verify that your sandbox can see your local LLM service. Run this command to inspect Ollama’s available models:
sbx exec <your-sandbox-name-here> curl -s http://host.docker.internal:11434/api/tagsIf you see a JSON response listing available models (like qwen3.5, llama2, etc.), your sandbox is properly configured with network access to Ollama.