OpenShell README

The project's README from github.com/NVIDIA/OpenShell. As one markdown file: README.md.

OpenShell

License PyPI Security Policy Documentation Project Status

OpenShell is the safe, private runtime for autonomous AI agents. It provides sandboxed execution environments that protect your data, credentials, and infrastructure — governed by declarative YAML policies that prevent unauthorized file access, data exfiltration, and uncontrolled network activity.

OpenShell is built agent-first. It ships public agent skills for using and operating OpenShell, plus separate repository-aware workflows for contributors and maintainers.

Quickstart

Prerequisites

Install

Binary (recommended):

curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh

The installer installs the latest stable release by default. To install a specific version, set OPENSHELL_VERSION. A dev release is also available that tracks the latest commit on main.

The openshell package on PyPI provides the Python SDK only. It does not install the openshell CLI. Add the SDK to a Python project with uv:

uv add openshell

Helm chart:

Experimental — the Kubernetes deployment path is under active development. Expect rough edges and breaking changes.

Deploy the OpenShell gateway into a Kubernetes cluster from the OCI chart published to GHCR:

helm install openshell oci://ghcr.io/nvidia/openshell/helm-chart

See deploy/helm/openshell/README.md for available versions, dev tag conventions, and configuration.

For deploying OpenShell on OpenShift, see deploy/helm/openshell/README.md#install-on-openshift.

Create a sandbox

openshell sandbox create -- claude  # or opencode, codex, copilot

The sandbox container includes the following tools by default:

Category Tools
Agent claude, opencode, codex, copilot
Language python (3.14), node (22)
Developer gh, git, vim, nano
Networking ping, dig, nslookup, nc, traceroute, netstat

For more details see https://github.com/NVIDIA/OpenShell-Community/tree/main/sandboxes/base.

See network policy in action

Every sandbox starts with minimal outbound access. You open additional access with a short YAML policy that the proxy enforces at the HTTP method and path level, without restarting anything.

# 1. Create a sandbox (starts with minimal outbound access)
openshell sandbox create

# 2. Inside the sandbox — blocked
sandbox$ curl -sS https://api.github.com/zen
curl: (56) Received HTTP code 403 from proxy after CONNECT

# 3. Back on the host — apply a read-only GitHub API policy
sandbox$ exit
openshell policy set demo --policy examples/sandbox-policy-quickstart/policy.yaml --wait

# 4. Reconnect — GET allowed, POST blocked by L7
openshell sandbox connect demo
sandbox$ curl -sS https://api.github.com/zen
Anything added dilutes everything else.

sandbox$ curl -sS -X POST https://api.github.com/repos/octocat/hello-world/issues -d '{"title":"oops"}'
{"error":"policy_denied","detail":"POST /repos/octocat/hello-world/issues not permitted by policy"}

See the full walkthrough or run the automated demo:

bash examples/sandbox-policy-quickstart/demo.sh

How It Works

OpenShell isolates each sandbox in its own container with policy-enforced egress routing. A lightweight gateway coordinates sandbox lifecycle, and every outbound connection is intercepted by the policy engine, which does one of three things:

Component Role
Gateway Control-plane API that coordinates sandbox lifecycle and acts as the auth boundary.
Sandbox Isolated runtime with container supervision and policy-enforced egress routing.
Policy Engine Enforces filesystem, network, and process constraints from application layer down to kernel.
Provider Access Profile-defined endpoints, binary policy, and endpoint-bound credential injection for model APIs and other services.

OpenShell runs a gateway control plane that manages sandbox lifecycle through a configured compute driver. Supported compute platforms include Docker, Podman, MicroVM, and Kubernetes.

Protection Layers

OpenShell applies defense in depth across four policy domains:

Layer What it protects When it applies
Filesystem Prevents reads/writes outside allowed paths. Locked at sandbox creation.
Network Blocks unauthorized outbound connections. Hot-reloadable at runtime.
Process Blocks privilege escalation and dangerous syscalls. Locked at sandbox creation.
Providers Grants endpoint-bound credentials and network access. Hot-reloadable at runtime.

Policies are declarative YAML files. Static sections (filesystem, process) are locked at creation; network policy and provider attachments can be updated on a running sandbox.

Providers

Agents need credentials — API keys, tokens, service accounts. OpenShell manages these as providers: named credential bundles that are injected into sandboxes at creation. The CLI auto-discovers credentials for recognized agents (Claude, Codex, OpenCode, Copilot) from your shell environment, or you can create providers explicitly with openshell provider create. Credentials never leak into the sandbox filesystem; they are injected as environment variables at runtime.

Inference access uses the same provider workflow. Attach an inference-capable provider to a sandbox, call the provider's native endpoint, and select the model in the client. Provider profiles contribute the endpoint policy and bind credential placeholders to the authorized destination.

