Sandboxed Python Environments

senv is a security boundary for Python environments. It runs uv and your code inside an OS-level sandbox with a different policy for each moment that carries risk: installs reach package registries and nothing else and cannot write to your source tree, and your code runs with no network by default, an environment it cannot modify, and no access to your credentials. One Rust binary, Apache 2.0, and it adds no files to your project beyond an optional senv.toml.

venv and uv isolate dependencies, not code. A virtual environment is a PATH convention: a package inside one can still read ~/.ssh, take your environment variables, open a socket to any destination, and execute build code during installation with your full user permissions. senv keeps the uv workflow and puts an OS-level sandbox underneath it. A senv project is still a uv project, so teammates without senv keep running plain uv against the same repository.

No, and it does not try. senv contains what a package can do rather than deciding what a package is. Lockfile hashes, pinned versions, and dependency review remain exactly as important as before. What changes is the blast radius: a malicious sdist build backend runs with no reach into your source tree, your credentials, or any network destination that is not a package registry.

Network access is denied by default, the installed environment is read-only, credentials are unavailable unless declared as secrets in senv.toml, and CPU and file-size limits apply everywhere with memory and process limits on Linux. Your project directory stays read-write, because that is the point of running the code. When something is blocked, senv prints what was blocked and the narrowest command that would permit it.

No. You widen one host at a time. senv allow api.stripe.com records the grant in senv.toml; senv run --allow-net api.stripe.com applies it to a single command. senv report --suggest aggregates the denials recorded across runs and prints a policy stanza to review — it never writes the policy for you. Some denials are guarantees rather than defaults, and senv does not offer to bypass those: runtime code cannot make the environment writable or read ~/.ssh.

It can edit senv.toml, because that file lives in your project and your project is writable while your code runs. It cannot make the edit take effect. senv keeps the last accepted policy snapshot outside the sandbox: an unchanged or narrower policy runs normally, and a wider one is refused with a diff until you inspect it and run senv trust. The same check covers the pyproject.toml sections that control install behavior, [build-system] and [tool.uv]. This is tamper-evidence, not tamper-prevention, and we do not claim more.

The default tiers share the host kernel: Landlock, seccomp, and Seatbelt are OS-level isolation, not a hypervisor boundary, so isolation = "microvm" is the rung for when a separate kernel is required. Installation must write packages, so the install sandbox protects your source, credentials, and non-registry network but cannot make the environment read-only during an install. Kernel-tier denial reports infer some denials from program output, which untrusted code can influence, so review every suggested grant. And running .venv/bin/python directly from an editor bypasses the run boundary entirely; use senv run or senv shell. The manual keeps the full list.

An optional senv.toml, and nothing else. The environment, the wheel cache, the receipts, and the trusted policy baseline all live outside the project tree, because the run phase grants the project read-write and receipts a compromised package can rewrite are not evidence. .venv stays as a symlink so editors and language servers still resolve. senv refuses to run if SENV_STATE_DIR or SENV_CACHE_DIR points inside the project.

Linux and macOS. On Linux, senv uses Landlock, seccomp-bpf, namespaces, and rlimits or cgroups, and registry allowlisting during installs additionally needs slirp4netns and nftables. On macOS it uses the built-in Seatbelt sandbox with a DNS-pinned loopback proxy for allowed egress, and no extra runtime is required; macOS has no seccomp and cannot enforce cgroup memory or process limits, which senv reports rather than silently ignoring. On Windows, use WSL2. Run senv doctor to see what your host can actually enforce.

senv refuses to run and explains what is missing. It never silently downgrades to a weaker boundary, and there is no flag that runs your code on the host unconfined. An explicit downgrade such as install.net = "host" is available for hosts that cannot allowlist registries, but it is written in the config, warned about in senv status, and stamped into every receipt.

senv uses h5i-sandbox, the confinement engine behind h5i, as a linked Rust crate, and compiles the Python-shaped senv.toml into an h5i policy. h5i gives a coding agent a whole disposable development environment; senv confines one Python project's installs and runs. They share the enforcement layer, the receipt model, and the rule that a boundary fails closed.