
LLM Sandbox
io.github.vndeePublished by GitHub account vndeev0.3.43Updated Oct 26, 2026
Securely run LLM-generated code in isolated containers across 7 languages and 3 container backends.
Overview
Runs LLM-generated code in isolated containers or local OS sandboxes across several languages, with captured plots and file transfer.
- What you can do
- Execute code in a sandboxed backend (Docker, Podman, Kubernetes, or local Linux/Windows sandboxes) and get stdout, stderr and exit status
- List supported programming languages and fetch details about a specific language
- Install libraries on the fly and capture generated plots and visualizations as artifacts
- Copy files into and out of the sandbox environment
- When to use it
- Useful when an assistant needs to actually run code it writes — data analysis, plotting, quick scripts — without executing it directly on the host. Suits developers and agent builders who want a hardened execution boundary with configurable resource and network limits.
- Requirements
- Local Python package installed with a backend extra (mcp-docker, mcp-podman or mcp-k8s) and launched over stdio. A reachable container runtime or Kubernetes cluster, or local Linux/Windows sandbox prerequisites such as bubblewrap and seccomp. Environment variables select the backend: BACKEND, DOCKER_HOST, KUBECONFIG, NAMESPACE, plus optional SANDBOX_* limits.
Installation
In SourceWeft
- Open LLM Sandbox in the dashboard and add it to a workspace.
- Enable the server for the chats that should use its tools.
Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.
Other MCP clients
Follow the launch instructions in the repository.
README
LLM Sandbox
Securely Execute LLM-Generated Code with Ease
[Quality Gate Status] [PyPI Downloads] [Release] [Build status] [CodeFactor] [codecov] [Image] [DOI]
LLM Sandbox runs Large Language Model (LLM) generated code through a common API for container and local Linux and Windows sandbox backends. Choose an isolation backend for your deployment, configure its security controls, and reuse the same code execution and file APIs.
Documentation: https://vndee.github.io/llm-sandbox/
Backend benchmarks compare Docker, Bubblewrap and NsJail across startup, execution, file transfers and concurrency, with confidence intervals and reproducible evidence.
✨ New: This project now supports the Model Context Protocol (MCP) server, which allows your MCP clients (e.g. Claude Desktop) to run code generated by LLMs in a secure sandbox environment.
🚀 Key Features
🛡️ Security First
- Isolated Execution: Container or local OS sandboxing with explicitly configured host access
- Security Policies: Define custom security policies to control code execution
- Resource Limits: Set CPU, memory, and execution time limits
- Network Isolation: Control network access for sandboxed code
🏗️ Flexible Sandbox Backends
- Docker: Most popular and widely supported option
- Kubernetes: Enterprise-grade orchestration for scalable deployments
- Podman: Rootless containers for enhanced security
- Bubblewrap: Local Linux namespaces and seccomp without Docker or a daemon
- NsJail: Local Linux namespaces and native seccomp policies without a daemon
- Windows MXC: Native Windows process isolation through Microsoft's MXC/PSEC APIs
- WSL2 Bubblewrap: Linux namespaces and seccomp in an explicitly selected WSL2 distribution
- Backend Registry: Register additional adapters and inspect their supported features
🌐 Multi-Language Support
Execute code in multiple programming languages with automatic dependency management:
- Python - Full ecosystem support with pip packages
- JavaScript/Node.js - npm package installation
- Java - Maven and Gradle dependency management
- C++ - Compilation and execution
- Go - Module support and compilation
- R - Statistical computing and data analysis with CRAN packages
🔌 LLM Framework Integration
Runnable examples for eleven agent frameworks — OpenAI Agents SDK, Claude Agent SDK, LangChain, DeepAgents, LlamaIndex, Google ADK, CrewAI, Pydantic AI, smolagents, Strands and AG2. See examples/agent_sdks/.
📊 Advanced Features
- Artifact Extraction: Automatically capture plots and visualizations
- Library Management: Install dependencies on-the-fly
- File Operations: Copy files to/from sandbox environments
- Custom Images: Use your own container images
- Fast Production Mode: Skip environment setup for faster container startup
- Container Pooling: Pre-warm and reuse containers for improved performance (NEW!)
📦 Installation
Basic Installation
With Specific Backend Support
Bubblewrap and NsJail use the base Python package plus system executables; no container SDK extra is needed. See local backend requirements for Linux prerequisites.
The Windows adapters also need no container SDK. windows-mxc requires a compatible Windows host and the native helper, while wsl2-bubblewrap requires a configured WSL2 distribution with the matching Python package and Linux prerequisites. See Windows requirements; neither adapter installs an OS runtime or falls back to unsandboxed execution.
Development Installation
Dev dependencies live in the dev uv dependency group, so install them with uv (or the make install shortcut):
See CONTRIBUTING.md for the full workflow.
🏃♂️ Quick Start
Basic Usage
Local Linux Usage Without Docker
On Debian/Ubuntu, install the system prerequisites with sudo apt install bubblewrap libseccomp2 python3-venv. Bubblewrap must be version 0.8.0 or newer with --disable-userns support; older distributions such as Ubuntu 22.04 need a newer package or upstream build. Your host must permit unprivileged user namespaces; distribution security policy can restrict them.
The local defaults combine namespace isolation with a seccomp syscall denylist, disable network access, expose runtime paths read-only, and provide a private writable workspace and temporary directory. Python setup creates a virtual environment offline. Install the host runtime and its venv support first. Select backend="nsjail" to use an installed NsJail binary instead.
The Linux adapters support run(), execute_command(), install(), file copying, and the artifact wrapper. They do not support container images, pooling, or interactive sessions. Files persist between commands in a session; background processes do not. These backends share the host kernel and are not a VM boundary. See configuration, security, and the backend roadmap.
Windows Usage Without Docker
For native Windows Python execution, use the MXC adapter on a compatible Windows host with the helper installed:
To run Linux tools from a Windows Python application, select a WSL2 distribution explicitly:
These are experimental adapters with different prerequisites and API limits. MXC initially supports Python and JavaScript with preinstalled dependencies. WSL2 reuses the Linux Bubblewrap runtime, requires seccomp, and restricts mounts to built-in Linux runtime paths to keep Windows interoperability inaccessible. Both default to disabled networking. See backend setup and limitations.
Installing Libraries
Multi-Language Support
JavaScript
Java
C++
Go
R
Interactive Sessions
For notebook-style workflows you can use InteractiveSandboxSession, which keeps the Python interpreter state across multiple run calls.
Interactive sessions support Docker, Podman, and Kubernetes backends and currently target Python language. They spin up a long-running IPython kernel inside the sandbox, so each run() behaves like a notebook cell—state, imports, and magic commands stay alive until the context manager exits, without any extra networking or manual serialization.
Capturing Plots and Visualizations
Python Plots
R Plots
🔧 Configuration
Basic Configuration
LLM Sandbox also supports copying files between the host and the sandbox:
Custom runtime configs
Remote Docker Host
Kubernetes Support
⚠️ Important for Custom Pod Manifests:
When using custom pod manifests, ensure your container configuration includes:
"tty": True(keeps container alive)- Proper
securityContextat both pod and container levels - Container name can be any valid name (no restrictions)
See the Configuration Guide for complete requirements.
Podman Support
⚡ Container Pooling (Performance Optimization)
Container pooling dramatically improves performance by reusing pre-warmed containers instead of creating new ones for each execution. This is particularly beneficial for applications that execute code frequently.
Key Benefits
- Faster Execution: Eliminate container creation overhead (up to 10x faster)
- Pre-warmed Environments: Containers are initialized with your dependencies
- Thread-Safe: Safely handle concurrent requests
- Resource Efficient: Automatic container lifecycle management
- Flexible Configuration: Control pool size, timeouts, and behavior
Basic Pool Usage
Sharing a Pool Across Sessions
For maximum efficiency, share a single pool across multiple sessions:
Concurrent Execution
Container pools are thread-safe and handle concurrent requests efficiently:
Pool Configuration Options
Pool Exhaustion Strategies
When all containers are busy, the pool can handle it in different ways:
1. WAIT (Default)
Wait for a container to become available:
2. FAIL_FAST
Immediately raise an error:
3. TEMPORARY
Create a temporary container outside the pool:
Monitoring Pool Statistics
Artifact Extraction with Pooling
For capturing plots and visualizations with container pooling, you can use either approach:
Examples
See the examples/ directory for complete demonstrations:
- pool_basic_demo.py - Basic pool usage and configuration
- pool_concurrent_demo.py - Concurrent execution patterns
- pool_monitoring_demo.py - Health monitoring and lifecycle management
- pool_artifact_demo.py - Artifact extraction with pooling (plots, CSV, mixed artifacts)
🤖 LLM Framework Integration
Runnable, version-pinned examples for eleven agent frameworks live in
examples/agent_sdks/:
Each file is self-contained, names the SDK version it was verified against, and applies container hardening. They all share the same core — a sandbox call with the controls that matter once the code was written by a model:
[!IMPORTANT] Security policies are advisory.
session.is_safe(code)returns a verdict — it does not block execution, andrun()executes code the policy flagged. Check it yourself before callingrun(). See the security guide.
🔌 Model Context Protocol (MCP) Server
LLM Sandbox provides a Model Context Protocol (MCP) server that enables AI assistants like Claude Desktop to execute code securely in sandboxed environments. This integration allows LLMs to run code directly with automatic visualization capture and multi-language support.
Features
- Secure Code Execution: Execute code in isolated containers with your preferred backend
- Multi-Language Support: Run Python, JavaScript, Java, C++, Go, R, and Ruby code
- Automatic Visualization Capture: Automatically capture and return plots and visualizations
- Library Management: Install packages and dependencies on-the-fly
- Flexible Backend Support: Choose from Docker, Podman, or Kubernetes backends
Installation
Install LLM Sandbox with MCP support using your preferred backend:
Configuration
Add the following configuration to your MCP client (e.g., claude_desktop_config.json for Claude Desktop):
Backend-Specific Configuration
For the specific backend, you need to set the BACKEND environment variable to the backend you want to use. You might need to set other environment variables depending on the backend you are using. For example, you might need to set the DOCKER_HOST environment variable to the host you want to use if the DOCKER_HOST is not automatically in your system.
Docker (default):
Podman:
For Kubernetes, you might need to set the KUBECONFIG environment variable to the path to your kubeconfig file.
Kubernetes:
Runtime Config Environment Variables
For Docker, Podman, and Micromamba backends, the MCP server can translate SANDBOX_* environment
variables into session runtime_configs.
Supported variables: SANDBOX_NETWORK_MODE, SANDBOX_READ_ONLY, SANDBOX_MEMORY, SANDBOX_MEM_LIMIT,
SANDBOX_CPUS, SANDBOX_CPU_COUNT, SANDBOX_CAP_DROP, SANDBOX_SECURITY_OPT, and SANDBOX_PRIVILEGED.
SANDBOX_MEMORY is normalized to the backend-safe mem_limit runtime config. SANDBOX_CPUS and
SANDBOX_CPU_COUNT are normalized to Linux-compatible CPU quota settings.
Security note: prefer
SANDBOX_NETWORK_MODE=none,SANDBOX_READ_ONLY=true,SANDBOX_CAP_DROP=ALL, and restrictiveSANDBOX_SECURITY_OPTvalues for hardened sandboxes. AvoidSANDBOX_PRIVILEGED=trueunless you explicitly need it, keep CPU and memory limits minimal, and audit any combination that re-enables privileges.SANDBOX_*settings do not apply to the Kubernetes backend in this MCP server. If you need Kubernetes-specific resource or security controls, provide a custompod_manifestvia a custom MCP wrapper or use the llm-sandbox Python API directly.
Available Tools
The MCP server provides the following tools:
execute_code: Execute code in a secure sandbox with automatic visualization captureget_supported_languages: Get the list of supported programming languagesget_language_details: Get detailed information about a specific language
Usage Example
Once configured, you can ask your AI assistant to run code, and it will automatically use the LLM Sandbox MCP server:
The assistant will execute Python code in a secure sandbox and automatically capture any generated plots or visualizations.
🏗️ Architecture
📚 Documentation
- Full Documentation - Complete documentation
- Getting Started - Installation and basic usage
- Configuration - Detailed configuration options
- Security - Security policies and best practices
- Backends - Container backend details
- Languages - Supported programming languages
- Integrations - LLM framework integrations
- API Reference - Complete API documentation
- Examples - Real-world usage examples
🤝 Contributing
We welcome contributions! Please see our Contributing Guide for details.
Development Setup
📖 Citation
If you use LLM Sandbox in your research, please cite it:
The DOI above resolves to the latest release. To cite a specific version, use that release's own DOI from the Zenodo record.
📄 License
This project is licensed under the MIT License - see the LICENSE file for details.
🌟 Star History
If you find LLM Sandbox useful, please consider giving it a star on GitHub!
📞 Support & Community
- GitHub Issues: Report bugs or request features
- GitHub Discussions: Join the community
- PyPI: pypi.org/project/llm-sandbox
- Documentation: vndee.github.io/llm-sandbox
Contributors
[Image]Star History
Source: README.md at commit ec5bd5f
Tools
0Version history
1- v0.3.43LatestSep 16, 2026
Score
50% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 days25 pts
Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.
- Auth declared10 pts
Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts