Getting Started with NVIDIA OpenShell: Installation, First Agent, and Where BlueField Sentry Fits

Bottom line: NVIDIA’s OpenShell README installs a CLI and an empty Ubuntu sandbox in two commands. Running your first agent is covered in a separate guide, and BlueField Sentry is a hardware-backed component of the same launch, not the next install step on a laptop.

The install block in NVIDIA’s OpenShell README is two lines. The sandbox it creates does not contain an agent. The hardware watchdog in the Sept. 29 launch post is not the next line of that install. If you mix those three facts, you will either think you are done when you have an empty Ubuntu box, or you will wait on a BlueField card you do not need to try the software.

This guide is based on the README on the main branch and the two docs it points to, Run Your First Agent and the first network-policy tutorial. Launch context comes from NVIDIA’s newsroom post from Sept. 29, StorageReview’s writeup, and Salesforce’s Slack bridge note from Sept. 28. The commands below are the ones those pages print.

This is a control layer, not a new model. We already wrote JetBrains Air as a control layer rather than a model. We wrote Claude Code pointed at a local Ollama runtime and Antigravity’s SDK running Gemma 4 on your GPU. OpenShell does not replace those. The README’s own description is that agents are useful when they can read files, install packages, call APIs, and use credentials, and that OpenShell is the thing that stops that from being unrestricted access. You declare what each agent can touch. It enforces the declaration.

Install OpenShell, then notice the sandbox is empty

The README’s support line is short. You need Linux, macOS on Apple Silicon, or Windows with WSL 2, and the WSL path is marked experimental. You also need Docker, Podman, or host virtualization for MicroVM-backed sandboxes. The detail lives on the support matrix.

The install they print is a remote script:

curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh
openshell sandbox create --name demo

That is the documented path. The README does not print a checksum next to it. Read the script if you care what it writes. The page says the installer sets up the CLI and a local gateway. The default sandbox image is minimal Ubuntu with no agent installed. openshell sandbox create --name demo gives you a named box. It does not give you Claude, OpenCode, or Hermes inside it.

The banner on that same README says what is new in OpenShell 0.1.x: a stable release cadence, new isolation primitives, an expanded extension surface, and new APIs. The upgrade notes are a separate page, the 0.1.0 upgrade guide. If you already had a prerelease checkout, that page is the one that tells you what moved. The two-line install is for a machine that does not have it yet.

StorageReview’s account of the same software is the availability sentence the README does not bother with. OpenShell showed up in the NemoClaw reference stack at GTC 2026, then in Dell, HPE, and SUSE AI Factory stacks. NVIDIA now calls it broadly available. The code is on GitHub under Apache 2.0. “Broadly available” and “the default image has no agent” can both be true. Available means you can install the runtime. Empty means you still have to put a process in it.

The first agent is a second document

Run Your First Agent is where the empty box gets a process. The page’s frame is: configure what the agent may use, choose an image that already contains the agent, create the sandbox with the agent command after --.

The credential step, as the doc prints it, is a provider named openrouter:

openshell provider create \
  --name openrouter \
  --type openrouter \
  --from-existing

Set OPENROUTER_API_KEY before you create that provider. OpenShell stores the value in its credential store and sends it only to openrouter.ai. The key does not go into the sandbox as a file the agent can cat. The page also has openshell profile import --url ahead of the provider create. Copy the import line from the doc page, not from this article.

The create line the doc prints is specific:

openshell sandbox create \
  --name my-agent \
  --from ghcr.io/anomalyco/opencode:latest \
  --provider openrouter \
  -- opencode -m openrouter/nvidia/nemotron-3.5-lightning:free

Everything after -- is the process inside the sandbox. --from is the image. The doc says that image installs opencode at /usr/local/bin/opencode, and that the example profile allows that binary to reach openrouter.ai. OpenCode picks up the OpenRouter credential and starts on the model you passed to -m. The model in the example is marked free, so it does not need OpenRouter credits. opencode models openrouter is how the page says you list other models. If the pull fails, the failure is the tag, not a sign that the two-line README install was wrong.

A custom policy is the page’s answer when the agent needs more than that profile: filesystem paths, package registries, source hosts, tool servers. The README’s mechanism section is the reason that answer exists. Kernel controls confine files and system calls. Every network connection passes a policy check before it leaves the sandbox. Credentials are added only to requests bound for approved endpoints. Before a policy change is applied, formal verification is supposed to flag risky new access, such as a new host reached with credentials or a new API method, and hold it for a person.

A network policy you can read, and the 403 that means it worked

The first network-policy tutorial is the page that shows the deny, which is the only way to tell a policy from a comment. A denied curl in that walkthrough comes back as HTTP 403 from the proxy after CONNECT. The tutorial tells you to leave the sandbox shell open and run the next openshell commands on the host. Exiting the shell stops the sandbox’s main process. With the default restart policy, you cannot reconnect after that. --no-keep at create time deletes the sandbox when you exit.

The rule the tutorial adds is this YAML, in the policy’s network_policies section:

network_policies:
  github_api:
    endpoints:
      - host: api.github.com
        port: 443
        protocol: rest
        enforcement: enforce
        access: read-only
    binaries:
      - path: /usr/bin/curl

