Why this matters

Most agent code today runs with the same privileges as the developer who started it. Same shell, same filesystem, same network. That worked when agents made one or two tool calls per session. It doesn’t work as well when an agent runs for thirty minutes, calls forty tools, and reads files from sources you don’t fully trust.

OpenShell (5.6k stars, 649 forks at time of writing) is NVIDIA’s bid at a runtime layer between the agent and the host. A small CLI, a Docker-based gateway, declarative YAML policies you only write when the defaults aren’t enough. Apache 2.0. Alpha (v0.0.36, released April 2026).

The framing the early adopters keep landing on isn’t “another sandbox,” it’s governance infrastructure. Sandboxes ask “did the agent do something bad?” Governance asks “could the agent have done that in the first place?” The interesting trick is per-binary policies: python3 can reach api.anthropic.com while curl on the same machine can’t reach anything at all. The model can hallucinate any tool call it likes; the runtime decides what actually executes.

Below are four concrete situations where I’d reach for it, framed from the developer’s side: what you type, what comes back, and what you do with it.

Use case 1

Drop containment under your existing agent without writing any YAML

The situation. You have an agent running today (Claude Code, Cursor, Codex, Copilot, or your own loop). You want default-deny network and read-only filesystem under it before something goes wrong, but you don’t have a free afternoon to learn a new policy DSL.

With OpenShell. The default OpenShell policy already ships with rules pre-baked for claude_code, codex, copilot, and cursor. You don’t write a policy file. You just create a sandbox and run your agent inside it.

$ openshell sandbox create --name dev
✓ Sandbox 'dev' ready (default policy applied)

$ openshell sandbox exec --name dev --no-tty -- claude
# your agent boots inside the sandbox, exactly as it would on your host

What you see. Inspect what’s protecting you with one command:

$ openshell policy get dev --full | head -40
filesystem_policy:
  read_only:  [/usr, /lib, /proc, /dev/urandom, /app, /etc, /var/log]
  read_write: [/sandbox, /tmp, /dev/null]

network_policies:
  claude_code:    { binaries: [{path: /usr/local/bin/claude}], ... }
  codex:          { binaries: [{path: /usr/local/bin/codex}],  ... }
  copilot:        { binaries: [{path: /usr/bin/gh}],           ... }
  cursor:         { binaries: [{path: /usr/local/bin/cursor}], ... }

That’s it. Filesystem locked to system paths, network locked to the hosts each major harness actually needs. The first time you try anything outside that envelope, the request dies at the kernel:

$ openshell sandbox exec --name dev --no-tty -- \
    curl -s -o /dev/null -w "HTTP %{http_code}\n" --max-time 10 \
    https://random-site-the-agent-tried.example.com
HTTP 000
exit code 56

One sandbox, one flag, default-deny everywhere your agent shouldn’t go. You can graduate to writing custom YAML later if you need it.

Use case 2

Audit an unfamiliar MCP server in five minutes

The situation. You found a useful-looking MCP server on GitHub. Twelve stars, zero issues. The README says it’s a Slack tool, but the code is 800 lines you haven’t read. You’d like to wire it into your agent today, but giving someone else’s binary your shell privileges is a bad way to find out what it does.

With OpenShell. Launch the server inside a fresh sandbox and let your harness talk to it via stdio. The MCP transport doesn’t care that there’s a sandbox in the middle. From any agent framework that supports stdio MCPs, the wiring looks like:

# Replace MultiServerMCPClient with whatever your harness uses
# (Claude Agent SDK, langchain-mcp-adapters, mcp-python, etc.)
mcp_server = {
    "audit-target": {
        "transport": "stdio",
        "command": "openshell",
        "args": [
            "sandbox", "exec", "--name", "mcp-audit", "--no-tty",
            "--", "/usr/local/bin/the-mcp-server",
        ],
    },
}

What you see. First time the server tries to phone home, it shows up as a denied request:

$ openshell sandbox exec --name mcp-audit --no-tty -- bash -c '
    /usr/local/bin/the-mcp-server --selftest'
HTTP 000     # tried to reach an unknown host on startup
exit code 56

What you do next. Read which host it tried, decide whether you trust it, add it to a small custom policy if you do, repeat. After three or four iterations you have an explicit allowlist of every host the server actually needs. The README doesn’t have to be honest. You don’t have to read 800 lines. The runtime tells you what the code actually wants.

Use case 3

Run parallel agent evals without state collisions

The situation. You have eight prompts and four model variants. That’s thirty-two agent runs and you’d like them in parallel. On a single host they’d collide on ports, scratch files, environment variables, and whatever the agent decides to write into ~/.cache. You could spin up thirty-two Docker containers, but each one takes seconds to boot and gigabytes to image.

With OpenShell. Each sandbox gets its own filesystem view, its own working directory, its own network namespace, and boots in milliseconds. Fan-out is a bash loop:

#!/usr/bin/env bash
set -euo pipefail

