Using Docker sbx with Claude Code and Ollama

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:11434

These 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 list

Phase 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
"

I’m using qwen3.5:4b-mlx for local development as it balances memory restrictions with speed and accurancy. Replace those at will.

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/tags

If you see a JSON response listing available models (like qwen3.5, llama2, etc.), your sandbox is properly configured with network access to Ollama.

Final things to consider

The sandbox is read-only everywhere except your project folder. So if you’re using a tool like Go that tries to write to system paths (e.g., ~/.cache/go-build), it’ll fail – because that directory doesn’t allow writes.

The fix is simple: tell your tools to use your workspace instead. Set environment variables like GOCACHE=./.go-cache or use the universal HOME=/workspace trick. This way, everything writes to your project folder, and you never hit permission issues again.