TL;DR: NVIDIA OpenShell (Apache 2.0, alpha, v0.0.106 as of August 14, 2026) runs autonomous agents like Claude Code and Codex inside policy-enforced sandboxes, and its inference.local routing can force every model call to your own GPU instead of a cloud API. The Windows catch: despite the “agents on your PC” framing, it runs on Windows only through WSL 2, and that path is officially experimental. Native Windows support is an unreviewed community RFC, not a roadmap item.

	OpenShell on Windows (WSL2)	OpenShell on Linux	Agent Safehouse (macOS)
Best for	RTX owners who live on Windows	The supported, boring path	Mac-only agent users
Price / Cost	Free (Apache 2.0) + your GPU	Free (Apache 2.0)	Free (open source)
The catch	”Experimental” is NVIDIA’s word, not ours; GPU passthrough needs extra setup	Alpha software either way — daily releases, breaking changes expected	No NVIDIA GPU, no inference.local-style routing

Honest take: if you already run local models on a Windows RTX box, OpenShell inside WSL2 is worth an afternoon — the deny-first network policy plus local-only inference is a genuinely new combination. But treat it like the v0.0.x alpha it is: run it for containment and privacy, don’t build your workflow on it yet.

NVIDIA shipped OpenShell into the spotlight during the same “Month of Local AI” push (started August 11, 2026) that gave us Nemotron 3.5 Lightning and Meta’s Muse Glimmer 30B. The models got the headlines. OpenShell is the piece that answers the question the models raise: once an always-on agent can read your files, run shell commands, and call tools for hours unattended, what stops it from doing something you didn’t ask for?

The July sandbox escapes made that question concrete — we covered the macOS answer in our Agent Safehouse guide. OpenShell is NVIDIA’s cross-platform answer, and it has one feature no other agent sandbox ships: inference routing that can make “my agent never talks to a cloud API” an enforced policy instead of a hope.

What OpenShell actually is

The GitHub repository describes it as “the safe, private runtime for autonomous AI agents,” and the architecture is more specific than the tagline: agents execute inside sandboxes (Docker, Podman, MicroVM, or Kubernetes as the compute backend) while a gateway process enforces declarative YAML policies across four layers — filesystem, network, process, and inference. Every allow and deny decision lands in an audit trail.

The parts that matter for a home lab:

• License and status. Apache 2.0, explicitly alpha. The release cadence tells you how alpha: v0.0.97 shipped August 3, v0.0.106 on August 14 — ten releases in twelve days. NVIDIA’s own docs call the current scope “single-player mode”: one developer, one environment, one gateway. Community traction is real, though — 8.2k GitHub stars and 1.2k forks as of mid-August 2026.
• Agents run unmodified. Claude Code (via ANTHROPIC_API_KEY), OpenCode, Codex, and GitHub Copilot CLI are the documented first-class agents. You don’t patch the agent; OpenShell wraps it.
• Policy is deny-first. Every sandbox starts with minimal outbound network access, and you widen it deliberately. The quickstart demo applies a GitHub read-only policy that allows API GETs while blocking POSTs at layer 7 — enforcement by inspecting the request, not just the destination host.

That last point is the same deny-first philosophy we recommended after the July escapes, arriving with NVIDIA’s engineering budget behind it.

The Windows catch: WSL2, and “experimental” in writing

Here’s the correction to how this launch got framed on social feeds: OpenShell is not a native Windows app. The README’s support matrix lists Linux, macOS on Apple Silicon, and “Windows with WSL 2 (experimental).” On a Windows machine, the gateway, the sandboxes, and your inference server all live inside the WSL2 Linux environment; Windows is the hypervisor host.

Will that change? There’s an open proposal — issue #2050, filed June 29, 2026 — for a native Windows compute driver built on Microsoft Execution Containers, which would drop the Linux VM layer entirely. Its current labels are needs-rfc and state:stale. No maintainer has committed to it. If you’re waiting for native Windows OpenShell before trying this, you may be waiting a long time.

The practical impact of the WSL2 layer is smaller than it sounds, at least for the inference side: community testing consistently puts WSL2 GPU inference at 90–100% of native Linux performance for LLM workloads, matching what we measured in our WSL GPU passthrough guide. The real WSL2 tax is setup complexity, and that’s where the next section earns its place.

Setup: from zero to a sandboxed agent

Inside your WSL2 distribution (or on bare Linux — identical from here on), the install is one line:

curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh
# or, if you use uv:
uv tool install -U openshell

Launching an agent in a sandbox is one more:

openshell sandbox create -- claude

