NemoClaw practical guide for secure OpenClaw operations in 2026

Most AI agent stacks still treat security as a post-demo fix.
NemoClaw starts from the opposite assumption and makes isolation, policy, and routing day-zero defaults.

OpenClaw stays the assistant while OpenShell stays the enforcement layer, and NemoClaw acts as the opinionated glue between them. That glue matters because it makes the safer path easier to install, easier to observe, and much harder to skip when you are rushing.

That is exactly why NemoClaw matters in 2026. It is not just another wrapper around an LLM agent, because it is designed as a reference stack for running always-on OpenClaw assistants inside sandboxed OpenShell containers, with routed inference, policy-based egress control, and lifecycle tooling built in from day one. If you want broader context for where this fits, start with the AI Systems hub and the baseline OpenClaw system overview.

There is one hard truth you should not bury for the sake of hype. NVIDIA marks NemoClaw as alpha software in early preview, beginning March 16, 2026, and explicitly warns that interfaces and behavior may still shift between releases. Treat it like a serious lab tool, not finished production furniture.

What NemoClaw is and when to use it

NemoClaw exists for a specific operational job rather than for experimentation theater. It gives you a practical way to run an always-on OpenClaw assistant with guardrails around network access, filesystem access, process privileges, and model routing. If you have ever looked at an autonomous agent and thought that it should not have casual host access, NemoClaw is a strong answer to that discomfort.

The stack is easier to understand when you separate the layers:

• OpenClaw is the assistant runtime, tools, memory, and behaviour inside the container.
• OpenShell is the execution environment that provides sandbox lifecycle, credential-storing gateway, inference proxying, and policy enforcement.
• NemoClaw is the opinionated reference stack that onboards, configures, and operates OpenClaw correctly inside OpenShell.

That distinction matters because it explains the product's purpose. NemoClaw is not trying to replace OpenClaw. It is trying to make OpenClaw survivable in real environments.

Typical use cases are obvious and sensible:

• running an always-on assistant with controlled egress
• testing agent behaviour before granting broader access
• pushing a sandboxed assistant onto a remote GPU host for persistent operation

My blunt take is this. If you only want a throwaway demo, raw OpenClaw is simpler and faster to get moving, and the OpenClaw quickstart is the fastest route. If you want something that behaves like it belongs on an actual machine, NemoClaw is the more serious choice because its defaults are built for operators instead of screenshots.

NemoClaw security and operations features that matter

A long feature list is cheap. The right feature list is not. These are the capabilities that actually change how you operate the system.

NemoClaw supports several inference paths, including NVIDIA Endpoints, OpenAI, Anthropic, Google Gemini, compatible OpenAI style and Anthropic style endpoints, and local Ollama. For compatible endpoints, onboarding validates the endpoint with a real inference request because many services copy the OpenAI shape but fail on real runtime behavior. If you are choosing an inference runtime strategy first, the broader LLM hosting guide for 2026 is a useful companion. Experimental local NIM and local vLLM paths also exist, but they are gated behind an environment flag for a reason, so use them for evaluation instead of unattended long-running workloads.

The security model is the real headline. NemoClaw starts with deny-by-default egress, keeps provider credentials on the host, uses a read-only OpenClaw config inside the sandbox, and lets operators review unknown network requests in the OpenShell TUI. This is not flashy, but that is exactly the point, because flashy agent stacks are common while boring control surfaces are the scarce resource in production.

The defaults you should not casually relax

NemoClaw does have escape hatches. It also tells you, very politely, when you are about to do something foolish.

The biggest foot-guns are these:

• --dangerously-skip-permissions trades the default sandbox posture for a permissive one
• adding permanent baseline policy entries for one-off requests makes privilege creep feel normal
• writing directly into /sandbox/.openclaw is the wrong mental model because that config is meant to stay locked down
• using openclaw agent --local as if it were your standard operating mode is a bad habit for anything security-sensitive

That last point deserves emphasis. Local mode is convenient for smoke testing and one-off checks, but it is not the posture you should normalize for an always-on assistant that has any real permissions.

NemoClaw quickstart for your first sandbox

Prerequisites

Here is the practical baseline before you waste an afternoon pretending a tiny laptop is enough. The official prerequisites page currently lists Node.js 22.16 or later and npm 10 or later in addition to Docker runtime requirements.

The tested runtime matrix is also straightforward:

