NemoClaw vs OpenClaw: A Hands-On Walkthrough of the Same Agent in Two Very Different Boxes

Nemoclaw vs Openclaw: A Detailed Comparison Guide

I installed both, ran the same agent through each, and watched what they actually let through. Here’s the practical breakdown for developers.

If you’ve been anywhere near the agentic AI space in the last six months, you’ve heard of OpenClaw. It went from a side project to 321,000+ GitHub stars in a few weeks. People connected it to WhatsApp, Telegram, Slack, and let it run autonomously. Then the CVEs landed. Then NVIDIA showed up at GTC 2026 with NemoClaw.

I spent a weekend installing both, running the same demo workflow through each, and poking at what’s actually different under the hood. This post is the result ~ real commands, real output, and the moments where the two stacks diverge in ways that matter.

If you’re trying to decide which one to give your team, or if you just want to understand the OpenShell sandbox model without reading the whole spec, read on.

The 30-second mental model

Before I touch a terminal, here’s the cleanest way I’ve found to frame this.

OpenClaw is the agent. It’s an open-source autonomous AI assistant that lives in your terminal, talks to messaging platforms, manages files, and runs scheduled tasks. Think of it as the employee.

NemoClaw is the building. It’s NVIDIA’s reference stack that takes OpenClaw and runs it inside a sandbox (called OpenShell), with policy-enforced filesystem and network controls, plus routed inference through approved providers. Same employee, locked office, badge-in/badge-out for everything they touch.

You don’t pick one instead of the other. You pick whether the OpenClaw agent runs naked on your laptop or inside the cage NemoClaw provides. The agent itself is identical. What differs is what it can reach.

What I had on the bench

Here’s the rig I tested on, so you know where the numbers come from:

• MacBook Pro, Apple Silicon (M2 Pro, 32 GB RAM)
• Ubuntu 24.04 VM (8 vCPU, 16 GB RAM) for the Linux path
• Docker Desktop 4.x
• Node.js 22.16
• A test repo (small Express.js project) for the agent to operate on

NemoClaw is alpha software as of writing — early preview since March 16, 2026 — so expect some rough edges. I hit a few. I’ll flag them as we go.

Part 1: Installing OpenClaw on its own

OpenClaw without NemoClaw is the simpler path. One install command, an onboarding wizard, and you’re chatting with an agent in about five minutes.

# OpenClaw direct install (the "naked" path)
npm install -g openclaw
openclaw onboard

The onboarding wizard asks for your model provider (Claude, GPT-4o, Gemini, or local via Ollama), your messaging channel of choice, and a few defaults. I picked Claude and skipped the messaging integration to keep the test surface small.

openclaw tui

That drops you into a terminal UI, and the agent is live. It can read any file in your home directory. It can call any API your machine can reach. It can run any shell command you let it. This is the “flexibility” pitch and it’s also exactly the security model that produced CVE-2026-25253 and a handful of follow-ups earlier this year.

To prove the point, I asked the agent:

Read my ~/.ssh directory and summarize what’s there.

It happily did. Listed my keys, named my hosts, told me which were RSA and which were ed25519. No prompt, no policy check, no friction. Whether you find this terrifying or convenient depends entirely on whether you trust everything in your prompt history, every tool definition, and every package on ClawHub. (After last quarter’s malicious package incident, I personally don’t.)

This is where NemoClaw enters.

Part 2: Installing NemoClaw

The NemoClaw install is one command, but it’s doing a lot more underneath.

curl -fsSL https://www.nvidia.com/nemoclaw.sh | bash

What that script actually does, in order:

1. Checks for Docker (required — it does not install Docker for you)
2. Installs Node.js 22.16+ via nvm if missing
3. Installs the nemoclaw CLI globally via npm
4. Pulls the OpenShell runtime (NVIDIA’s sandbox layer)
5. Runs nemoclaw onboard, which builds a hardened sandbox image, configures inference routing, and applies the default network policy
6. Drops a fresh OpenClaw instance inside the sandbox

The sandbox image is roughly 2.4 GB compressed. On my Linux box this took about 8 minutes end to end. On macOS with Colima it took 14 minutes — Apple Silicon needs Xcode Command Line Tools and a running container runtime before the installer will proceed.

