NVIDIA OpenShell

What NVIDIA OpenShell Actually Does

OpenShell is an open-source runtime, the environment that runs an agent and controls its access. It sits underneath your agent rather than replacing the agent's reasoning or tools.

Think of a contractor working inside a building. You give them a workshop, access to particular rooms and permission to call particular suppliers. You do not hand over the master key because the job description says “be careful.” OpenShell supplies those boundaries for software agents.

Its runtime overview describes filesystem restrictions, network controls, process restrictions and protected provider credentials. Landlock is the Linux kernel mechanism that limits file access; seccomp restricts system calls, the low-level requests a program makes to the operating system. Enforcement lives outside the agent's reasoning.

The gateway manages sandboxes and access. A supervisor outside the sandbox checks outbound requests against policy and supplies credentials where permitted. The policy prover checks modeled permissions against defined boundaries. These are controls over what an agent may do, not a guarantee that its permitted work is correct.

NVIDIA lists paths for Claude Code, Codex, GitHub Copilot CLI, Hermes, LangChain Deep Agents, OpenClaw and OpenCode, alongside custom agents and images. “Supported” does not mean every tool comes preinstalled: the current default workload is a minimal Ubuntu image without agent CLIs, the command-line programs you use to launch agents.

The business change is permission reuse. Without a reusable boundary, each new agent workflow can trigger another round of deciding what files, secrets and services to expose. With one, the team can package those decisions with the workload and review changes. Measure the effect in engineer hours spent on access setup and interruptions; there is no verified universal time-saving figure to borrow.

Where It Runs Now

Use the current support matrix to choose a host. This walkthrough follows the documentation labeled v0.1.7, checked on November 8, 2026.

WSL 2 runs a Linux environment on Windows. MXC is a separate native Windows isolation path. Do not treat “Windows support” as one interchangeable installation route.

The Windows collaboration announcement describes bringing OpenShell to Windows through MXC. That platform direction does not make the native path a normal stable installer today. The current installation docs explicitly say the standard release channels do not supply native Windows binaries.

For a first evaluation, choose a supported Linux or Apple Silicon setup. The support matrix also specifies kernel and runtime requirements: Linux 6.2 introduced the required Landlock ABI, but kernel version alone is insufficient. The runtime must pass the required checks. On the macOS Docker Desktop path, those Linux facilities run inside its Linux virtual machine. NVIDIA Vera CPUs are not required.

Install the CLI and Run Your First Agent

Start with NVIDIA's documented OpenCode example. It makes the three ingredients visible: a provider for service access, an image containing the agent, and a sandbox to run it. These are documentation-based steps, not a claim of a local test.

1. Prepare the host and install OpenShell. For the Docker route, have Docker Desktop running or Docker Engine 28.0 or later. On supported Linux or macOS, the installation guide uses curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh. Review the installer before executing it. It installs the CLI, policy prover and local gateway. Run openshell status to confirm the CLI reaches the gateway.

2. Configure the model service. The example uses OpenRouter. Set your OPENROUTER_API_KEY in the host environment before creating the provider. A provider profile describes allowed service endpoints and executable paths; the provider stores the credentials. NVIDIA's example profile permits /usr/local/bin/opencode to reach openrouter.ai.

3. Import the profile, create the provider and launch the image. Run these commands on the host, in order:

openshell profile import \
  --url https://raw.githubusercontent.com/NVIDIA/OpenShell/main/providers/openrouter.yaml
openshell provider create \
  --name openrouter --type openrouter --from-existing
openshell sandbox create \
  --name my-agent \
  --from ghcr.io/anomalyco/opencode:latest \
  --provider openrouter \
  -- opencode -m openrouter/nvidia/nemotron-3.5-lightning:free

The image supplies OpenCode; the command after -- starts it as the main process. The first-agent walkthrough uses this free model without requiring OpenRouter credits. That is the example's model choice, not a promise that arbitrary model usage costs nothing.

4. Review access requests from the host. When an agent tries an unapproved destination, OpenShell denies the request and drafts a narrow rule proposal. Run openshell rule get my-agent --status pending. If a proposal matches the job's intended access, approve that specific proposal with openshell rule approve my-agent --chunk-id <chunk-id>, replacing the placeholder with its actual ID. The rule reloads and the agent can retry.

5. Inspect the permissions you actually granted. Run openshell policy get my-agent --base, then openshell policy get my-agent --full. The first shows the base policy; the second includes provider-contributed rules. Review the effective permissions before adding a real project or sensitive service.

When finished with a disposable evaluation, delete it with openshell sandbox delete my-agent.

Which Policies Change Live?

Network access can change during a task. Filesystem and process boundaries require a newly created sandbox.

“Live” still has consequences. New network rules close connections opened under the previous rules, so clients must reconnect. Registering a new external middleware service needs gateway configuration and a gateway restart. Adding a filesystem path to saved policy does not grant it to the already-running workload; removing paths or changing startup settings is rejected after startup. The policy management guide spells out these differences.

