* fix(l7): reject ambiguous HTTP framing in REST proxy (SEC-009) Harden the L7 REST proxy HTTP parser against request smuggling: - Reject requests containing both Content-Length and Transfer-Encoding headers per RFC 7230 Section 3.3.3 (CL/TE ambiguity) - Replace String::from_utf8_lossy with strict UTF-8 validation to prevent interpretation gaps with upstream servers - Reject bare LF line endings (require CRLF per HTTP spec) - Validate HTTP version string (HTTP/1.0 or HTTP/1.1 only) * fix(server): harden shell_escape and command construction (SEC-002) Harden the gRPC exec handler against command injection via the structured-to-shell-string conversion: - Reject null bytes and newlines/carriage returns in shell_escape() - Add input validation in exec_sandbox: reject control characters in command args, env values, and workdir - Enforce size limits: max 1024 args, 32 KiB per arg/value, 4 KiB workdir, 256 KiB total assembled command string - Change shell_escape and build_remote_exec_command to return Result so callers must handle validation failures * fix(server): add command validation at SSH transport boundary (SEC-003) Add defense-in-depth validation in run_exec_with_russh before sending the command to the sandbox SSH server: - Reject null bytes in command string at transport boundary - Enforce max command length (256 KiB) at transport boundary - Enhance stream_exec_over_ssh logging with command length, stdin length, and truncated command preview for audit trail * fix(sandbox): validate port range and extend loopback check in SSH (SEC-007) Harden the SSH direct-tcpip channel handler: - Validate port_to_connect <= 65535 before u32-to-u16 cast to prevent port truncation (e.g., 65537 becoming port 1) - Replace string-literal loopback check with is_loopback_host() that covers the full 127.0.0.0/8 range, IPv4-mapped IPv6 (::ffff:127.x), bracketed IPv6, and case-insensitive localhost - Remove #[allow(clippy::cast_possible_truncation)] since the cast is now proven safe by the preceding range check * fix(sandbox): sanitize inference error messages returned to sandbox (SEC-008) Replace verbatim internal error strings in router_error_to_http with generic messages to prevent information leakage to sandboxed code. Upstream URLs, internal hostnames, TLS details, and file paths are no longer exposed. Full error context is still logged server-side at warn level by the caller for debugging. * fix(server): block internal IPs in SSH proxy target validation (SEC-006) Add IP validation in start_single_use_ssh_proxy to prevent SSRF if a sandbox status record were poisoned: - Resolve DNS before connecting and validate the resolved IP - Block loopback (127.0.0.0/8) and link-local (169.254.0.0/16, covers cloud metadata endpoint) addresses - Block IPv4-mapped IPv6 variants of the same ranges - Connect to the validated SocketAddr directly to prevent TOCTOU - Add debug logging of resolved target IP for audit * fix(sandbox): add resource limits to chunked body parser (SEC-010) Harden parse_chunked_body in the inference interception path: - Replace all unchecked +2 additions with checked_add for consistent overflow safety across all target architectures - Add MAX_CHUNKED_BODY (10 MiB) to cap decoded body size - Add MAX_CHUNK_COUNT (4096) to prevent CPU exhaustion via tiny chunks - Early-reject chunk sizes larger than remaining buffer space * fix(cli): double-escape command for SSH path, validate host and name (SEC-004) Harden doctor_exec against command injection in the SSH remote path: - Apply shell_escape to inner_cmd in the SSH path so it survives the double shell interpretation (SSH remote shell + sh -lc). This also fixes a correctness bug where multi-word commands were silently broken in the SSH path. - Add validate_gateway_name to reject shell metacharacters in gateway names before use in container_name - Add validate_ssh_host to reject metacharacters in remote_host loaded from metadata.json * fix(sandbox): add CIDR breadth warning and control-plane port blocklist (SEC-005) Defense-in-depth for the allowed_ips feature: - Log a warning when a CIDR entry has a prefix length < /16, as overly broad ranges may unintentionally expose control-plane services - Block K8s API (6443), etcd (2379/2380), and kubelet (10250/10255) ports unconditionally in resolve_and_check_allowed_ips, even when the resolved IP matches an allowed_ips entry * test(e2e): update assertion for sanitized inference error message (SEC-008) The SEC-008 fix changed the error message from 'no compatible route for source protocol ...' to 'no compatible inference route available'. Update the E2E assertion substring to match.
OpenShell
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. The project ships with agent skills for everything from cluster debugging to policy generation, and we expect contributors to use them.
Alpha software — single-player mode. OpenShell is proof-of-life: one developer, one environment, one gateway. We are building toward multi-tenant enterprise deployments, but the starting point is getting your own environment up and running. Expect rough edges. Bring your agent.
Quickstart
Prerequisites
- Docker — Docker Desktop (or a Docker daemon) must be running.
Install
Binary (recommended):
curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh
From PyPI (requires uv):
uv tool install -U openshell
Both methods install the latest stable release by default. To install a specific version, set OPENSHELL_VERSION (binary) or pin the version with uv tool install openshell==<version>. A dev release is also available that tracks the latest commit on main.
Create a sandbox
openshell sandbox create -- claude # or opencode, codex, copilot
A gateway is created automatically on first use. To deploy on a remote host instead, pass --remote user@host to the create command.
The sandbox container includes the following tools by default:
| Category | Tools |
|---|---|
| Agent | claude, opencode, codex, copilot |
| Language | python (3.13), 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:
- Allows — the destination and binary match a policy block.
- Routes for inference — strips caller credentials, injects backend credentials, and forwards to the managed model.
- Denies — blocks the request and logs it.
| 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. |
| Privacy Router | Privacy-aware LLM routing that keeps sensitive context on sandbox compute. |
Under the hood, all these components run as a K3s Kubernetes cluster inside a single Docker container — no separate K8s install required. The openshell gateway commands take care of provisioning the container and cluster.
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. |
| Inference | Reroutes model API calls to controlled backends. | Hot-reloadable at runtime. |
Policies are declarative YAML files. Static sections (filesystem, process) are locked at creation; dynamic sections (network, inference) can be hot-reloaded on a running sandbox with openshell policy set.
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.
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
The CLI auto-bootstraps a GPU-enabled gateway on first use. GPU intent is also inferred automatically for community images with gpu in the name.
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 | Community | Launch with openshell sandbox create --from openclaw. |
| Ollama | Community | Launch with openshell sandbox create --from ollama. |
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 policy set <name> --policy file.yaml |
Apply or update a policy on a running sandbox. |
openshell policy get <name> |
Show the active policy. |
openshell inference set --provider <p> --model <m> |
Configure the inference.local endpoint. |
openshell logs [name] --tail |
Stream sandbox logs. |
openshell term |
Launch the real-time terminal UI for debugging. |
See the full CLI reference for all commands, flags, and environment variables.
Terminal UI
OpenShell includes a real-time terminal dashboard for monitoring gateways, sandboxes, and providers — inspired by k9s.
openshell term
The TUI gives you a live, keyboard-driven view of your cluster. Navigate with Tab to switch panels, j/k to move through lists, Enter to select, and : for command mode. Cluster health and sandbox status auto-refresh every two seconds.
Community Sandboxes and BYOC
Use --from to create sandboxes from the OpenShell Community catalog, a local directory, or a container image:
openshell sandbox create --from openclaw # community catalog
openshell sandbox create --from ./my-sandbox-dir # local Dockerfile
openshell sandbox create --from registry.io/img:v1 # container image
See the community sandboxes catalog and the BYOC example for details.
Explore with Your Agent
Clone the repo and point your coding agent at it. The project includes agent skills that can answer questions, walk you through workflows, and diagnose problems — no issue filing required.
git clone https://github.com/NVIDIA/OpenShell.git # or git@github.com:NVIDIA/OpenShell.git
cd OpenShell
# Point your agent here — it will discover the skills in .agents/skills/ automatically
Your agent can load skills for CLI usage (openshell-cli), cluster troubleshooting (debug-openshell-cluster), inference troubleshooting (debug-inference), policy generation (generate-sandbox-policy), and more. See CONTRIBUTING.md for the full skills table.
Built With Agents
OpenShell is developed using the same agent-driven workflows it enables. The .agents/skills/ directory contains workflow automation that powers the project's development cycle:
- Spike and build: Investigate a problem with
create-spike, then implement it withbuild-from-issueonce a human approves. - Triage and route: Community issues are assessed with
triage-issue, classified, and routed into the spike-build pipeline. - Security review:
review-security-issueproduces a severity assessment and remediation plan.fix-security-issueimplements it. - Policy authoring:
generate-sandbox-policycreates YAML policies from plain-language requirements or API documentation.
All implementation work is human-gated — agents propose plans, humans approve, agents build. See AGENTS.md for the full workflow chain documentation.
Getting Help
- Questions and discussion: GitHub Discussions
- Bug reports: GitHub Issues — use the bug report template
- Security vulnerabilities: See SECURITY.md — do not use GitHub Issues
- Agent-assisted help: Clone the repo and use the agent skills in
.agents/skills/for self-service diagnostics
Learn More
- Full Documentation — overview, architecture, tutorials, and reference
- Quickstart — detailed install and first sandbox walkthrough
- GitHub Sandbox Tutorial — end-to-end scoped GitHub repo access
- Architecture — detailed architecture docs and design decisions
- Support Matrix — platforms, versions, and kernel requirements
- Brev Launchable — try OpenShell on cloud compute without local setup
- Agent Instructions — system prompt and workflow documentation for agent contributors
Contributing
OpenShell is built agent-first — your agent is your first collaborator. Before opening issues or submitting code, point your agent at the repo and let it use the skills in .agents/skills/ to investigate, diagnose, and prototype. See CONTRIBUTING.md for the full agent skills table, contribution workflow, and development setup.
License
This project is licensed under the Apache License 2.0.
