OpenShell sandboxes

Coding agents are fastest when they stop asking before every command. Claude Code calls that --dangerously-skip-permissions, and Codex calls it --dangerously-bypass-approvals-and-sandbox. On your own machine, that mode lets a prompt injection or a bad guess touch everything you can touch.

defenseclaw sandbox run gives the agent that mode inside an NVIDIA OpenShell sandbox instead. The agent sees only your project folder. DefenseClaw still checks every tool call and every site the agent contacts, and at the end of the session you review what changed and keep it, undo it or pull it back.

cd ~/code/myapp
defenseclaw sandbox run claude

On a Mac, the run looks like this. The capture is from a real session whose sandbox was named with --name myapp-claude (without --name it would be myapp- plus a random suffix) and whose model credential was an Amazon Bedrock key. Below the banner, Claude Code starts as usual.

The banner's lines, as text, for a default-named sandbox with an Anthropic API key:

Sandbox myapp-1c2d · Claude Code · skip-permissions ON · network: open + blocklist
  Project   ~/code/myapp → /sandbox/work/myapp (copy)   changes come back with `defenseclaw sandbox pull myapp-1c2d`
            Not visible: everything else on this machine
  Model     ANTHROPIC_API_KEY → api.anthropic.com only (the sandbox sees a placeholder)
  Asks      announced in this terminal's title as they come; answer them in another terminal: defenseclaw sandbox approvals --sandbox myapp-1c2d (or `defenseclaw tui`: 7, then t)

Read the banner explains each line.

The mental model

Think of the sandbox as a locked room that holds only your project folder. Two layers build it:

• OpenShell builds the room. On Linux each sandbox is a container; on a Mac it is a small virtual machine (a MicroVM) with its own Linux kernel. Either way the workload has no network of its own, runs as your uid with no capabilities, and is held in by Landlock filesystem rules and seccomp. Its only way out is OpenShell's supervisor.
• DefenseClaw adds the judgment. Its hooks run inside the sandbox and send every tool call to the DefenseClaw daemon, which checks it with the same rule packs, guardrails and judge as outside a sandbox. Its egress proxy decides and logs every site. It hides secret files, protects git internals, snapshots the folder and reviews what changed.

The sandbox reaches your machine only at host.openshell.internal, which OpenShell maps to your machine's loopback address. The hooks arrive there on a dedicated hook ingress port, and web traffic leaves through the egress proxy port. The DefenseClaw daemon's main API is never one of them. With the default API port 18970, the ingress is 18971 and the egress proxy 18972.

See it in action

Both demos were recorded with Claude Code in skip-permissions mode on a Linux host.

What OpenShell protects

• Sensitive files stay hidden. A .env file holds a dummy secret on the host. Inside the sandbox the agent reads the same file and finds it empty.
• The real model key never enters the sandbox. The harness gets a placeholder token. When the agent searches its environment for an ANTHROPIC_* key, it finds no real value.
• The host is out of reach. The agent cannot list or read the host's home directory, its ~/.ssh or a payroll file planted on the host. Those paths do not exist inside the sandbox.

What DefenseClaw adds

• Prompt guardrails. A malicious prompt is blocked before it reaches the model. In the demo, TRUST-IGNORE-PREVIOUS stops an "ignore all previous instructions" exfiltration request at UserPromptSubmit.
• Tool-call guardrails. Unauthorized or malicious tool calls are stopped before they run. In the demo, C2-METADATA-AWS blocks a curl to the cloud metadata endpoint.
• Egress control. The egress proxy blocks connections to suspicious destinations and lets normal traffic through. In the demo, github.com returns HTTP 200, and the connection to a request-inspection site is refused with a 403.

Linux and macOS at a glance

Sandboxes run on Linux (amd64 and arm64) and on Macs with Apple silicon. They are not supported on Windows or WSL2, on Intel Macs, in managed_enterprise deployments, or when you run DefenseClaw as root.

Everything else is the same on both: the hooks, the policy packs, the egress proxy and its blocklist, asks, credential placeholders, telemetry and tamper detection.

Choose your path

The session lifecycle

1. Setup checks the machine, installs OpenShell 0.1 when you agree, configures its gateway, and builds the harness images. You run it once.
2. Run creates a sandbox for the folder you are in, or resumes the one that already holds it, and gives the harness your terminal.
3. During the session every tool call goes through DefenseClaw's hooks and every site through its egress proxy. Blocks and asks appear in the activity feed.
4. At the end you get a summary and a review of the changed files that could run code on your machine.
5. Keep, undo or pull. On Linux you keep the changes or undo them. On a Mac, or with --copy, you apply them, put them on a branch, write a patch, or leave them in the sandbox for sandbox pull.
6. Stop or delete. The sandbox is stopped and kept, so defenseclaw sandbox connect NAME resumes it. defenseclaw sandbox delete NAME removes it.

Which agents can run

Claude Code and Codex are set up by default, and both use root-owned managed hook files that the agent cannot change. GitHub Copilot CLI, OpenCode, Kiro CLI, Hermes Agent, OpenHands, OmniGent and Antigravity also run. DefenseClaw uses a harness image only after it proves that its hooks fire and block in it. See which harnesses can run and the capability matrix.

Where to go next

• Complete sandbox guide: every run flag, copy mode, parallel runs, MCP servers, shell wrappers, teardown and troubleshooting.
• Sandbox policy packs and admin controls: write a custom pack and set organization-wide limits.
• Sandbox CLI reference: every defenseclaw sandbox command and flag.
• OpenShell sandbox settings: every openshell: key in config.yaml.