What It Does
NVIDIA OpenShell is an open-source (Apache-2.0) Rust runtime that provides sandboxed execution environments for autonomous AI agents. Each sandbox is an isolated container with policy-enforced egress routing. A lightweight gateway (K3s cluster inside a single Docker container) coordinates sandbox lifecycle, and every outbound connection is intercepted by a policy engine that allows, denies, or routes-for-inference based on declarative YAML rules.
OpenShell applies defense-in-depth across four policy domains: filesystem (Landlock LSM, locked at creation), process (seccomp syscall filtering, locked at creation), network (hot-reloadable YAML egress policies), and inference (privacy-aware routing that strips caller credentials and injects backend credentials). Supported agents include Claude Code, OpenCode, Codex, GitHub Copilot CLI, OpenClaw, and Ollama out of the box.
Key Features
- Four-layer isolation: Filesystem (Landlock), process (seccomp), network (namespace + proxy), inference (credential-stripping privacy router) — static layers locked at creation, dynamic layers hot-reloadable
- Declarative YAML network policies: L7 policy enforcement at the HTTP method + path level;
openshell policy set --waitapplies changes to a live sandbox without restart - Privacy router: Strips agent credentials, injects backend credentials — agents never hold provider API keys directly; prevents credential exfiltration
- K3s-in-Docker gateway: Full Kubernetes control plane inside a single Docker container; no external cluster required
- Multi-agent support: Claude Code, Codex, OpenCode, GitHub Copilot CLI, OpenClaw, and Ollama supported in the base sandbox image
- Provider credential management: Auto-discovers credentials from shell environment and injects as runtime environment variables (never written to sandbox filesystem)
- GPU passthrough (experimental): NVIDIA Container Toolkit integration for local inference or GPU workloads inside sandboxes
- Remote sandbox creation:
--remote user@hostdeploys the sandbox on a remote machine
Use Cases
- Sandboxed AI coding assistant execution: Running Claude Code, Codex, or OpenCode with enforced filesystem and network constraints, preventing unauthorized file access and data exfiltration
- Controlled egress for agent workloads: Teams wanting to allow agent internet access at the HTTP method+path level (e.g., read-only GitHub API, blocked POST) rather than all-or-nothing network isolation
- Credential isolation: Scenarios where you want agents to call AI providers without having direct access to the API keys
- Local inference sandboxing with GPU: Passing through NVIDIA GPUs into isolated sandboxes for Ollama-based local model serving with network constraints
Adoption Level Analysis
Small teams (<20 engineers): Good fit for Linux-native developers wanting sandboxed AI assistants with visible policy defaults. One-command install. macOS and Windows work with documented caveats. 8 GB RAM minimum.
Medium orgs (20-200 engineers): Viable for teams that want policy-as-code agent sandboxing without full Kubernetes. The multi-agent support (Claude Code, Codex, OpenCode, Copilot) differentiates it from NemoClaw’s OpenClaw focus. Alpha status is the primary risk.
Enterprise (200+ engineers): Not yet fit. Alpha software, single-player architecture (no multi-tenant), and kernel-based (not VM-based) isolation fall short of enterprise security requirements. NVIDIA is explicitly building toward multi-tenant enterprise deployments as a future milestone.
Alternatives
| Alternative | Key Difference | Prefer when… |
|---|---|---|
| NemoClaw | Higher-level abstraction on OpenShell; OpenClaw-specific with blueprint lifecycle and NVIDIA Endpoints integration | You specifically run OpenClaw and want the guided onboarding and state management layer |
| Kubernetes Agent Sandbox | K8s-native CRD approach; gVisor/Kata Containers VM-level isolation; official SIG project | You run Kubernetes and need VM-level isolation or multi-tenant sandboxing at scale |
| E2B | Firecracker microVM SaaS; strongest isolation boundary, fully managed | You need hardest isolation and prefer zero-ops managed infrastructure |
| Modal | gVisor + native GPU, Python-first, cloud execution | Your workloads are GPU-heavy Python and you prefer a cloud execution model |
| Daytona | Docker-based, persistent dev environments, computer-use focus | You want persistent state dev sandboxes rather than agent runtime isolation |
Evidence & Sources
- GitHub: NVIDIA/OpenShell
- OpenShell documentation
- OpenShell Community sandboxes
- NemoClaw documentation — Architecture
Notes & Caveats
- Alpha software: Published alongside NemoClaw in March 2026. Single-player mode only (one developer, one environment, one gateway). Multi-tenant is a stated roadmap goal, not a current capability.
- Kernel-based isolation, not VM-based: Landlock + seccomp is meaningful defense-in-depth but does not provide the hard boundary of Firecracker microVMs or gVisor. Kernel exploits or privilege escalation bugs could bypass these controls.
- K3s overhead: The K3s-in-Docker gateway adds ~2.4 GB image size and requires 8 GB RAM minimum. The OOM risk during image push is documented; configure swap if running on constrained hardware.
- macOS / Windows limitations: Fully tested only on Linux. macOS Apple Silicon and Windows WSL2 work with additional setup but are not the primary tested paths.
- NVIDIA ecosystem dependency: GPU passthrough requires NVIDIA Container Toolkit. The project is maintained by NVIDIA and the default inference backends are NVIDIA-hosted. Community adoption outside the NVIDIA ecosystem is unproven.
- GPU passthrough is experimental: Marked explicitly as under active development with expected breaking changes.