rest means the proxy terminates TLS and inspects each HTTP request. read-only permits GET, HEAD, and OPTIONS. enforce blocks everything else. The tutorial says policy update changes only the network rules and leaves the rest of the sandbox policy alone. To see the whole thing, openshell policy get demo --base. Denied connections land in a structured log: openshell logs demo --since 5m --source sandbox, run on the host, not in the sandbox.

If you want the log without the block, the same page says set enforcement: audit instead of enforce. Deploy in audit, read what would have been denied, then switch to enforce. That is the iteration loop. It is also the loop that will annoy you if you skip audit on a policy you copied from a blog, including this one. The GitHub rule above allows one binary to read one host. It does not allow your agent to git push. If the agent needs that, the tutorial’s answer is another rule, not a disabled proxy.

Cleanup is openshell sandbox delete demo. The page says that stops processes and purges injected credentials. There is a non-interactive path, bash examples/sandbox-policy-quickstart/demo.sh, which assumes you are in a checkout that has that example. The README install does not say it drops that script on your PATH. If the script is missing, you are on the install path, not the git checkout. Use the commands, not a path you do not have.

Sentry is the other half of the launch, and it is not this laptop

NVIDIA’s Sept. 29 newsroom post names a platform, not a command. Open Agent Safety Platform is OpenShell plus Sentry, a reference design. OpenShell is the software boundary: it traces actions and enforces policy as agents run on NVIDIA Vera CPUs, and the post says the open-source runtime can be extended to Arm and Intel as well. Sentry is an out-of-band watchdog on BlueField-4 DPUs. If an agent leaves the software boundary, Sentry quarantines it in milliseconds. The post calls that in-silicon enforcement, from a trust domain the agent cannot see.

In Vera Rubin POD systems, the BlueField-4 sits on the node’s only path to the model, which is what lets Sentry watch and enforce at line speed without the host’s cooperation. Sentry is built on DOCA. The newsroom says DOCA is what it uses to inspect requests and responses, provide attested telemetry, verify agent identity, and enforce zero-trust rules for data, tools, APIs, and services. None of that is in install.sh. If your machine does not have a BlueField-4, you still have the sandbox and the policy. You do not have the out-of-band watchdog. Writing a tutorial that tells a laptop user to “enable Sentry” would be fiction.

Anthropic is in the newsroom post as a collaboration, not as a model you apt-get. Claude Managed Agents run the agent loop on a separate server from the sandboxes where the work executes. Integrations with OpenShell and BlueField are how an enterprise would put a boundary on those sandboxes. That is a deployment shape.

Salesforce’s Sept. 28 post is the human side of the same boundary, if you are already in that stack. When an agent in OpenShell needs something outside the current network policy, the Slack Admin Bridge puts an approval card in Slack. Credentials stay outside Slack. The bridge is scoped to send audit events and ingest approvals. Salesforce says no message, channel, or user data flows out of Slack. It matters because the README’s “hold risky policy changes for a person” needs a person, and this is one vendor’s place to put that person. Your place might be the terminal you already have open.

The switches that are easy to miss

Telemetry is on unless you turn it off. The README says OpenShell collects anonymous telemetry, limited to operational categories and counts. It does not collect sandbox names, hostnames, file paths, prompts, credentials, provider or model names, or user content. To disable it, set OPENSHELL_TELEMETRY_ENABLED=false on the gateway, or server.telemetryEnabled=false for Helm. You can also compile it out.

The skills install is a different command from the runtime install: npx skills add NVIDIA/OpenShell. The README says those skills teach an agent to drive the CLI, write policies, and debug gateways, and that they work without a source checkout. Installing the skill does not create the sandbox. Creating the sandbox does not install the skill.

SDKs do not install the CLI either. Python is uv add openshell. TypeScript is npm install @nvidia/openshell-sdk, from GitHub Packages, not from the public npm registry unless that has changed since the README. Go is go get github.com/NVIDIA/OpenShell/sdk/go@latest. Rust wants a release tag in cargo add. The README’s warning is to use the same OpenShell release for the SDK and the gateway. A newer SDK against an older gateway is the kind of mismatch these tables exist to prevent, and the page does not promise it will fail loudly.

Kubernetes is marked as its own path: deploy the gateway with Helm, and the CNI must enforce NetworkPolicy. The tutorial’s proxy deny does not survive a cluster network that ignores network policy. If you are still on the laptop quickstart, you are not on this path. Do not start with Helm because the launch post said “platform.”

Security reports go to SECURITY.md. The README says not to open a GitHub issue for a vulnerability.

Recommended order of steps

On a Linux host that already has Docker or Podman, the order the docs support is the two-line install, then the provider create after the key is in the environment, then the profile import copied from the first-agent page, then the OpenCode sandbox create, then a policy you can see fail. The 403 is the success condition for the policy half. An agent that answers a prompt is the success condition for the other half. They are different tests.

The doc printed it as the example that does not need credits. Examples rot.

The useful split is the one the pages already made and the launch post blurred. OpenShell is a runtime you can install, with an empty default image, a policy language, and a credential store that is supposed to inject keys only toward approved hosts. Sentry is a DPU watchdog for a specific NVIDIA system design. The Slack bridge is an approval inbox for people who live in Slack. Install the first. Read the second before you put it in a budget. Ignore the third until an agent actually hits a wall your policy meant to build.

What this means for you

A practical path: install the CLI, follow the official first-agent tutorial, then apply the sample network policy and confirm that blocked requests return 403. Evaluate Sentry separately only if you run BlueField-equipped infrastructure.