That creates a sandbox with the default minimal-outbound policy and drops Claude Code into it. openshell sandbox list enumerates what’s running, openshell sandbox connect <name> gives you an SSH-style shell inside, and openshell term opens a live dashboard of gateways, sandboxes, and policy decisions.

Policies are YAML files applied per sandbox:

openshell policy set demo \
  --policy examples/sandbox-policy-quickstart/policy.yaml --wait

Two prerequisites trip people up on the Windows path:

1. A container runtime inside WSL2. OpenShell needs Docker or Podman (or host virtualization for MicroVM sandboxes). Docker Desktop’s WSL2 backend works; so does plain dockerd inside the distribution.
2. GPU access is a separate step. Passing your RTX card into a sandbox requires the NVIDIA driver on the host plus the NVIDIA Container Toolkit inside WSL2 — and the default sandbox image ships without GPU libraries, so you build from a GPU-enabled base:

openshell sandbox create --gpu --from <gpu-enabled-sandbox> -- claude

NVIDIA marks GPU passthrough experimental on every platform, with “rough edges and breaking changes expected” — their words in the docs. It worked in our reading of community reports, but this is the least-baked part of the stack.

The interesting part: inference.local

Everything above is a sandbox. Plenty of tools do sandboxes. What OpenShell adds is inference routing: the agent inside the sandbox sends its model calls to a virtual endpoint named inference.local, and the gateway intercepts that traffic and forwards it to whatever backend you configured — any OpenAI-compatible or Anthropic-compatible server, which in a home lab means Ollama or vLLM on your own GPU.

openshell provider create --type ollama --from-existing
openshell inference set --provider ollama --model gpt-oss:20b

The agent never learns your model server’s real address. And because network policy is deny-first, you can refuse direct connections to api.anthropic.com, api.openai.com, and every other external inference host — at which point “this agent runs 100% on my hardware” stops being a configuration you hope holds and becomes a rule the gateway enforces and logs. That’s the zero-cloud guarantee we approximated with firewall rules in our Claude Code on Ollama setup, done properly.

There’s also a shortcut: the Ollama community sandbox image bundles Ollama, Claude Code, OpenCode, and Codex in one image, with Ollama starting automatically when the sandbox launches — model and sandbox in a single container, GPU flag permitting.

The error you will hit, and the fix. If you run Ollama on the host (the usual setup, so the sandbox stays light), the first symptom is the agent timing out on every model call while ollama run works fine from the host shell. The cause: from inside a sandbox, 127.0.0.1 and localhost point at the sandbox itself, not your machine. Per NVIDIA’s local-inference tutorial, the fix is two-sided — bind Ollama to all interfaces, then point the provider at the host alias instead of loopback:

# host side (WSL2 shell):
OLLAMA_HOST=0.0.0.0 ollama serve
# provider config: use host.openshell.internal (or the host's LAN IP),
# never 127.0.0.1 or localhost

Same class of bug as Docker’s host.docker.internal dance, and if you’ve fought that battle in Open WebUI, this will feel familiar.

What GPU actually drives a sandboxed agent

OpenShell adds no meaningful VRAM overhead of its own — the sandbox is namespaces and policy, not a second model copy. Your floor is set by the model doing the agent work, and agents punish weak models harder than chat does: long contexts, strict tool-call formats, hours of sustained generation. Numbers below are for the model alone; check your exact model-plus-context combination in the VRAM calculator.

GPU tier	Card to buy	Agent model that fits	Footprint / measured speed
16GB	RTX 5060 Ti 16GB	GPT-OSS 20B (MoE)	12.8GB Q4_K_M; ~132 tok/s on a 4090, proportionally less here
24GB	RTX 3090 (used) / RTX 4090	Muse Glimmer 30B	17GB 4-bit; 75 tok/s on RTX 4090
32GB	RTX 5090	Muse Glimmer 30B + DFlash, or Nemotron 3.5 Lightning	Glimmer: 74.9 → 233.4 tok/s with DFlash (3.1×); Lightning: 25GB Q4_K_M, ~123 tok/s

Sourcing on those: GPT-OSS 20B’s 12.8GB Q4_K_M footprint and ~132 tok/s RTX 4090 decode come from WillItRunAI’s compatibility data — and note our own testing found the sustained-speed picture depends heavily on context, with 225 tok/s achievable at an 8K cap and single-digit speeds at 128K. Muse Glimmer’s 17GB 4-bit target for 24GB cards and the RTX 5090 DFlash numbers (74.9 tok/s base, 233.4 tok/s with the speculative-decoding drafter) are from Developers Digest’s benchmark writeup of Meta’s launch data. Nemotron 3.5 Lightning’s 25GB Q4_K_M and RTX 5090 speed are covered in our hardware guide from yesterday.

