How NemoClaw Works

NemoClaw combines a lightweight CLI plugin with a versioned blueprint to move OpenClaw into a controlled sandbox. This page explains the key concepts about NemoClaw at a high level.

How It Fits Together

The nemoclaw CLI is the primary entrypoint for setting up and managing sandboxed OpenClaw agents. It delegates heavy lifting to a versioned blueprint, a Python artifact that orchestrates sandbox creation, policy application, and inference provider setup through the OpenShell CLI.

flowchart TB
    subgraph Host
        CMD["nemoclaw onboard"]
        PLUGIN[nemoclaw plugin]
        BLUEPRINT[blueprint runner]
        CLI["openshell CLI sandbox · gateway · inference · policy"]

        CMD --> PLUGIN
        PLUGIN --> BLUEPRINT
        BLUEPRINT --> CLI
    end

    subgraph Sandbox["OpenShell Sandbox"]
        AGENT[OpenClaw agent]
        INF[NVIDIA inference, routed]
        NET[strict network policy]
        FS[filesystem isolation]

        AGENT --- INF
        AGENT --- NET
        AGENT --- FS
    end

    PLUGIN --> AGENT

    classDef nv fill:#76b900,stroke:#333,color:#fff
    classDef nvLight fill:#e6f2cc,stroke:#76b900,color:#1a1a1a
    classDef nvDark fill:#333,stroke:#76b900,color:#fff

    class CMD,PLUGIN,BLUEPRINT nvDark
    class CLI nv
    class AGENT nv
    class INF,NET,FS nvLight

    style Host fill:none,stroke:#76b900,stroke-width:2px,color:#1a1a1a
    style Sandbox fill:#f5faed,stroke:#76b900,stroke-width:2px,color:#1a1a1a

Design Principles

NemoClaw architecture follows the following principles.

Thin plugin, versioned blueprint : The plugin stays small and stable. Orchestration logic lives in the blueprint and evolves on its own release cadence.

Respect CLI boundaries : The nemoclaw CLI is the primary interface. Plugin commands are available under openclaw nemoclaw but do not override built-in OpenClaw commands.

Supply chain safety : Blueprint artifacts are immutable, versioned, and digest-verified before execution.

OpenShell-native for new installs : For users without an existing OpenClaw installation, NemoClaw recommends openshell sandbox create directly rather than forcing a plugin-driven bootstrap.

Reproducible setup : Running setup again recreates the sandbox from the same blueprint and policy definitions.

Plugin and Blueprint

NemoClaw is split into two parts:

• The plugin is a TypeScript package that powers the nemoclaw CLI and also registers commands under openclaw nemoclaw. It handles user interaction and delegates orchestration work to the blueprint.
• The blueprint is a versioned Python artifact that contains all the logic for creating sandboxes, applying policies, and configuring inference. The plugin resolves, verifies, and executes the blueprint as a subprocess.

This separation keeps the plugin small and stable while allowing the blueprint to evolve on its own release cadence.

Sandbox Creation

When you run nemoclaw onboard, NemoClaw creates an OpenShell sandbox that runs OpenClaw in an isolated container. The blueprint orchestrates this process through the OpenShell CLI:

1. The plugin downloads the blueprint artifact, checks version compatibility, and verifies the digest.
2. The blueprint determines which OpenShell resources to create or update, such as the gateway, inference providers, sandbox, and network policy.
3. The blueprint calls OpenShell CLI commands to create the sandbox and configure each resource.

After the sandbox starts, the agent runs inside it with all network, filesystem, and inference controls in place.

Inference Routing

Inference requests from the agent never leave the sandbox directly. OpenShell intercepts every inference call and routes it to the configured provider. NemoClaw routes inference to NVIDIA cloud, specifically Nemotron 3 Super 120B through build.nvidia.com. You can switch models at runtime without restarting the sandbox.

Network and Filesystem Policy

The sandbox starts with a strict baseline policy defined in openclaw-sandbox.yaml. This policy controls which network endpoints the agent can reach and which filesystem paths it can access.

• For network, only endpoints listed in the policy are allowed. When the agent tries to reach an unlisted host, OpenShell blocks the request and surfaces it in the TUI for operator approval.
• For filesystem, the agent can write to /sandbox and /tmp. All other system paths are read-only.

Approved endpoints persist for the current session but are not saved to the baseline policy file.

Next Steps

• Follow the Quickstart to launch your first sandbox.
• Refer to the Architecture for the full technical structure, including file layouts and the blueprint lifecycle.
• Refer to Inference Profiles for detailed provider configuration.