Our take
Activeregular commits and releases- Releases more often than 93% of the projects we track
- Merges more pull requests than 81% of the projects we track
- More contributors than 77% of the projects we track
OpenShell is an actively developed, Apache-2.0 runtime for controlling agent access, with frequent commits and releases and a broad contributor base, though its platform requirements and evolving release state merit a trial before production use.
Good fit if
- You need agents to use files, APIs, or credentials while enforcing explicit sandbox and network policies.
- Your team can run the required host virtualization or container setup and wants a CLI, gateway, or Kubernetes deployment path.
- You want an actively maintained project with contributions from many people and an Apache-2.0 license.
Look elsewhere if
- You need a ready-to-use agent included with the sandbox. The default image is minimal Ubuntu and has no agent installed.
- Your target environment is Windows without WSL 2, or you cannot meet the documented Linux, Apple Silicon macOS, and virtualization requirements.
- You need a release process limited to stable versions. The latest release recorded in the project health data is a prerelease.
All health signals
| Last commit | 2026-10-09 (today) |
|---|---|
| Commits, last 90 days | 100+ |
| Releases, last 12 months | 99 (latest dev, 2026-03-18, pre-release) |
| Contributors | 100+ (top contributor: 21% of commits) |
| Issues closed, last 90 days | 23+ (typically closed in 1 day) |
| Pull requests merged, last 90 days | 67 (typically merged in 2 days) |
| Project age | 8 months |
Checked on 2026-10-09 with the GitHub API.
Overview
OpenShell is a runtime for running autonomous AI agents in isolated sandboxes. It addresses the security gap between giving agents useful access to files, packages, APIs, and credentials and allowing them unrestricted access to a host or network.
Teams define policies for what an agent can access. OpenShell enforces them at runtime and checks proposed policy changes for newly granted access before they are applied. The project includes a CLI and gateway, with SDKs for connecting applications to a gateway.
Key Features
- Runs agents in sandboxes with controls over filesystem access and system calls.
- Checks outbound network connections against policy.
- Adds credentials to requests for approved endpoints rather than exposing them directly to agents.
- Uses formal verification to flag risky access introduced by policy changes for human review.
- Provides a gateway to manage sandboxes, policy, and access.
- Offers SDKs for Python, TypeScript, Go, and Rust.
- Supports gateway deployment on Kubernetes using Helm, with a CNI that enforces NetworkPolicy.
- Provides extension points for middleware, interceptors, and compute drivers.
Use Cases
- Security teams can let coding agents install packages or work with files while restricting access to approved paths and network destinations.
- Platform teams can manage sandbox and access policies for a fleet of agents through a gateway.
- Developers can allow an agent to call an approved API without giving it direct access to reusable credentials.
- Application developers can connect Python, TypeScript, Go, or Rust services to an OpenShell gateway using the available SDKs.
What you need
Detected in the repository
- Python >=3.11 (from pyproject.toml)
- Rust 1.94 or newer (from Cargo.toml)
- A test suite and automated checks on GitHub Actions
License in plain words
Apache-2.0permissive
- Commercial use: yes
- Modify and redistribute: yes
- You must keep: the license, the NOTICE file and a note of your changes
- Share your changes: no
- Includes an explicit patent grant from the contributors:
A summary, not legal advice: the LICENSE file is what applies.
Getting Started
On Linux, macOS on Apple Silicon, or Windows with experimental WSL 2, install the CLI and create a sandbox:
curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh
openshell sandbox create --name demo
See the README and documentation for setup details and instructions for running an agent.
Alternatives
- microsandbox: Microsandbox isolates workloads in local microVMs, while OpenShell applies policies to agent access to files, processes, and networks.
- destructive_command_guard: dcg blocks destructive commands through agent hooks, while OpenShell provides broader sandboxing and access policies for agents.
| Project | Language | License | Stars | Status |
|---|---|---|---|---|
| OpenShell | Rust | Apache-2.0 | 15.5k | Active |
| microsandbox | Rust | Apache-2.0 | 8.5k | Active |
| destructive_command_guard | Rust | Other | 6.1k | Active |
Considerations
- OpenShell is a runtime and control layer, not a bundled agent. You need to choose and configure an agent separately.
- Supported environments and virtualization options vary. Windows support through WSL 2 is experimental, and Kubernetes deployments require a CNI that enforces NetworkPolicy.
- The project is changing quickly, with frequent commits and releases; check compatibility between gateway and SDK versions, and evaluate the prerelease status before adopting a release in production.
- The README describes anonymous operational telemetry. It says telemetry excludes prompts, credentials, file paths, hostnames, and other user content, and documents how to disable it.
- Apache-2.0 permits broad use, subject to its license terms and notices.
Found this useful?
Share it with someone who would like OpenShell.