One more trap: no policy file does not mean no access. A policy may come from the image, an environment setting or a gateway-wide policy. Attached providers can add network rules. The policy selection rules also make clear that a global policy replaces the sandbox's own policy; it is not simply an extra restrictive layer.

A Coding-Agent Policy You Can Reason About

Give a bug-fixing agent a writable project directory and read-only API access before giving it permission to publish changes.

Here is an illustrative policy for a prepared coding image with the project at /workspace and curl installed at /usr/bin/curl. Save it as policy.yaml and pass --policy ./policy.yaml when creating a new sandbox. This is a template for that image layout, not a drop-in replacement for every agent image:

version: 1
filesystem_policy:
  include_workdir: false
  read_only: [/usr, /lib, /etc]
  read_write: [/workspace, /tmp]
landlock:
  compatibility: hard_requirement
network_policies:
  github_readonly:
    endpoints:
      - host: api.github.com
        port: 443
        protocol: rest
        enforcement: enforce
        access: read-only
    binaries:
      - path: /usr/bin/curl

The agent can edit the project and temporary files. The network rule permits the named executable to make GET, HEAD and OPTIONS requests to the GitHub API. It does not grant arbitrary programs internet access, authorize package downloads or provide Git push access. The model provider is configured separately.

Prepare any writable agent state directories the image needs and add them deliberately. These paths refer to the sandbox's filesystem. Do not infer that a similarly named host directory is automatically available. Also, baseline filesystem paths are added for network-capable workloads, so the short YAML is not a claim that only its listed paths exist in the effective boundary.

Two settings deserve attention. hard_requirement stops startup if the user filesystem rules cannot be enforced, though individual missing or inaccessible paths can still be skipped. enforcement: enforce blocks disallowed inspected requests; the schema's default audit mode logs violations and allows those requests. See the policy schema reference before adapting the template.

Test both permission and refusal. NVIDIA's network-policy tutorial checks that curl -s https://api.github.com/zen succeeds under the read-only rule, then verifies that a POST is denied. Inspect openshell logs my-agent --since 5m --source sandbox from the host. For your project, also test an intended file write and an out-of-scope file access. A successful agent launch is not the acceptance test for a security policy.

Five Workflows Worth Trying First

The best early uses have a clear job boundary and a human who can judge the output. Ranked by likely operational value:

None of these makes generated code correct or an incident diagnosis reliable. The value is narrowing what can happen while the agent works. For broader tool selection, use Best AI Sandbox Security Tools 2026; for execution-platform choices, use Best AI Agent Code Sandboxes 2026.

Two Things Worth Building Around It

The strongest opportunity is a team coding-agent onboarding kit. The buyer is a platform lead who wants developers productive inside an approved environment. DataForSEO estimates 1,300 monthly searches for “claude code sandbox” in the market returned by this run's query. That is evidence of setup interest, not 1,300 prospective customers, and some searchers want the agent's own sandbox rather than OpenShell.

The smallest sellable version could support one agent and one approved host configuration: a prepared image, a reviewed policy, a provider setup checklist and repeatable allow/deny tests. Sell a working team rollout, with clear ownership of updates. The catch is maintenance: image paths, agent behavior and experimental interfaces can change. Interview platform leads about that maintenance burden before building a hosted product.

A policy-review workbench is the second opportunity. Security teams could use it to see what an effective policy permits, compare changes and record approvals. DataForSEO estimates 480 monthly searches for “ai agent security”, with 70 for “ai agent security tools.” Those separate queries are broad demand signals; do not add them together as unique buyers.

An MVP could import base and effective policies, highlight added destinations and request permissions, and attach test results to a review record. The catch is differentiation: OpenShell already has policy analysis, proposals and logs. The product needs to improve the team's review process, rather than wrap existing commands in a dashboard. Start with the onboarding kit because its buyer and deliverable are easier to define.

What It Does Not Solve

OpenShell limits access; it does not decide whether an allowed action is a good business decision. An agent allowed to write project files can still write a bad patch. An approved external destination can still receive data your policy permits it to receive. File access and endpoint approval must reflect what you actually intend to expose.

It also does not replace identity systems, secret stores, monitoring or governance. NVIDIA's runtime-controls announcement positions enforcement outside the agent workload. Treat that as one part of the surrounding system, not a reason to discard the rest.

The project now has stable releases intended for production within its support matrix, so calling all of OpenShell an experimental demo would be misleading. The limits are more specific: experimental interfaces can change in patch releases, native Windows remains under development, and NVIDIA says its current qualification profile does not cover the entire release-qualification policy. Pin what you deploy and validate the exact workload and host combination.

Monday move: have your platform lead pick one non-sensitive repository and one agent. Install on a supported host, prepare the image, define file and network access, then test an allowed operation and a blocked one. Record setup time and engineer hours spent handling interruptions across the first week. Expand only after the team can explain every granted permission.

If you want this built into your team's workflow, we can help put the production controls in place.