NemoClaw on DGX Spark

1 Installation

The official command is simple, but on the DGX Spark there's a prerequisite you need to know about.

The problem: npm permissions

The command curl -fsSL https://nvidia.com/nemoclaw.sh | bash fails if npm tries to write to /usr/lib/node_modules/. Using sudo for this is out of the question.

# 1. Create a global npm folder in your home
mkdir -p ~/.npm-global

# 2. Configure npm to use it
npm config set prefix ~/.npm-global

# 3. Add the bin to PATH (persistent)
echo 'export PATH=~/.npm-global/bin:$PATH' >> ~/.bashrc
source ~/.bashrc

# 4. Run the NemoClaw install (no sudo)
curl -fsSL https://nvidia.com/nemoclaw.sh | bash

Never need sudo for npm install -g again.

2 Port 8080 & the Cloudflare Tunnel

NemoClaw uses port 8080 to expose the OpenClaw service. Important to know before installation.

What NemoClaw does with port 8080

NemoClaw launches the OpenShell gateway on port 8080 (HTTPS). It's the main entry point: the dashboard, the API, and WebSocket connections all go through this port. If another service is already using it on your machine, the installation will fail with the error Port 8080 is not available.

The Cloudflare tunnel: remote access

Once installed, nemoclaw start automatically launches an ephemeral Cloudflare tunnel (trycloudflare.com) that exposes your dashboard on a public URL:

The URL changes with every nemoclaw start. To get a fixed URL (essential if you want to control the agent from Telegram, Discord, etc.), you can set up a permanent Cloudflare tunnel on your own domain — exactly like for any self-hosted service.

My choice: test locally first

I preferred to start by testing with local access to OpenClaw on localhost, via an SSH tunnel from my Mac:

ssh -L 18789:127.0.0.1:18789 -L 8080:127.0.0.1:8080 -N -f spark

Then open http://127.0.0.1:18789 in the browser. Simple, secure, no need for a Cloudflare tunnel to explore the dashboard.

Also, you need to forward both ports (18789 for the dashboard AND 8080 for the gateway) otherwise the dashboard loads but stays stuck on "Disconnected from gateway".

3 The install.sh Script

The URL nvidia.com/nemoclaw.sh redirects to GitHub. Here's what it actually does.

First launch — error "Port 8080 is not available"

4 Onboarding in 7 Steps

Once the script finishes, nemoclaw onboard takes over with an interactive assistant.

1. Preflight checks — Verifies Docker, installs openshell CLI v0.0.12, detects the GPU (1 GPU, 124,610 MB VRAM)
2. Starting OpenShell gateway — Launches the gateway on port 8080 (HTTPS)
3. Creating sandbox — Builds a Docker image in 22 steps (node:22-slim + Python 3 + deps). Image size: 1545 MiB
4. Configuring inference (NIM) — Requests the NVIDIA API key (nvapi-*), stored in ~/.nemoclaw/credentials.json (mode 600)
5. Setting up inference provider — Cloud model selection. 6 options including Nemotron 3 Super 120B
6. Setting up OpenClaw inside sandbox — Launches the internal gateway within the sandbox
7. Policy presets — Configures sandbox network access (npm, pypi, slack, telegram, discord, etc.)

Successful launch after freeing port 8080

Model selection (Nemotron 3 Super 120B) and policy preset configuration

5 The Model: Cloud by Default, Local Possible

Important point: by default, the LLM powering the agent does NOT run on the DGX Spark. But you can change that.

Model selection at installation

At step [5/7] of the onboarding, NemoClaw asks for an NVIDIA API key (generated at build.nvidia.com/settings/api-keys, format nvapi-*) then offers 6 cloud models:

I chose Nemotron 3 Super 120B (the default). Here are its specs:

How it works in practice

The agent sends its prompts to the inference.local route, which is actually a proxy to the integrate.api.nvidia.com API. The model runs on NVIDIA's GPUs in the cloud, not on your DGX Spark. The API key authenticates the requests, and costs are currently included (shown as 0 in the Usage dashboard).

What about local? It works!

