senv Review 2026: Sandbox Your Python Runs So a Bad Dependency Can't Read Your SSH Keys

A virtual environment isolates your dependencies. It does not isolate your code. That sentence is the whole reason senv exists. When you pip install or uv add a package, its build script runs on your machine with your permissions — it can read ~/.ssh, grab environment variables, and phone home. And when your project later runs, a compromised dependency can rewrite the environment to persist itself for next time. venv and uv are a PATH convention, not a security boundary. senv, a small Rust tool from the h5i-dev team, bolts an actual OS-level sandbox underneath the uv workflow you already use.

The pitch is appealing because it asks for almost nothing in return. A senv project is still a uv project: same pyproject.toml, same uv.lock. Teammates who never install senv keep using uv exactly as before. But every install and run you do through senv is wrapped in a policy that treats the two dangerous moments differently — installing dependencies (where build code can touch your machine) and running code (where installed packages can). The result is the kind of boundary most Python developers know they should have but never bother to set up.

What senv Does

At its core, senv keeps the familiar uv command surface and adds a deny-by-default sandbox beneath it. uv sync becomes senv sync, uv run pytest becomes senv run pytest, and flags pass straight through to uv so exit codes and CI behavior are unchanged. Under the hood, the two phases get separate policies.

During install, dependency build code can reach approved package registries (PyPI and any configured indexes) but not your source tree or your credentials. During run, your project directory is writable, but the installed environment is read-only and the network is denied unless you explicitly allow it. The managed environment lives outside the project, so a package cannot quietly rewrite .venv to survive into the next run. senv even compiles bytecode at install time and disables writable bytecode caches at runtime, closing the “leave a modified .pyc” trick.

It is deliberately scoped: senv is not a container, not a new package manager, and not a runtime of its own. It is one binary that makes the uv commands you already type enforce a boundary instead of trusting every line of build and runtime code.

Use Cases

• Running AI-agent-generated Python. If you let Claude Code, Codex, or a similar agent scaffold and execute code on your machine, senv confines what that generated code — and its dependencies — can actually reach.
• Evaluating untrusted third-party packages. Trying a new library whose build script you have not read? senv sync keeps that build code off your credentials and source.
• CI and shared runners. senv run pytest drops into pipelines with fail-closed defaults, so a poisoned test dependency cannot exfiltrate secrets from the runner.
• Supply-chain-conscious local dev. Teams that already depend on uv lock and vulnerability scanners get runtime isolation on top, not instead of, those practices.

Key Features

uv workflow preserved

Commands map 1:1 to uv and pass flags and exit codes through, so adoption is a find-and-replace of your muscle memory — source .venv/bin/activate becomes senv shell, uv run becomes senv run.

Two-policy isolation

Installs get registry-only network; runs get deny-by-default network, a read-only environment, and only explicitly declared secrets. The split reflects that build time and run time carry different risk.

Explicit, phase-scoped secrets

Secrets are declared in senv.toml (env:, file:, or command: sources) and scoped to phases. They are never handed to install-time build code, and command: secret sources require an explicit opt-in because the command runs on the host.

Policy trust model

Because senv.toml lives inside the project, a compromised dependency could try to widen it. senv keeps the last accepted policy snapshot outside the sandbox; a wider policy is refused until you inspect and accept it with senv trust.

Auditable denials

senv status shows what is enforced; blocked operations print the narrowest command to permit them (senv allow api.stripe.com); senv report --suggest proposes a policy without changing anything.

Pricing

senv is free and open source under the Apache-2.0 license. There is no paid tier, no account, and no SaaS component — it runs fully local-first. Install via the provided script, uv tool install h5i-senv, pipx install h5i-senv, or cargo install. The only hard dependency is uv on your PATH; Linux additionally needs slirp4netns and nftables, and Windows is WSL2-only.

Common Questions

Is senv a replacement for Docker? No. Docker gives stronger, heavier isolation in a separate workflow. senv is the lighter option for “I want my normal uv project to stop trusting every build and runtime line” without spinning up containers.

Will my existing uv project break? No. senv init keeps pyproject.toml and uv.lock as-is; teammates without senv keep using uv directly. It creates a separate managed environment rather than overwriting your .venv.

Does it slow runs down? The overhead is the sandbox, not a translation layer — commands pass through to uv. For most dev and CI work the cost is negligible; the bigger “cost” is the occasional senv trust prompt when a policy legitimately needs to widen.

Verdict

senv fixes a real gap: a virtualenv isolates dependencies but not code, so a malicious or careless package can read your credentials or persist itself during install and run. senv adds a deny-by-default OS boundary while keeping the uv workflow your team already knows, which makes it genuinely useful for anyone running agent-generated Python or untrusted dependencies. The trust model and secrets handling are thoughtful, and Apache-2.0 plus a single Rust binary make it easy to try.

The caveats are maturity and narrowness. It is v0.1.0 with a small community (around 43 stars at review time) and a quiet month of pushes, so treat the CLI as pre-1.0. And it is a Python security tool rather than an “AI tool” — its relevance to AI is indirect, through safe execution of agent-written code. For the 9bests audience, that lands at a solid 6.5/10: worth knowing if you execute untrusted code, easy to skip if you just want faster installs. One correction worth flagging: this repository was originally logged in our tracker as a “multi-agent orchestration SDK,” which is incorrect — it is a sandboxed-environment tool, and this review reflects the real product.