PROMPTS=( prompts/*.txt )
MODELS=( opus-4-7 sonnet-4-6 haiku-4-5 gpt-5 )

for prompt in "${PROMPTS[@]}"; do
  for model in "${MODELS[@]}"; do
    name="eval-$(basename "$prompt" .txt)-$model"
    openshell sandbox create --name "$name" > /dev/null
    openshell sandbox exec --name "$name" --no-tty -- \
      python3 /app/run_eval.py "$prompt" "$model" \
      > "results/$name.jsonl" 2>&1 &
  done
done
wait
echo "All 32 runs complete"

What you see. Thirty-two output files in results/, one per (prompt, model) pair. No port conflicts because each sandbox has its own network namespace. No scratch-file collisions because each one writes to its own /sandbox/. No leaked env vars because the sandbox process doesn’t inherit your shell environment by default.

$ ls results/ | wc -l
32

$ openshell sandbox list --filter eval-
NAME                                STATUS    AGE
eval-tool-use-1-opus-4-7            running   00:00:42
eval-tool-use-1-sonnet-4-6          running   00:00:42
eval-tool-use-1-haiku-4-5           running   00:00:42
... (29 more)

What you do next. Diff the results, drop the losers, tear down all thirty-two sandboxes with one openshell sandbox prune. Your host is exactly as you left it.

Use case 4

Build a multi-agent debug rig where each agent has its own lane

The situation. You’re building a multi-agent system. A planner emits a task graph, an executor runs each task, a critic reviews the output. Three agents that need different things: the planner needs LLM API access only, the executor needs filesystem write and a few external APIs, the critic needs read access to the executor’s outputs and nothing else. Running all three in one process means a bug in any one can corrupt the others.

With OpenShell. Each agent gets its own sandbox. You wire them together with shared volumes for the artifacts they need to pass and nothing else.

import subprocess

AGENTS = {
    "planner":  ("policies/planner.yaml",  ["python3", "/app/planner.py"]),
    "executor": ("policies/executor.yaml", ["python3", "/app/executor.py"]),
    "critic":   ("policies/critic.yaml",   ["python3", "/app/critic.py"]),
}

def boot(name, policy):
    subprocess.run(
        ["openshell", "sandbox", "create",
         "--name", name, "--policy", policy],
        check=True,
    )

def run(name, argv, task):
    return subprocess.run(
        ["openshell", "sandbox", "exec", "--name", name,
         "--no-tty", "--", *argv, task],
        capture_output=True, text=True, check=True,
    ).stdout

for name, (policy, _) in AGENTS.items():
    boot(name, policy)

plan = run("planner",  AGENTS["planner"][1],  "summarize repo")
out  = run("executor", AGENTS["executor"][1], plan)
review = run("critic", AGENTS["critic"][1],   out)

What you see. Three sandboxes, three policies, three independent processes. When the executor goes haywire and tries to rm -rf something, it hits its own filesystem boundary, not yours. When the planner’s API call hangs, the critic and executor keep running. Attach a shell to any one of them mid-run:

$ openshell sandbox exec --name executor -- bash
sandbox@executor:/sandbox$ ls artifacts/
plan.json   step-1.out   step-2.out   step-3.out
sandbox@executor:/sandbox$ cat step-2.out | tail -5
# inspect intermediate state without restarting the run

What you do next. Restart any one sandbox without killing the other two: openshell sandbox restart executor. The planner’s still up, the critic’s still up, the executor comes back fresh and picks up from plan.json. Multi-agent systems get a lot more pleasant to debug when each agent is its own process you can hold separately.

What to know before you reach for it

OpenShell is alpha software in a hot category. The dev-experience write-ups so far are positive on the architecture and honest about the rough edges. A few worth flagging before you put it in front of anything sensitive:

• DNS over UDP/53 is currently unenforced. The gateway proxies TCP/HTTP egress; DNS queries go straight to the system resolver. Issue #1169 shows a working data-exfiltration PoC where /etc/passwd escapes a strict policy via subdomain-encoded DNS lookups. Open as of v0.0.36. If you’re sandboxing against real PII, treat this as a known gap and front the sandbox with an outbound DNS firewall until it’s patched.
• K3s overhead is real. The gateway runs k3s in Docker, which is a lot of machinery for a single-developer laptop sandboxing one Claude Code instance. Above three or four sandboxes the overhead amortizes; below that, you’re paying for capability you may not need.
• Don’t ship credentials into the sandbox as env vars. The community pattern that’s emerging: keep secrets out of the sandbox process entirely and expose them only via a connection API or short-lived ticket. An LLM running inside the sandbox can read its own environment trivially; the runtime won’t save you from that.
• Static vs dynamic policy. filesystem_policy, landlock, and process are locked at sandbox creation; only network_policies hot-reloads. Plan filesystem layout up front; iterate on network rules.

None of these are dealbreakers for the use cases above. They are reasons to read the issue tracker before you bet a production workflow on it.

Where it sits next to Claude Code, Cursor, and MCP

OpenShell is not a coding agent. It’s the runtime under one. Three layers, three jobs:

• The harness is your Claude Code, Cursor, Aider, OpenCode, or your own agent loop. It owns the agent loop and decides which tools to call.
• The protocol is MCP. It’s how the harness talks to the tools.
• The runtime is OpenShell. The sandboxed OS the harness and the tools run inside.

If you’ve read the Prompt → Context → Harness post, OpenShell is the fourth layer underneath: Prompt → Context → Harness → Runtime. The agent loop confines the model to a finite set of moves. The runtime confines the moves themselves to what’s actually allowed.

It’s worth saying explicitly that OpenShell isn’t competing with e2b, Daytona, or Blaxel. Those are sandbox-as-a-service: cold-start a fresh VM in 25–150ms, run untrusted code, throw it away. Different category, different optimizations. e2b is north of two hundred million sandboxes served. OpenShell isn’t trying to win that race; it’s trying to be the policy and governance layer you’d run under any of them, or under your own agent on your own host. If your problem is “I need to spin up a thousand throwaway envs an hour for user-submitted code,” reach for e2b. If your problem is “I need to constrain what my own agent can do, with policies I can read in a YAML file and version in git,” reach for OpenShell.

About the author

Archit Dwivedi builds AI agents and ships them into production. More at /about · what I’m working on · say hi.

• LinkedIn
• GitHub
• Mail

Archit · May 2026