I tested it: the DGX Spark can run Nemotron 3 Super 120B locally via Ollama, entirely on the GPU. The model (86 GB in Q4 quantization) fits comfortably in the 128 GB of unified memory.

Surprise: the Super (120B) is faster than the Nano (30B)! This is thanks to the Mixture-of-Experts architecture — only 12B parameters are active per forward pass, making it more efficient than the dense Nano (30B active).

Switching cloud / local

The switch is done with a single command, no restart needed:

# Switch to local (Nemotron 3 Super on GPU)
openshell inference set --provider ollama-local --model nemotron-3-super --no-verify

# Switch back to NVIDIA cloud
openshell inference set --provider nvidia-nim --model nvidia/nemotron-3-super-120b-a12b --no-verify

# Check which model is active
openshell inference get

Fun fact: the model doesn't know itself

Amusing detail: when you ask Nemotron 3 Nano "what model are you?", it answers "Nemotron 3 Super 120B, a dense model with 120 billion parameters." Everything is wrong: it's not the Super, it's not dense, and it doesn't have 120B parameters. The real Super at least knows its name but also hallucinates about its specs. LLMs don't know themselves!

6 Architecture

NemoClaw is a matryoshka: a container inside a Kubernetes cluster inside Docker.

7 Running Processes

A ps aux | grep claw reveals 6 interconnected processes.

8 Inside the Sandbox

nemoclaw dgx-assistant connect gives you a shell into the isolated environment.

Connecting to the sandbox — home /sandbox with .nemoclaw, .openclaw, .npm

9 Accessing the Dashboard

The OpenClaw dashboard runs inside the sandbox. Two ways to access it:

# Forward BOTH ports (dashboard + gateway)
ssh -L 18789:127.0.0.1:18789 -L 8080:127.0.0.1:8080 -N -f spark

# Open in the browser (127.0.0.1, NOT localhost!)
open http://127.0.0.1:18789

10 Overview

Main dashboard: health, connection, counters.

Status OK, uptime 2h, 1 active session, cron enabled. This is where you enter the token to connect to the gateway via WebSocket.

11 Chat

Direct conversation interface with the agent, real-time in the browser.

Here you can see the heartbeat session: every 30 minutes, the agent reads HEARTBEAT.md and responds HEARTBEAT_OK if nothing needs attention. It's the agent's pulse.

12 Channels — 8 Platforms

The most impressive feature: control the agent from any messaging platform.

13 Instances

Who is currently connected to the gateway.

Two instances: the gateway itself (dgx-assistant, Linux arm64, kernel 6.17) and our browser (openclaw-control-ui, operator role with admin/approvals/pairing rights).

14 Sessions

Fine-grained management of conversation sessions and their settings.

Per session, you can adjust the Thinking level (off to xhigh), Verbose mode, and Reasoning. This is the behavioral fine-tuning of the agent.

15 Usage

Token consumption and cost tracking.

Time filters, tokens/cost view, export. With Nemotron via NIM, costs show 0 — NVIDIA cloud inference is included.

16 Cron Jobs

Schedule automated tasks with delivery to any channel.

Create jobs with a schedule (every/at/cron), session choice (main or isolated), execution mode, timeout, and delivery (announce in chat, webhook POST, or internal). For example, you can schedule a daily brief sent to Telegram.

17 Agents

Workspace, identity, and model configuration for the agent.

A "main" agent with the Nemotron 3 Super 120B model (131K context). Sub-tabs: Overview, Files, Tools, Skills, Channels, Cron Jobs.

18 Tools — 25 Tools

The agent's arsenal, all enabled by default ("full" profile).

19 Skills — 51 Capabilities

From GitHub to Spotify, including Philips Hue lights and Eight Sleep beds.

Immediately available skills (3)

Full catalog of 51 skills

A word on skill security

In practice, the skills fall into three trust levels:

