GitHub
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
作者提供的说明(英文原文)
Sandboxed Python execution for AI agents. PEP 723 inline deps, multi-version Python, zero pollution.
这三项永远不会合并成一个分数:意见、测量和人气是不同的东西。
我们还没有为它写通俗的介绍。下面是我们从注册中心读取到的事实。
选择你使用的 AI 应用,然后复制设置。
你需要
你用的是哪个应用?
在上方选择你的应用。我们会记住它,下次按钮会显示“安装到 …”。
打开 Claude Desktop → Settings → Developer → Edit Config,把下面的内容粘贴到 claude_desktop_config.json
{
"mcpServers": {
"python-exec-sandbox": {
"command": "uvx",
"args": [
"mcp-python-exec-sandbox"
]
}
}
}在终端中运行这条命令
claude mcp add python-exec-sandbox -- uvx mcp-python-exec-sandbox粘贴到项目中的 .cursor/mcp.json,或 ~/.cursor/mcp.json
{
"mcpServers": {
"python-exec-sandbox": {
"command": "uvx",
"args": [
"mcp-python-exec-sandbox"
]
}
}
}浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。
粘贴到项目中的 .vscode/mcp.json
{
"servers": {
"python-exec-sandbox": {
"type": "stdio",
"command": "uvx",
"args": [
"mcp-python-exec-sandbox"
]
}
}
}浏览器会先询问是否打开应用,然后应用会显示设置并请你确认。密钥的值会留空,由你自己填写。
这个服务器在你的电脑上运行,而 ChatGPT 只能连接互联网上的服务器。请选择其他应用。
你的选择通过 Cookie 保存在这台设备上,无需账户。
这些设置是根据作者在注册中心的条目生成的。如果 README 的写法不同,请以 README 为准。
它在你的电脑上运行;安装后,工具列表会显示在你的 AI 应用中。
我们检查的是任何人都能看到的信息;我们没有阅读代码。不适用的检查项不计入总数。 · 检查于 2026年11月7日
注册名称已通过 GitHub 账户 lu-zhengda 验证,该账户拥有此仓库
我们还没有从 GitHub 读取这个仓库
我们还没有从 GitHub 读取这个仓库
它在你的电脑上运行,没有互联网端点
在你的电脑上运行,改用本地设置
它在你的电脑上运行;我们只能读取互联网端点的工具列表
与注册中心里这个分类中所有活跃的服务器比较。只有当发布者拥有该仓库时,星标数才计入。
它在 1 项适用的基础检查中通过了 1 项。我们没有阅读代码。在添加密钥或令牌之前,请先看看这个服务器要求哪些权限,并使用只具备所需权限的密钥。
注册中心没有列出必需的密钥,不过有些服务器会在首次使用时要求你登录。
它在你的电脑上运行。你的 AI 应用会在需要时启动它,数据不会经过作者的服务器(除非它自己调用在线服务)。
GitHub 仓库最后更新于–,最新版本(0.1.5)于9个月前进入注册中心。
支持 MCP 的应用,例如 Claude Desktop、Claude Code、Cursor 和 VS Code。你的电脑上还需要有 Python (uv)。
同一分类中有:GitHub, Desktop Commander, Cloudflare MCP
同一分类中其他作者的服务器,按星标数排序。
如何看卡片:★ GitHub 星标i三大支柱:评价 · 检查 · 使用情况i更新 = 最新版本发布到注册中心的时间i
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
MCP server for terminal commands, file operations, and process management
Cloudflare MCP servers
按原文从作者的仓库复制。PopNx MCP 没有审查或背书其内容。HTML、图片和脚本已被移除。链接会离开本站。
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.
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:
uv# /// script blocksAll setups require:
uvx for running the server without installing it globally.Additional requirements depend on your chosen sandbox backend:
| Setup | Additional requirements | Install |
|---|---|---|
| Native sandbox (Linux) | bubblewrap | sudo apt install bubblewrap |
| Docker sandbox (macOS, any) | Docker Engine | See Docker docs |
| No sandbox | None | -- |
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.
claude mcp add python-sandbox -- uvx mcp-python-exec-sandbox
claude mcp add python-sandbox -- uvx mcp-python-exec-sandbox
The Docker sandbox image is pulled automatically from GHCR on first use. No manual build required.
claude mcp add python-sandbox -- uvx mcp-python-exec-sandbox --sandbox-backend none
Add to .cursor/mcp.json (project-level) or ~/.cursor/mcp.json (global):
{
"mcpServers": { "python-sandbox": { "command": "uvx", "args": ["mcp-python-exec-sandbox"] } } }
codex mcp add python-sandbox -- uvx mcp-python-exec-sandbox
Or add to .codex/config.toml:
[mcp_servers.python-sandbox]
command = "uvx" args = ["mcp-python-exec-sandbox"]
Any client that supports the MCP stdio transport can use this server:
{
"mcpServers": { "python-sandbox": { "command": "uvx", "args": ["mcp-python-exec-sandbox"] } } }
Use --python-version to target a specific Python version. uv downloads it automatically -- no manual install needed.
# Python 3.13 (default)
uvx mcp-python-exec-sandbox --python-version 3.13
uvx mcp-python-exec-sandbox --python-version 3.14
uvx mcp-python-exec-sandbox --python-version 3.15
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.
execute_pythonExecute a Python script with automatic dependency management.
| Parameter | Type | Default | Description |
|---|---|---|---|
script | str | required | Python source code, may include PEP 723 inline metadata |
dependencies | list[str] | [] | Extra PEP 508 dependency specifiers to merge |
timeout_seconds | int | 30 | Maximum execution time (1--300) |
# Simple script
execute_python(script="print('hello world')")
execute_python( script="import requests; print(requests.get('https://httpbin.org/get').status_code)", dependencies=["requests"] )
execute_python(script="""
import pandas as pd print(pd.DataFrame({'a': [1,2,3]}).describe()) """)
check_environmentReturns information about the execution environment: Python version, uv version, platform, sandbox status, and configuration.
validate_scriptValidates a script's PEP 723 metadata and dependencies without executing it.
| Parameter | Type | Default | Description |
|---|---|---|---|
script | str | required | Python source code to validate |
dependencies | list[str] | [] | Extra dependency specifiers to validate |
| Backend | Platform | Tool | Notes |
|---|---|---|---|
native | Linux | bubblewrap | Namespace isolation, network allowed |
docker | Any | Docker | Container isolation, resource limits |
none | Any | -- | No sandboxing (not recommended) |
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.
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:
docker build -t ghcr.io/lu-zhengda/mcp-python-exec-sandbox profiles/
mcp-python-exec-sandbox [OPTIONS]
Options: --python-version TEXT Python version for execution (default: 3.13) --sandbox-backend TEXT native | docker | none (default: native on Linux, docker on macOS) --max-timeout INT Maximum allowed timeout in seconds (default: 300) --default-timeout INT Default timeout in seconds (default: 30) --max-output-bytes INT Maximum output size in bytes (default: 102400) --no-warm-cache Skip cache warming on startup --uv-path TEXT Path to uv binary (default: uv)
git clone https://github.com/lu-zhengda/mcp-python-exec-sandbox.git
cd mcp-python-exec-sandbox uv sync --dev
src/mcp_python_exec_sandbox/ # Package source
server.py # FastMCP server + tool definitions executor.py # uv subprocess orchestration script.py # PEP 723 metadata parsing/merging sandbox.py # Sandbox ABC + factory sandbox_linux.py # bubblewrap sandbox (Linux) sandbox_docker.py # Docker sandbox (macOS/any) config.py, cache.py, output.py, errors.py tests/ # Unit + integration tests (mocked or local uv) e2e_tests/ # End-to-end tests (require uv + network) profiles/ # Dockerfile, warmup packages .devcontainer/ # Devcontainer for Linux sandbox testing from macOS
Unit and integration tests -- fast, run everywhere:
uv run pytest tests/ -v
E2E tests -- require uv and network access. These exercise real script execution, package installation, MCP protocol flow, and sandbox enforcement:
uv run pytest e2e_tests/ -v
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 build -t ghcr.io/lu-zhengda/mcp-python-exec-sandbox profiles/
Then run:
uv run pytest e2e_tests/test_docker_sandbox.py -v
These tests are automatically skipped if Docker is unavailable or the image hasn't been built.
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:
uv run pytest e2e_tests/test_sandbox_enforcement.py -v
CLI:
# Install the devcontainer CLI (once)
npm install -g @devcontainers/cli
devcontainer up --workspace-folder .
devcontainer exec --workspace-folder . uv run pytest e2e_tests/test_sandbox_enforcement.py -v
| Test suite | Command | Requirements |
|---|---|---|
| Unit tests | uv run pytest tests/ -v | uv |
| Integration tests | uv run pytest tests/test_integration.py -v | uv |
| E2E (general) | uv run pytest e2e_tests/ -v | uv, network |
| E2E (Docker sandbox) | uv run pytest e2e_tests/test_docker_sandbox.py -v | uv, Docker, sandbox image |
| E2E (Linux/bwrap sandbox) | uv run pytest e2e_tests/test_sandbox_enforcement.py -v | uv, Linux with bwrap (or devcontainer) |
uv run pytest tests/ -v before committing -- all tests must pass.tests/, E2E in e2e_tests/ if it needs real execution.server.py are user-facing MCP tool descriptions. Write them for an LLM audience.NoopSandbox with a warning.MIT