Run Code in Sandbox

The sandbox executor runs arbitrary code inside isolated containers (Docker or Podman) so agents can compute results, run tests, and execute scripts without risking the host system.

Configuring the sandbox

1. Open the Sandbox page from the Infrastructure section of the sidebar

2. Select the sandbox mode:

   • OFF — No sandboxing; code runs directly on the host (not recommended)
   • SELECTIVE — Only sandbox high-risk operations (bash with network access, untrusted scripts)
   • ALL — Every code execution goes through the container sandbox

3. Choose the scope mode:

   • SESSION — One container per conversation session, reset between sessions
   • AGENT — One container per agent, persists across sessions
   • SHARED — All agents share a single container (for collaboration workflows)

4. Set workspace access level:

   • NONE — Container has no access to agent workspace
   • RO — Container can read workspace files but not write
   • RW — Container can read and write workspace files

5. Save your settings

Expand

Resource limits

Each sandbox instance has configurable resource limits. On the Sandbox page, you can set the following per-instance limits:

Setting	Description
CPU Cores	Number of CPU cores allocated to the container
Memory (MB)	Maximum memory in megabytes
Disk (MB)	Maximum disk space in megabytes
Max Processes	Maximum number of concurrent processes
Timeout (seconds)	Maximum execution time before the container is killed

How agents use the sandbox

You don’t need to explicitly invoke the sandbox — it’s transparent. When an agent executes bash or runs a script, the sandbox mode determines whether it’s containerized:

For instance, if you ask the agent to write a Python script that processes a CSV file and plots the results, the agent runs the code in the sandbox automatically, generates the plot, and returns the image in the chat.

Expand

The Logs tab tracks every sandboxed command with exit codes, duration, and security scores.

For explicit control, you can direct the agent:

Example prompt: “Run this in an isolated container and give me the output”

Example prompt: “Execute the test suite in a fresh Python 3.12 environment”

Example prompt: “Run this JavaScript snippet in Node.js 20”

Supported runtimes

The sandbox supports any runtime available in the container image:

• Python 3.10, 3.11, 3.12 (default: 3.12)
• Node.js 18, 20, 22 (default: 20)
• Bash / Shell
• Go, Rust, Ruby (via custom images)

Specify a runtime:

Example prompt: “Run this in Python 3.10”

Example prompt: “Execute with Node 22”

Network policy

Container network access is controlled per permission tier:

• Sandbox / Restricted: No outbound network access
• Standard: Can reach a configurable allowlist of domains
• Elevated / Unrestricted: Full outbound access

On the Sandbox page, configure network policy settings including Network Enabled, Allowed Domains, and Blocked Domains.

Persistent workspace

With scope mode AGENT or SESSION, the container’s workspace directory persists between executions:

For example, if the first execution installs a package with pip install pandas, the second execution can immediately import pandas without reinstalling — the dependency persists within the container.

This makes multi-step data pipelines efficient — install dependencies once, reuse them.

Requirements

• Docker ≥ 24 or Podman ≥ 4.x installed and running on the host
• The Snippbot daemon process needs socket access (/var/run/docker.sock)

To check if Docker is available, open Monitor in the sidebar. The system health panel shows Docker availability status along with other subsystem checks.

Note

The sandbox does not require root privileges. Snippbot uses rootless containers by default.

Sandbox vs. direct execution

	Direct execution	Sandbox
Speed	Fast	Adds ~200ms startup
Isolation	None (host system)	Full container isolation
Risk	Host can be modified	Contained
Persistence	Persistent	Configurable via scope
Network	Full	Configurable

Use direct execution (SELECTIVE or OFF) for:

• Read-only file operations
• Fast, trusted scripts
• Development environments where the agent is well-tested

Use ALL sandbox for:

• Running untrusted or generated code
• Data processing with external inputs
• Production environments

Troubleshooting

Docker not found

If the system health panel in Monitor shows Docker as unavailable, install Docker from docker.com/get-started (or via Homebrew on macOS).

Permission denied on docker.sock

Add your user to the docker group on Linux, then log out and back in. On macOS with Docker Desktop, ensure Docker Desktop is running.

Container out of memory

Increase memory limits on the Sandbox page by adjusting the Memory (MB) setting.