Additionally, a known vulnerability (Issue #272) means policy presets lack a binaries: field — which means any process in the sandbox can use the allowed endpoints, not just the intended binary. Keep this in mind if you enable skills that access sensitive services.

In summary: treat each skill as you would treat a plugin in any ecosystem — check what it installs and what it accesses before enabling it.

20 Nodes & Security

Access control, paired devices, and execution policies.

By default: Deny mode with Ask on miss. The agent asks for confirmation before executing an unexpected command. Secure by design.

21 Config

Full visual editor for the openclaw.json file.

11 categories: Environment, Updates, Agents, Authentication, Channels, Messages, Commands, Hooks, Skills, Tools, Gateway. Form mode or Raw JSON.

22 Debug & Logs

For power users: JSON snapshots, manual RPC, and live logs.

90+ RPC methods available: chat.send, cron.add, config.patch, sessions.list, skills.install, tts.convert, browser.request...

Real-time logs with level filters (trace to fatal), auto-follow, search, and export. JSONL format with complete metadata.

23 In Practice: "Install a Music Generator for Me"

To test the agent under real-world conditions, I asked it to install a local music generation model. The result is very instructive.

What the agent did (in ~7 minutes)

The agent explores the environment, runs nvidia-smi, detects sandbox constraints

The agent's verdict

The sandbox proxy blocks PyPI access — the policy system is doing its job

What this teaches us

The agent is impressive: in 7 minutes, with no help, it identified the right project (AudioCraft/MusicGen from Meta), cloned the repo, created a Python virtualenv, read the documentation, and attempted the installation. When it hit a wall, it cleanly diagnosed all 3 causes and proposed solutions.

The sandbox does its job: network policies prevent the agent from installing anything from the Internet. This is security by design — no sudo, no free access to PyPI, no visibility into the host GPU. To go all the way, you'd need to properly configure the proxy to allow pypi.org and download.pytorch.org in the policies.

Second attempt: the PyPI bug confirmed

After investigating, I discovered that the PyPI blockage is a known bug in NemoClaw (Issue #481 on GitHub). The pypi preset is marked as "applied" in NemoClaw, but the rules are never actually propagated to the sandbox proxy.

I tried several approaches:

1. Re-apply the pypi preset via nemoclaw policy-add → preset marked OK, but proxy still returns 403
2. Apply a custom YAML policy via openshell policy set with pypi.org and files.pythonhosted.org → says "loaded" but hosts unchanged
3. Recreate the sandbox from scratch via nemoclaw onboard → same result on a fresh sandbox

Same error on a freshly created sandbox — the bug is confirmed (Issue #481)

Checking the GitHub issues confirms this is a known problem, reported by other users on macOS and WSL2. NemoClaw is in alpha ("single-player mode") and this type of bug is expected at this stage.

Conclusion: Promising, but Not Yet Ready for Blind Trust

After several hours of intensive exploration, here's my honest assessment.

What's impressive

NemoClaw is a complete autonomous AI agent platform: multi-channel (WhatsApp, Telegram, Discord, Slack, Signal, iMessage, Google Chat, Nostr), 25 tools, 51 skills, cron jobs, web dashboard, and a secure sandbox architecture. The Nemotron 3 Super 120B model runs at 17.6 tokens/second entirely locally on the DGX Spark's GPU — zero cloud dependency, zero cost. The cloud/local switch is done with a single command, no restart needed.

What raises questions

My verdict

NemoClaw is super promising. The combination of a free open-source model (Nemotron 3 Super 120B via NVIDIA NIM, or locally on the GPU), a complete autonomous agent platform (OpenClaw), and an innovative security layer (OpenShell) is unique on the market. The DGX Spark is the ideal machine for this — 128 GB of unified memory, the model fits entirely in GPU memory, and the performance delivers.

But you can't blindly trust it yet. The design vulnerabilities (policies that don't propagate, unaudited third-party skills, no granular per-action control) are too critical for production use or with sensitive data. Plugging your password manager and your emails into an autonomous agent whose security barriers don't fully work yet would be reckless.

What if you do everything yourself?

You might think: if I create my own skills (email access, credential storage), run the model locally, and don't install any third-party skills — the risk disappears, right?

That's significantly better, indeed. Local model + homemade skills + no public tunnel = issues #272 and #481 become moot. But there remains a fundamental problem that even a perfect version of NemoClaw couldn't solve:

So, what do we do?