cVisor is an SDK and runtime for safely executing bash commands locally, without the need for remote sandboxes or local VMs/containers.

Inspired by gVisor, cVisor runs programs directly on the host machine, providing isolation by intercepting and virtualizing Linux syscalls from userspace.

Unlike gVisor, cVisor is built to run directly in your application, spinning up sandboxes in ~2 milliseconds. This makes it ideal for ephemeral tasks commonly performed by LLM agents, such as code execution or filesystem operations.

Status: cVisor is an early proof-of-concept and should not yet be used in production. If you detect any discrepancies between cVisor's behavior and the linux kernel, please file an issue.

Compatibility: cVisor currently ships for Linux hosts only, with support for ARM and X86 architectures and glibc/musl ABIs.

Note: cVisor is a fork of bVisor, rewritten in Rust (the original is written in Zig).

Drop into a Python REPL with cvisor installed, from any machine with Docker:

docker run -it --rm \
  --security-opt seccomp=unconfined --security-opt apparmor=unconfined \
  ghcr.io/astral-sh/uv:python3.12-alpine \
  uv run --with cvisor python

>>> from cvisor import Sandbox
>>> sb = Sandbox()
>>> print(sb.run("echo hi; uname -n").stdout)
hi
cvisor

The --security-opt flags are required: cVisor installs its own seccomp filter, which Docker's default profiles block.

The cVisor runtime ships wrapped in a Typescript SDK, installed via npm.

npm install cvisor

Example usage:

import { Sandbox } from "cvisor";

const sb = new Sandbox();
const output = sb.runCmd("echo 'Hello, world!'");

console.log(await output.stdout());

This executes echo 'Hello, world!' inside a sandbox.

Filesystem operations are safely virtualized:

sb.runCmd("echo 'Hello, world!' > /tmp/test.txt"); // only visible from this sandbox

Unsafe commands are blocked:

sb.runCmd("chroot /tmp"); // error

Python, Ruby, Erlang, Clojure, Bun, and Deno SDKs are also published — see sdks/README.md.

Here are a selection of full examples which currently work in cVisor:

• Hello World - Run your first command in the sandbox
• Running Python - Write and execute a Python script
• Testing Sandbox Boundaries - See how the sandbox handles host fingerprinting, blocked paths, and filesystem isolation
• Filesystem Operations - Demonstrate directory creation, file operations, running scripts

cVisor is built on Seccomp user notifier, a Linux kernel feature that allows userspace processes to intercept and optionally handle syscalls from a child process. This allows cVisor to block or mock the kernel API (such as filesystem read/write, network access, etc.) to ensure the child process remains sandboxed.

Other than the overhead of syscall emulation, child processes run natively.

cVisor is imageless, meaning it does not require a base image to run. It runs with direct visibility to the host filesystem. This allows system dependencies such as npm to work out of the box. Isolation is achieved via a copy-on-write overlay on top of the host filesystem. Files opened with write flags are copied to a sandbox-local directory. Read-only files are passed through to the real filesystem.

Every Linux syscall falls into one of four categories in cVisor:

Syscalls are intercepted and handled in userspace by the cVisor virtual kernel.

Note that cVisor may still call into the underlying kernel to virtualize any given syscall.

Syscalls are forwarded to the kernel unmodified. These syscalls are process-local or read-only and do not require any virtualization.

Syscalls are blocked and return ENOSYS or EPERM. These could allow sandbox escape or privilege escalation.

Not yet handled but likely necessary for Bash compatibility. Currently return ENOSYS.

cVisor is written in Rust (a Cargo workspace under crates/). It depends on Linux kernel features but is developed primarily on ARM Macs; cross-compilation uses cargo-zigbuild, and all kernel-facing tests run in Docker.

Requires: a stable Rust toolchain with the four linux targets, cargo-zigbuild, and Docker.

cargo test -p cvisor-core        # pure-logic unit tests on the host (macOS ok)
cargo xtask test                 # full unit + e2e suite in Alpine (Docker, cross-compiled musl)
cargo xtask run                  # E2E smoke scorecard in the sandbox in Docker
cargo xtask ffi                  # build libcvisor.so and distribute it to the FFI SDKs
cargo xtask run-node             # build libcvisor.node + run the Node SDK test.ts in bun
cargo xtask node-artifacts       # build libcvisor.node for all 4 platform packages

Build with the fail-loudly feature to panic on an unhandled syscall instead of returning ENOSYS:

cargo build -p cvisor-core --features fail-loudly

See sdks/README.md for the language SDKs (Node, Bun, Deno, Python, Ruby, Erlang, Clojure).