GPU Support (Experimental)

Experimental — GPU passthrough works on supported hosts but is under active development. Expect rough edges and breaking changes.

OpenShell can pass host GPUs into sandboxes for local inference, fine-tuning, or any GPU workload. Add --gpu when creating a sandbox:

openshell sandbox create --gpu --from [gpu-enabled-sandbox] -- claude

Docker-backed GPU sandboxes auto-select CDI when available and otherwise fall back to Docker's NVIDIA GPU request path (--gpus all).

Requirements: NVIDIA drivers and the NVIDIA Container Toolkit must be installed on the host. The sandbox image itself must include the appropriate GPU drivers and libraries for your workload — the default base image does not. See the BYOC example for building a custom sandbox image with GPU support.

Supported Agents

Agent Source Notes
Claude Code base Works out of the box. Provider uses ANTHROPIC_API_KEY.
OpenCode base Works out of the box. Provider uses OPENAI_API_KEY or OPENROUTER_API_KEY.
Codex base Works out of the box. Provider uses OPENAI_API_KEY.
GitHub Copilot CLI base Works out of the box. Provider uses GITHUB_TOKEN or COPILOT_GITHUB_TOKEN.
OpenClaw NemoClaw Run OpenClaw more securely inside NVIDIA OpenShell with the NemoClaw blueprint.
Hermes Agent NemoClaw Run Hermes Agent more securely inside NVIDIA OpenShell with the NemoClaw blueprint.
Ollama Community Launch with openshell sandbox create --from ollama.
Pi Community Launch with openshell sandbox create --from pi.

Key Commands

Command Description
openshell sandbox create -- <agent> Create a sandbox and launch an agent.
openshell sandbox connect [name] SSH into a running sandbox.
openshell sandbox list List all sandboxes.
openshell provider create --type [type] --from-existing Create a credential provider from env vars.
openshell sandbox provider attach <sandbox> <provider> Attach a provider to a running sandbox.
openshell policy set <name> --policy file.yaml Apply or update a policy on a running sandbox.
openshell policy get <name> Show the active policy.
openshell logs [name] --tail Stream sandbox logs.
openshell term Launch the real-time terminal UI for debugging.

See the full documentation for command guides, tutorials, and reference material.

Terminal UI

OpenShell includes a real-time terminal dashboard for monitoring gateways, sandboxes, and providers — inspired by k9s.

openshell term

OpenShell Terminal UI

The TUI gives you a live, keyboard-driven view of your gateway and sandboxes. Navigate with Tab to switch panels, j/k to move through lists, Enter to select, and : for command mode. Gateway health and sandbox status auto-refresh every two seconds.

Community Sandboxes and BYOC

Use --from to create sandboxes from the OpenShell Community catalog or a container image:

openshell sandbox create --from gemini             # community catalog
docker build -t my-sandbox:latest ./my-sandbox-dir # Docker gateway
openshell sandbox create --from my-sandbox:latest  # Docker built image
podman build -t localhost/my-sandbox:latest ./my-sandbox-dir # Podman gateway
openshell sandbox create --from localhost/my-sandbox:latest  # Podman built image
openshell sandbox create --from registry.io/img:v1 # container image

Build with the container engine used by your local gateway. For a remote gateway, push the image to a registry that the gateway can pull from.

See the OpenShell Community catalog and the BYOC example for details.

Use OpenShell with Your Agent

OpenShell provides four portable skills for users and operators: CLI workflows (openshell-cli), gateway troubleshooting (debug-openshell-cluster), inference troubleshooting (debug-inference), and policy generation (generate-sandbox-policy). Install them with the Agent Skills CLI:

npx skills add NVIDIA/OpenShell

These public, installable skills live in skills/ and use the installed CLI help and published documentation as their sources of truth. They do not require an OpenShell source checkout.

Built With Agents

OpenShell is developed using the same agent-driven workflows it enables. Contributor and maintainer skills live separately in .agents/skills/; they automate work on the OpenShell repository and are not included when users install the public skills:

Agent implementation is human-directed: a user may request a phase directly, or maintainers may use the optional agent:* workflow to queue and approve planning and implementation. See AGENTS.md for the full workflow chain documentation.

Getting Help

Learn More

Contributing

OpenShell is built agent-first. Issues should include a user story, problem statement, impact, and acceptance criteria. The impact should explain the consequences of the current behavior and why existing workarounds are insufficient. Feature requests also require a workflow-level proposed design and alternatives; bug reports add reproduction steps, environment details, and relevant logs. Once work is authorized through the project workflow or a direct request, contributors should use the skills in .agents/skills/ to investigate the current code and behavior, implement the change, and verify it. If an issue contains earlier diagnostics, verify them rather than relying on them. See CONTRIBUTING.md for the full agent skills table, contribution workflow, and development setup.