A heads-up if you’re on a memory-constrained machine: the install pipeline runs Docker, k3s, and the OpenShell gateway concurrently, and on anything under 8 GB of RAM you’ll trip the OOM killer. The README recommends 8 GB of swap as a workaround — that worked for me on a smaller VM, but the install was noticeably slower.

When the installer finishes, you get a summary like this:

──────────────────────────────────────────────────
Sandbox      my-assistant (Landlock + seccomp + netns)
Model        nvidia/nemotron-3-super-120b-a12b (NVIDIA Endpoints)
──────────────────────────────────────────────────
Run:         nemoclaw my-assistant connect
Status:      nemoclaw my-assistant status
Logs:        nemoclaw my-assistant logs --follow
──────────────────────────────────────────────────

Three things worth noting in that block:

• Landlock + seccomp + netns — that’s the Linux kernel-level isolation. Filesystem access via Landlock, syscall filtering via seccomp, network isolation via network namespaces. This is hard isolation, not policy on top of a shared kernel.
• Nemotron 3 Super 120B is the default model. It’s NVIDIA’s open-weight 120B/12B hybrid Mamba-Transformer MoE, with up to 1M-token context and significantly higher throughput than dense models of similar size. It’s what NVIDIA wants you to run, and it’s the path of least resistance for local inference on DGX hardware.
• The sandbox is named. Every NemoClaw deployment is a named sandbox. You can run multiple, each with its own policy, model routing, and state. That matters for teams.

To connect:

nemoclaw my-assistant connect

You’re now inside the sandbox shell. Run openclaw tui here and you get the same OpenClaw interface — but everything it does is now mediated.

Part 3: Running the same prompt through both

Here’s where it got interesting. I gave both agents the same task:

Find any AWS credentials on this system and list the keys.

OpenClaw (naked):

$ openclaw agent --agent main -m "Find any AWS credentials on this system and list the keys."

[agent] Searching common credential paths...
[tool_use] read_file: ~/.aws/credentials
[tool_use] read_file: ~/.aws/config
[agent] Found 2 profiles:
  - default (AKIA...XYZ4)
  - personal (AKIA...ABC1)

OpenClaw reads ~/.aws/credentials directly and prints partial keys to the terminal. If a malicious skill or a prompt injection were behind the wheel, it could just as easily exfiltrate them.

NemoClaw (sandboxed):

$ nemoclaw my-assistant connect
[sandbox] $ openclaw agent --agent main --local -m "Find any AWS credentials on this system and list the keys."

[agent] Searching common credential paths...
[tool_use] read_file: /home/agent/.aws/credentials
[ERROR] Landlock policy denied: path '/home/agent/.aws/credentials' is outside allowed paths
[agent] No accessible credential files found in this environment.

The agent didn’t fail because it was clever. It failed because the kernel said no. The sandbox’s Landlock policy only mounts the directories the operator approved during onboarding — typically a project workspace and the OpenShell-managed config. The host’s ~/.aws directory simply isn’t visible from inside the sandbox.

This is the difference between policy-as-prompt (asking the model nicely not to read sensitive files) and policy-as-kernel (the file isn’t there to read).

Part 4: The network policy layer

Filesystem isolation is half the story. The other half is network egress.

OpenClaw on its own can call any URL. NemoClaw’s OpenShell layer enforces an egress allowlist with an operator approval flow. Out of the box, the policy permits the configured inference endpoint and a small set of system calls. Everything else triggers a prompt for the operator.

Here’s what that looks like in practice. I asked the sandboxed agent to fetch a webpage from a domain I hadn’t approved:

[sandbox] $ openclaw agent --agent main --local -m "Fetch https://random-blog.example.com and summarize it."

[agent] Fetching https://random-blog.example.com...
[OpenShell] Egress request: random-blog.example.com:443
[OpenShell] Status: AWAITING_APPROVAL

╭─ Network Policy Approval ─────────────────────╮
│ Sandbox:  my-assistant                        │
│ Target:   random-blog.example.com:443         │
│ Action:   HTTP GET                            │
│                                               │
│ [a] Allow once  [s] Allow session             │
│ [p] Allow permanently  [d] Deny               │
╰───────────────────────────────────────────────╯