The tier logic mirrors the GPU buying guide: 16GB is the entry ticket for a competent agent model, 24GB is the sweet spot where 30B-class models fit with context room, and 32GB is where speculative decoding turns “usable” into “fast.” Glimmer’s DFlash drafter costs extra VRAM on top of the base model — on a 24GB card you’re choosing between the drafter and context headroom.

No GPU, or a GPU that tops out at 8GB? OpenShell’s provider config points at any OpenAI-compatible endpoint, including one you rent: a RunPod instance running vLLM gives you the same inference.local privacy boundary between agent and model server, minus the “never leaves my house” property.

Where it fits, honestly

Three things keep this out of daily-driver territory for now.

First, alpha means alpha. Ten releases in twelve days is a project moving fast and breaking things — great for watching, risky for depending on. NVIDIA’s “single-player mode” framing is honest: no multi-user, no fleet management, one gateway.

Second, the Windows story is a compatibility layer with an experimental label on it. It works, the inference overhead is small, but you’re stacking alpha software on WSL2 GPU passthrough — two layers that each have their own failure modes. When something breaks, you get to bisect which layer did it.

Third, policy quality is on you. A sandbox with a permissive policy is theater. The deny-first defaults are good, but the moment you start allowing hosts to make an agent useful, you’re doing security engineering, and the audit log only helps if you read it.

What OpenShell gets right, though, is the thing nobody else ships: the combination of containment (the agent can’t touch what policy doesn’t allow) and inference sovereignty (the agent can’t phone a cloud model even if it wants to) in one enforced stack. For the home-lab reader who bought a 24GB card precisely so their code never leaves the building, that second property is the whole point — and it’s why this is worth tracking through the 0.0.x churn even if you don’t deploy it this month.

FAQ

Does OpenShell run natively on Windows? No. Windows support goes through WSL 2 and is marked experimental in NVIDIA’s own support matrix. A native Windows driver using Microsoft Execution Containers exists only as a stale community RFC (issue #2050) with no maintainer commitment.

Does the sandbox slow down my GPU inference? The sandbox itself doesn’t meaningfully — it’s process isolation, not virtualized compute. The WSL2 layer on Windows costs roughly 0–10% versus native Linux for LLM inference per community testing. GPU passthrough into sandboxes is the experimental part; expect setup friction, not speed loss.

Can I use OpenShell with LM Studio instead of Ollama? The gateway forwards inference.local to any OpenAI-compatible server, and LM Studio exposes one. Ollama and vLLM are the documented, first-class paths; anything else is “should work” territory — fitting for alpha software.

What’s the minimum GPU for a local agent under OpenShell? A 16GB card running GPT-OSS 20B (12.8GB at Q4_K_M) is the realistic floor for agent work — tool calls and long contexts punish smaller models. Below that, route inference.local to a rented endpoint instead.

Is this the same as the sandboxing in Cursor or Claude Code? No — those are per-app sandboxes, several of which were escaped in the July 2026 disclosures. OpenShell is an external runtime that wraps the agent in kernel-level isolation with its own policy engine, so the agent’s own sandbox becoming Swiss cheese doesn’t void the containment.

Sources

• NVIDIA/OpenShell repository — GitHub
• OpenShell README: install, agents, GPU sandboxes — GitHub
• OpenShell releases (v0.0.97–v0.0.106, Aug 3–14 2026) — GitHub
• Issue #2050: native Windows support via Microsoft MXC — GitHub
• Overview of NVIDIA OpenShell — NVIDIA Docs
• Inference Routing — NVIDIA OpenShell Docs
• Run Local Inference with Ollama — NVIDIA OpenShell Docs
• GPT-OSS 20B VRAM requirements and RTX 4090 speed — WillItRunAI
• Muse Glimmer 30B benchmarks and hardware reality — Developers Digest
• WSL2 GPU inference at 90–100% of native — InsiderLLM
• Nvidia’s Month of Local AI — AI-360

Recommended Gear

Products linked in this guide:

• RTX 5060 Ti 16GB — the 16GB entry ticket for local agent models
• RTX 3090 — used 24GB value pick for 30B-class agents
• RTX 4090 — 24GB with the bandwidth to make agents feel instant
• RTX 5090 — 32GB tier: DFlash speculative decoding and Nemotron Lightning territory

Last updated August 18, 2026. OpenShell is alpha software on a near-daily release cadence, and GPU prices move weekly; verify current versions and rates before building around either.