OpenShell by NVIDIA: Sandbox for AI Agents Explained
Oct 23, 202611 min read
OpenShell is a new open-source project from NVIDIA, published on GitHub as NVIDIA/OpenShell. It's early: the repository was read on 2026-10-23.
Anyone who wires it into a workflow, whether through a hand-built script or an automation tool such as Activepieces, should ask first who owns it when it breaks.
When read, the repository page was a file listing with no README text. NVIDIA's own description of the project is therefore not available to quote here.
Anything beyond the name, the host and the facts below would be inference, so this article treats it that way.
The repository sits under NVIDIA's GitHub organisation, and commits carry NVIDIA addresses. The card below shows what the page states.
OpenShell is NVIDIA's new project, released on GitHub
A commit dated the day of reading means the project is moving and this card ages quickly.
| Item | Fact | Source |
|---|---|---|
| Maker | NVIDIA | GitHub |
| Repository | NVIDIA/OpenShell | GitHub |
| License | Apache 2.0 | GitHub |
| Latest version | — | GitHub |
| Latest commit | Oct 23 2026 | GitHub |
| OS | — | GitHub |
Prices and plan limits checked against github.com and docs.claude.com and claude.com and openai.com and gemini.google on October 23, 2026.
Hosting, engineering time and upkeep still cost money, and nobody has measured them.
The platform line means a Windows or Arm-based server is outside what the maker states. Teams building automations in tools such as Activepieces should pin a version and name an owner before trusting it.
Hosting, engineering time and upkeep still cost money, and nobody has measured them.
Everything below works on Activepieces' free plan. Start without code or a credit card.
What OpenShell means for automation teams
OpenShell matters because it puts a boundary around the agent, and a boundary is something a named owner can be held to when the 2am page arrives.
The repository states three things that bear on any automation touching business systems:
- Agents run inside sandboxes.
- Each sandbox has its own policy.
- Each sandbox has its own provider credentials.
Taken together, a misbehaving run touches only one sandbox's policy and keys, so the post-incident question is "which sandbox, and who set its policy?" rather than "which shared secret leaked?" That's the repository's stated design. Nobody here has tested how well it holds.
Three terms carry that argument, and the repository's README was empty, so what follows are the generic meanings, not NVIDIA's definitions. A sandbox is an isolated environment where an agent's code and tool calls run, apart from the host machine.
A policy typically limits what that sandbox can reach: which files it can read or write, which network addresses it can call, and which tools it can use.
Provider credentials are the model or API keys the agent uses to do its work. Giving each sandbox its own keys limits the damage if one leaks, because the other sandboxes keep working and only one key needs revoking.
The three other repositories named below are, in one line each, as follows. NeMo Guardrails is an NVIDIA toolkit for putting rules around what a language model says and does. Agent-infra sandbox is a project that provides sandbox environments for running agents.
K8s agent-sandbox is a Kubernetes-oriented project for running agents in isolated sandboxes.
OpenShell GitHub stars compared with similar projects
18,409 stars is what GitHub shows for OpenShell, against 7,355 for NeMo Guardrails, 6,194 for agent-infra sandbox and 4,362 for K8s agent-sandbox.
That's about two and a half times the next repo, so more people are looking at it and someone has more likely already asked your question.
Don't read quality, speed or cost into that number. Stars measure attention, and they say nothing about any of the three.
Before adopting it, a team needs answers to these:
- Who owns each sandbox's policy, and who approves changes to it?
- Who rotates the provider credentials, and how often?
- Which version do you pin, and who decides when it moves?
If any of those answers is "nobody yet", the sandbox isn't ready for production work.
What's measurably new in OpenShell
You can hold NVIDIA only to what's on its GitHub page. That page states per-sandbox policies and credentials, an Apache 2.0 license, and repository activity counts.
Capabilities NVIDIA lists
The table gives each stated fact with its source and the check date. Read the right-hand column as the limit of what this article asserts.
| Stated fact | Source link | Checked |
|---|---|---|
| Per-sandbox policies and credentials | NVIDIA OpenShell on GitHub | 2026-10-23 |
| Apache 2.0 license | NVIDIA OpenShell on GitHub | 2026-10-23 |
| Version v0.1.5 | NVIDIA OpenShell on GitHub | 2026-10-23 |
| 1,855 commits, 517 branches, 159 tags | NVIDIA OpenShell on GitHub | 2026-10-23 |
| Linux x86_64 | NVIDIA OpenShell on GitHub | 2026-10-23 |
Someone on your team must own pinning and re-testing each upgrade, because the project is moving quickly. The commit, branch and tag counts show the repository is active, but they say nothing about reliability, so they're no reason to skip your own testing.
What the page doesn't say
Although the page lists per-sandbox credentials, as checked it gives no cost figures, no latency or throughput numbers, and no benchmark against other sandboxes. This article states none of those because nobody involved in it has measured them.
Until someone does, a claim that OpenShell is cheaper or faster is a guess, and the person paged at 2am shouldn't inherit a guess.
Easier to see it running than to read about it: set it up free, no card.
How to connect OpenShell in an Activepieces workflow today
Every route is general-purpose glue, and whoever builds the glue is the one paged when it breaks.
We haven't run OpenShell ourselves, so each route below is a plan drawn from how the building blocks work, not a tested result.
Option 1: an HTTP request step
This is the simplest route. Add the built-in HTTP request step, set the method and URL to whatever endpoint OpenShell's own documentation publishes, and add the authentication header it requires.
Store any credential in a connection, not in the step body, so rotating it doesn't mean editing the flow.
Because we haven't run it, confirm the request and response shape against the maker's documentation before trusting the output downstream. Name an owner for that step.
Option 2: an AI step with an OpenAI-compatible provider
If OpenShell exposes an interface that follows the OpenAI request format, you can point the AI step at it as a custom provider. Set the base URL, the API key and the model name the maker documents.
The risk is the word "if": compatibility is a claim to check, not assume, and we haven't tested it. Run one known input through it and read the raw reply before wiring in anything that acts on it.
Option 3: an MCP server
The Model Context Protocol (MCP) lets an AI agent call external tools through a standard interface. This route fits only if OpenShell, or a wrapper someone maintains, speaks MCP.
Once a piece is connected in Activepieces, an agent can call it: the same piece action runs as a step in a flow and as a tool on the project's MCP server, open to Claude, ChatGPT, Cursor or an agent you built.
Nothing is published to a second catalog and nothing is registered twice, so a wrapped OpenShell step doesn't need re-integrating for agents. You can read the shared action in packages/pieces in the MIT-licensed repo, and MoneyGram, Moneypenny, Alan and FundingSocieties run Activepieces in production.
Wrapping OpenShell takes the most setup, we haven't run it, and someone still has to own the wrapper.
What OpenShell means for cost and speed
Nobody can yet say whether OpenShell is cheaper or faster than the alternatives, because NVIDIA has published no cost-per-task or speed figures.
That matters most to whoever owns the wrapper: a budget line or a latency promise built on a guess becomes their problem the first time the bill or the timeout arrives.
Look at what each option publishes in the table below. The takeaway is that only the OpenShell cost cell has a fact in it, and that fact concerns licensing, not running cost.
| Option | Cost per task | Speed | Source |
|---|---|---|---|
| OpenShell | — | Not published | NVIDIA's project repository |
| Hosted model APIs | Set by each vendor's price list | Set by each vendor's service | Each vendor's own model page |
| Self-managed setups | Depends on your hardware and staffing | Depends on your hardware and configuration | Your own measurements |
You get a reason to measure from this table, not a ranking. Until someone runs the same task through each row, you can't compare any cell with another.
The one firm cost fact is that NVIDIA released OpenShell under the Apache 2.0 license and anyone can download it free from GitHub. That means there's no license fee to approve.
But it says nothing about the compute, storage and staff time needed to run it, which is where a per-task cost would come from.
Speed: what is not yet published
NVIDIA has published no speed measurements, so any latency claim you hear has no source.
The evidence that would settle it is a like-for-like run: the same task, the same inputs, timed and costed on OpenShell, on a hosted model API, and on a self-managed setup, with the person who'll be paged if the numbers are wrong writing the results down.
What to watch next as OpenShell develops
Before anyone quotes a cost or speed claim, read the repository. A like-for-like run needs inputs, and that's where they'll either appear or visibly fail to.
NVIDIA's published description is the firm part: it says what the project is meant to do, and a team can wire it into automations with ordinary building blocks today. It doesn't say who answers when the thing misbehaves at 2am.
For an early project, that owner is you, so the repository's activity is your only view of how much support to expect.
The checklist below shows how fast the project is moving and what other users have already hit, which tells you whether to put a pager behind it:
- Releases after v0.1.5, and what each changed
- Documentation changes, especially to anything you rely on
- Open issues, and whether maintainers answer them
- Published benchmarks, and who ran them
- The inputs for your own cost-per-task and latency test: task, data, hardware and model choice
A project that ships often but leaves issues unanswered is a different risk from a quiet one.
No benchmark, no price per task and no latency figure appears on the page. Any such number you meet elsewhere has no source until someone shows the method.
On Monday morning:
- Name one person who owns the OpenShell trial.
- Record the version you tested against.
- Pick one real task and freeze its inputs.
- Run it on all three setups and write down the results.
Frequently asked questions
Is OpenShell free to use?
Yes, as far as the license goes: the repository states Apache 2.0, so there's no license fee. What it doesn't settle is the cost of running it, since hosting, engineering time and upkeep are unmeasured.
Treat running cost as unknown, because an automation built on an assumed price leaves whoever owns it explaining a bill nobody planned for.
How to wire OpenShell into automations?
Nothing confirms native support. This article establishes only that you can wire OpenShell into automations through ordinary building blocks, such as a command step or a web request.
Treat that as an integration your team builds and maintains, not a feature a vendor supports. If it breaks at 2am, the page goes to your team, not to a vendor's support queue.
Where can I download OpenShell?
From NVIDIA's own repository at github.com/NVIDIA/OpenShell, and only there. It's released under Apache 2.0, and the page names Linux Debian/Ubuntu x86_64 as the platform.
A copy from a mirror or a third-party repackaging has no maker behind it, which matters if you later need to show where the software came from.
Has OpenShell been benchmarked against other options?
Not by anyone writing here, and no independent comparison is cited. Any claim about speed or cost savings is therefore unsupported for now. Treat such claims as hypotheses to test on your own workload, and have someone named as owner record the results.