If you are on macOS, install Xcode Command Line Tools first. If you are on Linux, make sure Docker is actually running and that your user can talk to it without permission drama.

There is also a resource detail that catches many first-time users. The sandbox image is around 2.4 GB compressed, and the export pipeline can temporarily consume enough memory to trigger OOM on weak machines. If you cannot add RAM, adding at least 8 GB swap is an official workaround, though it slows onboarding. For small dedicated AI boxes, the NVIDIA DGX Spark overview gives a concrete reference point for local always-on deployments.

Install and onboard

The official install path is intentionally simple:

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

Then confirm the CLI is present:

nemoclaw --help
nemoclaw --version

From there, the real work is onboarding. nemoclaw onboard drives sandbox creation, provider setup, and policy application in one guided flow, which is why it should be your default lifecycle entry point.

nemoclaw onboard

During onboarding you will choose an inference provider, a sandbox name, and a policy tier. The tier choice matters more than most people expect:

• restricted keeps the base sandbox only
• balanced is the default and adds development tooling plus web search related access
• open adds broad third-party access, including messaging and productivity services

My recommendation is not subtle. For an always-on assistant, start with the smallest posture that can possibly work. If that means restricted, good. Add only what the agent proves it needs.

If you want a scripted run, the non-interactive flow looks like this:

NEMOCLAW_POLICY_TIER=restricted \
nemoclaw onboard --non-interactive --yes-i-accept-third-party-software

Use a sane sandbox name. NemoClaw expects lowercase alphanumeric characters and hyphens. If you keep trying to be clever with names, the validator will win.

First connection and first prompt

Once onboarding completes, connect to the sandbox:

nemoclaw my-assistant connect

Inside the sandbox, open the terminal UI:

openclaw tui

If you only want a one-message smoke test, you can do this:

openclaw agent --agent main --local -m "hello" --session-id test

That said, do not confuse a smoke test with an operating model. For real day-two usage, I would rather stay honest about the system and use the TUI plus host-side monitoring instead of normalising --local.

NemoClaw operations that matter on day two

Once the sandbox exists, NemoClaw becomes an operations tool, not just an installer. These are the commands that pull their weight.

Changing network access after onboarding

This is where NemoClaw is noticeably better than ad hoc agent setups. Instead of loosening all controls after the first block, you can keep a constrained baseline and then approve or persist only what is necessary.

For one-off blocked destinations, use the TUI:

openshell term

That lets you review host, port, binary, and method or path information when available. Approved requests stay available for the current session, but they do not become permanent baseline policy. That is a feature, not a bug.

For durable changes, add or remove presets:

nemoclaw my-assistant policy-add github --yes
nemoclaw my-assistant policy-remove github --yes

If you need something more specific than a stock preset, define a custom policy entry and keep protocol: rest with method and path restrictions for HTTP APIs whenever possible. L4-only rules are a compromise. Pretending otherwise just makes bad policy look neat.

Switching models without rebuilding your whole life

If you are staying within the same provider family, model changes are simple:

openshell inference set --provider openai-api --model <model>

Then verify the result:

nemoclaw my-assistant status

If you are switching across provider families, the story gets more opinionated. You are not just flipping a runtime pointer. You are changing the route and some baked image configuration. In practice, that means you should treat the change like a real reconfiguration and rerun onboarding or recreate the sandbox with the appropriate overrides.

Cost is another practical reason to keep this workflow clean. Public pricing pages in April 2026 show large spreads between model tiers, such as GPT-5.4 mini at low single-digit dollars per million output tokens versus premium frontier tiers that cost an order of magnitude more. Anthropic pricing similarly ranges from Haiku class to Opus class, and the wider pricing shift is covered in Claude, OpenClaw, and the End of Flat Pricing for Agents. If you need a practical playbook for spending less under these conditions, see token optimization strategies for LLM cost control, because being able to switch models without policy chaos is an operational advantage, not just a convenience.

Understanding what persists and what does not

The useful state lives in the workspace under /sandbox/.openclaw/workspace/. That includes files such as AGENTS.md, IDENTITY.md, MEMORY.md, SOUL.md, USER.md, and the memory/ directory of daily notes. If you are designing longer-lived assistants, the AI Systems Memory hub and agent memory provider comparison are useful next reads.

The good news is that sandbox restarts preserve this state. The bad news is that nemoclaw destroy does not care about your feelings. Destroying the sandbox deletes its persistent volume and your workspace goes with it.

