I tried running NVIDIA NemoClaw on DGX Spark
This page has been translated by machine translation. View original
Introduction
Hello, I'm Morishige from Classmethod's Manufacturing Business Technology Department.
In my recent on-site report from GTC 2026, I introduced "NemoClaw," an open-source AI agent security stack announced by NVIDIA.
After GTC ended, I tried it out on my DGX Spark before heading home. This time, rather than a conceptual discussion, this is a hands-on record from installation through chatting with an agent.
NemoClaw Recap
The details of NemoClaw are explained in my previous GTC report article, so here I'll briefly review only the parts necessary for this verification.
NemoClaw is an open-source plugin that adds an NVIDIA-made security layer to OpenClaw (an AI agent framework). The core is a secure runtime called OpenShell, consisting of three layers: sandbox (OS-level isolation via Landlock + seccomp), a policy engine (constraint enforcement and update proposals), and a privacy router (routing sensitive data to local models).
The goal for this session is to set up NemoClaw on DGX Spark and run a locally self-contained secure agent environment using Nemotron 3 Super via Ollama. I'll be following the DGX Spark Playbook published by NVIDIA.
Verification Environment
| Item | Value |
|---|---|
| Hardware | NVIDIA DGX Spark (GB10) |
| Memory | 128GB unified memory |
| OS | Ubuntu 24.04 LTS |
| Docker | 29.1.3 |
| NVIDIA Driver | 580.126.09 |
| Node.js | v22.22.0 |
| Ollama | 0.17.2 |
| Inference model | Nemotron 3 Super 120B-A12B (Q4_K_M, Ollama) |
Nemotron 3 Super is already running via Ollama on the DGX Spark. I'll proceed by adding NemoClaw to this environment. The OLLAMA_HOST=0.0.0.0 setting for Ollama is already configured, so the connection from the sandbox is ready.
For basic DGX Spark setup and Nemotron 3 Super installation, please refer to past articles as well.
Installing on DGX Spark
The DGX Spark Playbook published by NVIDIA summarizes the 14-step procedure. It carefully covers everything from Docker, Node.js 22, and Ollama installation, so if you're new to DGX Spark, it's safest to start there.
Since these are already installed in my environment, I'll start from the NemoClaw-specific installation.
Installing the OpenShell CLI
Install the CLI for OpenShell, NemoClaw's sandbox runtime.
curl -LsSf https://raw.githubusercontent.com/NVIDIA/OpenShell/main/install.sh | sh
openshell: resolving latest version...
openshell: downloading openshell v0.0.11 (aarch64-unknown-linux-musl)...
openshell: verifying checksum...
openshell: extracting...
openshell: installed openshell 0.0.11 to /home/morishige/.local/bin/openshell
On the ARM64 DGX Spark, the install script automatically downloaded the aarch64 binary.
Installing NemoClaw
NemoClaw itself is installed by cloning the GitHub repository and globally installing via npm.
cd ~
git clone https://github.com/NVIDIA/NemoClaw.git
cd NemoClaw
sudo npm install -g .
added 1 package in 452ms
Setup for DGX Spark
NemoClaw has a dedicated setup command for DGX Spark.
sudo nemoclaw setup-spark
Internally, it automatically handles configuring Docker's cgroup namespace mode (required for OpenShell to run k3s inside a container) and adding the user to the Docker group. On first run, you'll be prompted to enter an NVIDIA API Key, so issue a free key at build.nvidia.com and enter it. Even if you only use local Ollama, it's required as a CLI gateway.
Onboarding Wizard
Running nemoclaw onboard launches a 7-step setup wizard.
cd ~/NemoClaw
nemoclaw onboard
The wizard proceeds in 7 steps. Here's how it went for me.
Step 1: Preflight
✓ Docker is running
✓ Container runtime: docker
✓ openshell CLI: openshell 0.0.11
✓ Port 8080 available (OpenShell gateway)
✓ Port 18789 available (NemoClaw dashboard)
✓ NVIDIA GPU detected: 1 GPU(s), 124610 MB VRAM
The DGX Spark Playbook mentioned "No GPU detected may be displayed," but in my environment it was properly recognized as 124,610 MB (approximately 122GB). The reporting method for unified memory appears to vary by environment.
Note that port 18789 is the port used by NemoClaw's dashboard. If another container is using it, the Preflight will be blocked, so it's a good idea to check beforehand.
Step 2: Gateway
The OpenShell gateway container starts. The first time took about 30-60 seconds due to image downloading.
Step 3: Sandbox
You enter a sandbox name (default is my-assistant). It builds a Docker image from NemoClaw's Dockerfile and creates the sandbox. During the initial build, Python 3, Git, OpenClaw, NemoClaw plugins, and more are installed on top of a Node.js 22-slim base image. The build completed without issues on the ARM64 DGX Spark as well. The image size is approximately 1.5GB, and including the upload to the gateway, it took about 5 minutes.
Step 4: Inference
It automatically detects the local inference engine. If Ollama is running, it appears as a candidate for selection.
Inference options:
1) NVIDIA Cloud API (build.nvidia.com)
2) Local Ollama (localhost:11434) — running (suggested)
Choose [1]: 2
The model list is also automatically retrieved from Ollama. In my environment, 36 models were displayed. I selected nemotron-3-super here.
Step 5: Inference provider
The ollama-local provider is automatically created and the inference route is configured.
Route: inference.local
Provider: ollama-local
Model: nemotron-3-super:latest
Step 6: OpenClaw
The OpenClaw gateway automatically starts inside the sandbox.
Step 7: Policies
You select a network policy preset. pypi and npm are suggested by default, and it detected environment variables from the host environment (in this case SLACK_BOT_TOKEN) and suggested additional presets as well.
When setup is complete, the sandbox information is displayed.
──────────────────────────────────────────────────
Sandbox my-assistant (Landlock + seccomp + netns)
Model nemotron-3-super:latest (Local Ollama)
NIM not running
──────────────────────────────────────────────────
Run: nemoclaw my-assistant connect
Status: nemoclaw my-assistant status
Logs: nemoclaw my-assistant logs --follow
──────────────────────────────────────────────────
The whole process took about 17 minutes. The first time takes longer due to the image build, but subsequent runs should be faster thanks to caching.
Changing the Inference Model
This time I directly selected nemotron-3-super in Step 4 of the onboarding wizard. The Playbook default is nemotron-3-nano, but with DGX Spark's 128GB unified memory, Super runs without issues.
If you want to change the model later, you can switch the inference route with the following command.
openshell inference set \
--provider ollama-local \
--model nemotron-3-super:latest \
--no-verify
--no-verify is a flag to skip verification from the host side, because host.openshell.internal is only resolved from inside the sandbox.
If the provider hasn't been created yet, create it manually.
openshell provider create \
--name ollama-local \
--type openai \
--credential "OPENAI_API_KEY=ollama" \
--config "OPENAI_BASE_URL=http://host.openshell.internal:11434/v1"
You can check the current settings with openshell inference get.
Running the Agent
Running from the Command Line
First, let's connect to the sandbox and try the agent from the command line.
nemoclaw my-assistant connect
Inside the sandbox:
export NVIDIA_API_KEY=local-ollama
export ANTHROPIC_API_KEY=local-ollama
openclaw agent --agent main --local -m "Say hello in Japanese" --session-id s1
こんにちは！
real 0m14.423s
With the Nemotron 3 Super model already loaded, a response came back in about 14 seconds. Checking with nvidia-smi, Ollama was using approximately 89,734 MiB (about 87.6GB / 128GB). Note that the first time requires waiting a bit since the model loading takes time.
The reason dummy values are set for NVIDIA_API_KEY and ANTHROPIC_API_KEY is that OpenClaw performs an existence check for API keys. Since actual inference is routed to Ollama, the keys don't need to be valid.
Let's also verify the sandbox's network isolation.
# Run inside sandbox
curl -sI https://httpbin.org/get
HTTP/1.1 403 Forbidden
It's properly blocked. OpenShell's network policy is working, and external access to anything other than pypi, npm, and slack — which were permitted during onboarding — is blocked. This reduces the risk of an agent inside the sandbox making unintended external communications.
Interactive Chat with OpenClaw TUI
Beyond throwing single questions from the command line, you can also use it interactively. Launch the OpenClaw TUI while connected to the sandbox.
# Inside sandbox
openclaw tui
Monitoring with OpenShell TUI
Launching the OpenShell TUI from the host side in a separate terminal allows you to monitor sandbox activity in real time.
openshell term
f to follow, s to filter by source, q to quit.
Using the Browser Dashboard
OpenClaw also comes with a browser-based chat UI. Since port 18789 forwarding is automatically configured during onboarding, retrieve the dashboard URL and open it in your browser.
Inside the sandbox:
openclaw dashboard
🦞 OpenClaw 2026.3.11 (29dc654)
Dashboard URL: http://127.0.0.1:18789/#token=29f18ce9...
Opening the displayed URL in your browser shows the OpenClaw chat UI. Note that you need to use the complete URL including the #token=... hash fragment as-is.
Sandbox Operation Tips
Once setup is complete, interacting with the agent is comfortable, but there are a few points worth knowing during development and customization.
Moving Files In and Out
The sandbox environment is minimal and doesn't include editors like vi or nano. The workflow for editing configuration files or placing scripts is to work on the host side and then send them in with openshell sandbox upload.
# Send a file from host → sandbox
openshell sandbox upload my-assistant ./my-file.txt /sandbox/
# Retrieve a file from sandbox → host
openshell sandbox download my-assistant /sandbox/output.txt ./
When uploading a directory, .gitignore rules are applied by default, so you don't need to worry about node_modules being included. Use the --no-git-ignore flag if you want to disable this.
Connecting with VS Code Remote-SSH
The openshell sandbox ssh-config command can generate an SSH config entry. By appending this to ~/.ssh/config, you can connect directly to the sandbox from VS Code's Remote-SSH extension for file editing and terminal operations.
openshell sandbox ssh-config my-assistant >> ~/.ssh/config
Managing the Sandbox
# Check sandbox status
nemoclaw my-assistant status
# Check logs (real-time follow)
nemoclaw my-assistant logs --follow
# Delete sandbox (when you want to start over)
nemoclaw my-assistant destroy
To return to a completely clean state including the gateway:
openshell sandbox delete my-assistant
openshell gateway destroy -g nemoclaw
After that, re-running nemoclaw onboard lets you start from scratch.
Architecture Overview
NemoClaw on DGX Spark operates in the following nested structure.
DGX Spark (Ubuntu 24.04, cgroup v2)
└── Docker (29.x, cgroupns=host)
└── OpenShell gateway container
└── k3s (embedded)
└── nemoclaw sandbox pod
└── OpenClaw agent + NemoClaw plugin
It's a structure where k3s runs inside Docker, and the sandbox pod runs inside that. The reason nemoclaw setup-spark configures Docker's cgroup namespace mode is because this k3s expects cgroup v1-style paths.
OpenShell's security isolation consists of 4 layers.
| Layer | Protection Target | Timing |
|---|---|---|
| Filesystem | Blocks reads/writes outside permitted paths | Fixed at sandbox creation |
| Network | Blocks unauthorized external connections | Hot-reloadable at runtime |
| Process | Blocks privilege escalation and dangerous syscalls | Fixed at sandbox creation |
| Inference | Routes model API calls to controlled backends | Hot-reloadable at runtime |
Pain Points and Solutions
Here is a summary of issues encountered while running NemoClaw on DGX Spark, as well as known issues documented in the Playbook.
Dashboard Port Conflict
NemoClaw's dashboard hard-codes port 18789. In my environment, another container from a hackathon was occupying this port, causing Preflight to block it. It's a good idea to verify beforehand with ss -tlnp | grep 18789.
Gateway Port Conflict
If a container is using port 8080, the gateway startup will fail. If an old gateway remains, you can remove it with openshell gateway destroy -g nemoclaw.
OpenShell Forward Goes Dead
After setup, the port forward to the dashboard sometimes became dead. Check with openshell forward list, and if it has gone dead, restart it.
openshell forward stop 18789 my-assistant
openshell forward start --background 18789 my-assistant
Cannot Reach Ollama from Sandbox
If Ollama is only listening on the default localhost, it cannot be accessed from the sandbox. The OLLAMA_HOST=0.0.0.0 setting is required.
sudo mkdir -p /etc/systemd/system/ollama.service.d
printf '[Service]\nEnvironment="OLLAMA_HOST=0.0.0.0"\n' | sudo tee /etc/systemd/system/ollama.service.d/override.conf
sudo systemctl daemon-reload && sudo systemctl restart ollama
Origin Error When Accessing Remotely
Accessing the dashboard via SSH tunnel resulted in an origin not allowed error. This is because nemoclaw-start.sh sets only the default value of CHAT_UI_URL, http://127.0.0.1:18789, in allowedOrigins. When accessing from a browser via http://localhost:18789, 127.0.0.1 and localhost are treated as different origins.
The fix is simply to restart the gateway inside the sandbox with CHAT_UI_URL specified.
# Inside sandbox
export NVIDIA_API_KEY=local-ollama
export ANTHROPIC_API_KEY=local-ollama
export CHAT_UI_URL=http://localhost:18789
nemoclaw-start
Performance Impressions
I measured two models — Nemotron 3 Super and Nano — across three patterns: direct Ollama API call, OpenClaw CLI, and the web dashboard.
| Model | Direct Ollama API | OpenClaw CLI | Web Chat |
|---|---|---|---|
| Nano (30B / 3B active) | 0.6 seconds | 15 seconds | ~1 minute |
| Super (120B / 12B active) | 5 seconds | 14 seconds | ~5 minutes |
Both models are sufficiently practical when hitting the Ollama API directly. On the other hand, via the OpenClaw agent, it takes 14-15 seconds on CLI and 1-5 minutes on web chat. This is dominated not by model inference time but by the overhead of the agent framework itself — agent startup, plugin loading, multiple inference calls during planning, and so on.
Nemotron 3 Super supports the reasoning_effort parameter. It can be controlled via Ollama API's think parameter, and setting think: false skips reasoning token generation, speeding things up from 10 seconds to 5 seconds. However, disabling reasoning via the OpenClaw agent reduced the model's judgment capacity, increased the agent's planning loops, and actually slowed things down significantly from 14 seconds to 2 minutes 47 seconds. It seems keeping reasoning ON is the right call when using the agent.
Memory usage as checked by nvidia-smi showed Super using approximately 89,734 MiB (about 87.6GB) and Nano about 27GB. With DGX Spark's 128GB unified memory, Super runs fine, but if you're cohosting other services, Nano gives you more headroom.
If you just want to confirm it works, Super is fine, but for daily use as an agent, Nano will likely feel less stressful.
Summary
I tried everything on DGX Spark from installing NemoClaw Early Preview through running the agent.
Looking back at what worked: the OpenShell sandbox built without issues on the ARM64 DGX Spark, the agent ran with local inference via Ollama, and network isolation functioned properly as well. You can chat from the dashboard Web UI, and command-line execution is also supported. I confirmed that NemoClaw's concept of "a locally self-contained secure agent environment" can be realized on DGX Spark.
On the other hand, there were some rough edges typical of an Early Preview. Origin errors when accessing remotely, the port forward going dead, being required to provide an NVIDIA API Key even for local use — there are quite a few pain points that aren't obvious from the documentation alone. Referring to spark-install.md in the repository alongside the DGX Spark Playbook should help things go considerably more smoothly.
On performance — the fact that even the 120B Super model "works" is thanks to DGX Spark's 128GB unified memory, but if you prioritize the agent experience, Nano is more practical. That said, there seems to be room for improvement as the agent framework side gets optimized.
NemoClaw is still at the Early Preview stage, but I have a feeling that OpenShell's security model (out-of-process policy enforcement) will become a very powerful foundation when it reaches GA. It's reassuring that a "sandbox you can safely experiment with" like this can run on hardware you have on hand, as we head into an era where agentic AI is seriously deployed in enterprise settings.
Reference Links
Official Documentation
- NVIDIA NemoClaw Product Page
- NemoClaw Developer Guide
- NemoClaw Architecture Reference
- GitHub - NVIDIA/NemoClaw
- DGX Spark Playbooks - NemoClaw
- OpenShell Technical Blog