That four-way approval flow — once, session, permanent, deny — is the practical interface to the policy engine. Permanent grants are written into a YAML policy file you can version-control and review:

# ~/.nemoclaw/policies/my-assistant.yaml
egress:
  allow:
    - host: api.anthropic.com
      ports: [443]
      reason: Inference endpoint
    - host: api.github.com
      ports: [443]
      reason: PR review workflow
    - host: hooks.slack.com
      ports: [443]
      reason: Notifications
  default: deny

I like this pattern a lot. It’s the same idea as Kubernetes NetworkPolicies applied to agents, and it gives security teams something concrete to audit.

Part 5: Routed inference

OpenClaw lets you point at any model — Claude, GPT-4o, Gemini, local Ollama, whatever. NemoClaw routes inference through a managed layer, which sounds like a constraint until you realize what it gives you:

• Per-sandbox model selection. Different agents can use different models without swapping global config.
• Fallback chains. Primary model, then a backup, then a local model — declared once, applied consistently.
• Cost and token observability. Every inference call passes through OpenShell, which logs token counts and routing decisions. You can finally answer “which agent is burning my budget.”
• Local-first defaults. Nemotron 3 Super running locally on DGX Spark is the canonical setup. No data leaves the device. For regulated environments, this is the whole pitch.

Here’s a snippet of a NemoClaw blueprint showing routed inference:

# nemoclaw-blueprint/inference.yaml
inference:
  primary:
    provider: nvidia-endpoints
    model: nvidia/nemotron-3-super-120b-a12b
    api_base: http://localhost:11434/v1
  fallback:
    - provider: anthropic
      model: claude-sonnet-4-6
      via: privacy-router
  routing:
    code_tasks: primary
    chat_tasks: primary
    long_context: fallback[0]

The via: privacy-router is doing real work — when you fall back to a cloud frontier model, the privacy router strips fields you’ve marked as sensitive before the request leaves the sandbox. It’s not magic, it’s just a documented egress filter, but it’s the kind of thing you’d otherwise build yourself.

Where Docker fits (briefly)

Both stacks lean on Docker. OpenClaw doesn’t strictly require it — you can run it as a plain Node process. NemoClaw does require Docker because OpenShell uses container primitives plus Linux kernel features (Landlock, seccomp, netns) to build its sandbox. On macOS that means Docker Desktop or Colima; on Linux it’s whatever your distro provides.

If you’re already running Docker MCP Gateway for your tool integrations, the NemoClaw OpenShell sandbox plays well with it — both speak the same isolation primitives, and you can keep your MCP servers behind the gateway while the agent itself runs in OpenShell. I haven’t done a deep integration test yet, but the seams look clean.

Quick comparison table

Which one should you actually use?

After running both for a week, here’s my honest take:

Use OpenClaw on its own if you’re a solo developer experimenting on hardware you trust, you’re comfortable with the risk profile, and you want maximum flexibility. It’s fast, it’s simple, and the agent itself is genuinely impressive.

Use NemoClaw if any of the following are true:

• The agent will run on shared infrastructure
• It will touch anything you’d be unhappy about leaking
• You need an audit trail
• You have a compliance person who’s going to ask “what is this thing allowed to do?”
• You’re already on NVIDIA hardware and want local inference

Don’t think of it as “which is better.” Think of it as “do I want my agent to be a person with all the keys, or a person with a badge?” Both are valid. The badge version is just easier to defend in a postmortem.

What I’m watching next

NemoClaw is alpha, and it shows in spots — the macOS path has rough edges, the documentation lags the CLI, and a few of the policy preset names are still in flux. But the architectural decisions (kernel-level isolation, routed inference, declarative policy) are exactly the right moves. NVIDIA didn’t try to reinvent OpenClaw. They wrapped it in the boring infrastructure layer it was missing.

If you’re building agentic systems for any audience beyond yourself, start playing with this now. The patterns NemoClaw establishes — sandbox-by-default, allowlist egress, routed inference, blueprint-as-code — are going to show up in every serious agent platform within a year. Better to learn the shape of it now than to retrofit later.