Telemetry

OpenShell collects anonymous telemetry to help improve the project for developers. This data is not used to track individual user behavior. It helps us understand aggregate usage of sandbox, provider, and policy workflows so we can prioritize product improvements and share usage trends with the community.

Disable telemetry at runtime by setting OPENSHELL_TELEMETRY_ENABLED=false on the gateway deployment. For Helm installs, set server.telemetryEnabled=false. OpenShell propagates this deployment setting into sandbox supervisor environments so sandbox-side telemetry collection is disabled as well.

You can also compile telemetry out entirely. Telemetry support is a default-on telemetry Cargo feature, and each crate that carries it also defines a defaults-without-telemetry alias covering every other default feature. Build telemetry-free artifacts with --no-default-features --features defaults-without-telemetry:

cargo build --release -p openshell-gateway --no-default-features --features defaults-without-telemetry
cargo build --release -p openshell-sandbox --no-default-features --features defaults-without-telemetry
cargo build --release -p openshell-driver-vm --no-default-features --features defaults-without-telemetry

The resulting binaries contain no telemetry endpoint, no telemetry HTTP client, and no emission code. With telemetry compiled out, the gateway emits nothing and reports telemetry disabled to th

OpenShell (NVIDIA/OpenShell)

Searching Database…

16.4K ·GitHub
这是什么?OpenShell 是一个开源运行时,用于在隔离的沙箱中运行自主 AI 智能体。它通过声明式的 YAML 策略保护你的文件、凭证和基础设施,防止未授权访问和数据外泄。
这是我安装在自己电脑上的软件,还是需要登录使用的在线服务?它是一个本地命令行工具('openshell'),外加一个网关控制平面,通过多种计算驱动(Docker、Podman、MicroVM 和 Kubernetes)来管理沙箱的生命周期。每个沙箱都是一个隔离的容器,出站流量受策略管控。
怎么安装,怎么创建我的第一个沙箱?先运行安装程序——默认会安装最新的稳定版本(也有跟随 main 分支的开发版)。然后用 'openshell sandbox create' 创建你的第一个沙箱,它可以立即启动一个智能体。
我需要提前装好 Docker 或 Podman 吗?需要——你得有一个本地运行时:Docker、Podman,或者开启宿主机虚拟化以支持基于 MicroVM 的沙箱。注意,PyPI 上的 'openshell' 包只包含 Python SDK,不含命令行工具。
Kubernetes 部署方式现在稳定到可以用于生产环境了吗?还没有——通过 Helm chart 部署网关目前是实验性的,仍在积极开发中,预计会遇到不完善的地方和破坏性变更。
它能在 Windows 上用吗,还是只支持 Linux 和 Mac?支持的宿主机有 Linux、macOS(Apple Silicon),以及启用 WSL 2 的 Windows——Windows 这条路线被标记为实验性。沙箱本身则运行在 Docker、Podman、MicroVM 或 Kubernetes 上。
它怎么保证我的 API 密钥不会暴露给智能体?密钥以提供方(providers)的形式管理——这是命名的凭证包,只作为运行时环境变量注入沙箱,绝不会写入沙箱的文件系统。命令行工具还会自动从你的 shell 中发现 Claude、Codex、OpenCode 和 Copilot 的凭证。
哪些 AI 智能体可以在沙箱里运行?Claude Code、OpenCode、Codex 和 GitHub Copilot CLI 开箱即用,凭证会自动发现。OpenClaw 和 Hermes Agent 通过 NemoClaw 蓝图运行,而 Ollama 或 Pi 等社区沙箱可以用 'openshell sandbox create --from ollama' 启动。
沙箱能用我的 GPU 做本地推理吗?可以,但目前还是实验性功能:创建沙箱时加上 --gpu 即可。宿主机需要安装 NVIDIA 驱动和 NVIDIA Container Toolkit,而且由于默认基础镜像不包含 GPU 库,大多数工作负载需要自定义的 BYOC 沙箱镜像。
有没有仪表盘可以实时查看我的沙箱?有——'openshell term' 会打开一个受 k9s 启发的实时终端界面,可以实时查看网关、沙箱和提供方。Tab 键切换面板,j/k 键在列表中移动,健康状态每两秒自动刷新一次。
沙箱里预装了哪些工具?包括智能体命令行工具(claude、opencode、codex、copilot)、Python 3.14 和 Node 22、gh、git、vim、nano 等开发工具,以及一些网络实用工具。你也可以通过 --from 从社区目录镜像或你自己的镜像启动。
Creator
NVIDIA
Size
85.8 MB
Stars
16.4K
Age
7mo
Commits · 90 Days