
Python Exec Sandbox
io.github.lu-zhengdaPublished by GitHub account lu-zhengdav0.1.5Updated Oct 25, 2026
Sandboxed Python execution for AI agents. PEP 723 inline deps, multi-version Python, zero pollution.
Overview
A local MCP server that lets an AI assistant run Python scripts in an isolated sandbox with inline PEP 723 dependencies and selectable Python versions.
- What you can do
- Execute Python scripts with automatic dependency resolution, optional extra dependency specifiers and a per-run timeout, with output truncation to protect the agent context. Validate a script's PEP 723 metadata and dependencies without running it. Inspect the execution environment, including Python and uv versions, platform, sandbox status and configuration. Run scripts on Python 3.13, 3.14 or 3.15, with uv downloading the target version automatically.
- When to use it
- Useful when an assistant needs to run Python for calculations, data checks or quick experiments without polluting the host's Python, site-packages or virtualenvs. Also fits workflows that want per-run isolation, disposable environments and controlled timeouts.
- Requirements
- Runs locally over stdio, typically via uvx. Requires Python 3.13+ for the server process and uv for dependency resolution and Python version downloads. Sandboxing needs bubblewrap on Linux or Docker on macOS and other platforms; the Docker image is pulled automatically on first use. The no-sandbox backend needs neither.
Installation
In SourceWeft
- Open Python Exec 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
mcp-python-exec-sandbox
[CI] [PyPI] [Python] [License]
Sandboxed Python execution for AI agents. Scripts run in ephemeral, isolated environments with inline dependencies (PEP 723) -- zero host pollution, zero leftover venvs, zero package conflicts.
Why?
Every coding agent can already run Python on your host. The problem is what happens next: packages accumulate, venvs sprawl, and a rogue pip install breaks your system. mcp-python-exec-sandbox eliminates this:
- Scripts execute in a sandbox (bubblewrap on Linux, Docker on macOS/other platforms)
- Dependencies are declared inline and resolved ephemerally via
uv - Nothing touches your host's Python, site-packages, or virtualenvs
- Each execution is isolated and disposable
Features
- Sandboxed execution -- platform-specific isolation prevents host filesystem access
- PEP 723 inline metadata -- declare dependencies directly in scripts with
# /// scriptblocks - Multi-version Python -- run scripts on Python 3.13, 3.14, or 3.15 (uv downloads the right version automatically)
- Ephemeral environments -- dependencies are resolved per-execution, never persisted
- Package caching -- uv's global cache makes repeat installs near-instant
- Timeout enforcement -- configurable per-execution timeouts
- Output truncation -- prevents runaway output from overwhelming the agent
Prerequisites
All setups require:
- Python 3.13+ -- to run the MCP server process
- uv -- manages script execution, dependency resolution, and Python version downloads. Also provides
uvxfor running the server without installing it globally.
Additional requirements depend on your chosen sandbox backend:
Host Python vs. execution Python: These are independent. Python 3.13+ is needed to run the server process itself. The
--python-versionflag controls which Python version your scripts execute on -- uv downloads the target version automatically. You do not need to install Python 3.14 or 3.15 on your host to run scripts on those versions.
Quick start
Claude Code (Linux -- native sandbox)
Claude Code (macOS -- Docker sandbox, recommended)
The Docker sandbox image is pulled automatically from GHCR on first use. No manual build required.
Claude Code (no sandbox)
Cursor
Add to .cursor/mcp.json (project-level) or ~/.cursor/mcp.json (global):
OpenAI Codex CLI
Or add to .codex/config.toml:
Other MCP clients
Any client that supports the MCP stdio transport can use this server:
Multi-version Python
Use --python-version to target a specific Python version. uv downloads it automatically -- no manual install needed.
This works across all sandbox backends. The Docker sandbox uses uv inside the container to manage Python versions, so the same --python-version flag applies.
Tools
execute_python
Execute a Python script with automatic dependency management.
check_environment
Returns information about the execution environment: Python version, uv version, platform, sandbox status, and configuration.
validate_script
Validates a script's PEP 723 metadata and dependencies without executing it.
Sandbox backends
The default backend is native (bubblewrap) on Linux and docker on macOS/other platforms. Specifying --sandbox-backend native on macOS automatically redirects to Docker. If the sandbox tool is unavailable, the server falls back to none with a warning.
Docker sandbox setup
The Docker sandbox image is published to GHCR and pulled automatically when the server starts. No manual setup is needed.
To build locally for development:
CLI options
Development
Setup
Project structure
Running tests
Unit and integration tests -- fast, run everywhere:
E2E tests -- require uv and network access. These exercise real script execution, package installation, MCP protocol flow, and sandbox enforcement:
Docker sandbox tests
The Docker E2E tests (e2e_tests/test_docker_sandbox.py) verify execution, dependency installation, read-only filesystem enforcement, host isolation, and timeout handling through the Docker backend.
Prerequisites:
- Docker must be installed and running
- Build the sandbox image:
Then run:
These tests are automatically skipped if Docker is unavailable or the image hasn't been built.
Linux sandbox tests (devcontainer)
The Linux sandbox tests (e2e_tests/test_sandbox_enforcement.py::test_linux_sandbox_blocks_etc_shadow) use bubblewrap (bwrap) for namespace isolation. They are skipped on macOS because bwrap is Linux-only.
To run them from macOS, use the included devcontainer which provides Ubuntu 24.04 with bwrap pre-installed:
VS Code:
- Install the Dev Containers extension
- Open the project and select Reopen in Container
- In the integrated terminal:
CLI:
Test matrix
Contributing
- One logical change per commit. Descriptive commit message (imperative mood).
- Run
uv run pytest tests/ -vbefore committing -- all tests must pass. - Add tests for new functionality: unit tests in
tests/, E2E ine2e_tests/if it needs real execution. - Keep dependencies minimal. Do not add runtime deps without strong justification.
- Tool docstrings in
server.pyare user-facing MCP tool descriptions. Write them for an LLM audience. - Sandbox backends must degrade gracefully: if the required tool (bwrap, docker) is missing, fall back to
NoopSandboxwith a warning.
License
MIT
Source: README.md at commit ffdee0e
Tools
0Version history
1- v0.1.5LatestSep 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