That is why the rebuild and snapshot flows matter. NemoClaw is usable precisely because it does not force you to choose between upgrading and losing the assistant's memory.

The rule everyone learns late

Here is the rule that saves the most time once you internalize it. A surprising amount of NemoClaw configuration is build-time or image-time configuration, not live mutable state.

That explains several behaviours that confuse new users:

• messaging channels are baked into the image and host-side commands rebuild the sandbox when channels change
• the OpenClaw config path inside the sandbox is read-only
• some auth, proxy, and port settings require re-onboarding or sandbox recreation
• editing the right host-side state is usually the correct move, while editing from inside the sandbox is usually the wrong one

Once you accept that model, the platform stops feeling random and starts feeling deliberate.

NemoClaw troubleshooting that actually saves time

Install and platform problems

Runtime and policy problems

If the agent cannot reach an external host, the first answer is usually not that the provider is broken. The first answer is usually that the destination is not allowed by policy yet, especially on new sandboxes.

Open the TUI:

openshell term

If the request is legitimate, approve it for the session or add the correct preset or custom policy entry permanently.

If onboarding fails because port 18789 is taken, find and kill the conflict:

sudo lsof -i :18789
kill <PID>

If an older release left an orphaned SSH forward behind after a destroy, current NemoClaw versions can clean that up automatically during re-onboard. Older ones may need the manual kill.

If the dashboard does not load after setting NEMOCLAW_DASHBOARD_PORT, rerun onboarding on a current release with the desired port. Older builds had a bug where the host respected the custom port but the sandbox still listened on the default one.

Memory, rebuilds, and channels

If sandbox creation dies with exit code 137, you probably hit an out-of-memory condition during the image push path. Add swap or use a machine with more RAM. The cheap machine was not actually cheap if it cost you a day.

Before risky changes, snapshot first:

nemoclaw my-assistant snapshot create --name before-upgrade

If you need to upgrade the sandbox but keep the assistant state, rebuild instead of destroy:

nemoclaw my-assistant rebuild --yes

If you rotate Telegram, Discord, or Slack tokens, rerun onboarding so NemoClaw can detect the credential change and recreate the sandbox correctly.

And if you try to fix channels from inside the sandbox with openclaw channels commands, stop. Channel config is baked into the image and the config path is read-only. Use the host-side commands instead:

nemoclaw my-assistant channels add telegram
nemoclaw my-assistant channels remove telegram
nemoclaw my-assistant channels stop telegram
nemoclaw my-assistant channels start telegram

Inference and local model pain

Compatible endpoints are the classic source of false confidence. Just because a server exposes an OpenAI-looking API does not mean it supports the streaming behaviour OpenClaw expects.

If onboarding succeeded but runtime calls fail on a compatible endpoint, rerun onboarding and let NemoClaw re-probe the endpoint. Do not assume a config override alone is enough.

For local backends, keep an eye on health and binding issues:

nemoclaw my-assistant status

If local inference health checks look wrong on older releases, IPv6 versus IPv4 resolution may be the culprit. If Ollama behaves badly in WSL, make sure Docker Desktop integration is working and consider increasing OLLAMA_CONTEXT_LENGTH before restarting ollama serve.

If all else fails, collect diagnostics instead of guessing:

nemoclaw debug --sandbox my-assistant --output ./nemoclaw-debug.tar.gz

That is a much better bug report than a screenshot of a half-visible terminal.

Should you use NemoClaw in 2026

NemoClaw is opinionated in the right places. It assumes that an always-on agent should begin inside a cage, that inference credentials should stay on the host, and that network access should be earned rather than assumed. For this class of tooling, that philosophy is still the right default.

It is also still alpha. That means rough edges are real, the runtime model takes time to learn, and the issue you hit may genuinely be a product issue rather than operator error. If you are honest about that constraint, the stack is usable today for serious evaluation and controlled internal workloads.

My recommendation is simple. Use NemoClaw if you care about secure-by-default agent operations, want a clearer separation between assistant and enforcement layer, and are willing to operate within a deliberate lifecycle. If you only want the fastest possible demo, there are simpler toys, but if you want a safer long-running stack, NemoClaw is one of the most convincing options available right now. Once you are stable, the practical follow-on is OpenClaw production setup patterns with plugins and skills, which maps day-to-day operating models. At that stage, add formal monitoring with LLM inference observability using Prometheus and Grafana so operations do not depend on terminal intuition alone.