NemoClawThis page explains how NemoClaw runs supported agents inside an OpenShell sandbox and how the gateway connects the agent to inference, integrations, and policy.
NemoClaw does not replace OpenShell or your chosen agent runtime. It packages them into a repeatable setup with a host CLI, a versioned blueprint, default policies, inference setup, and state helpers.
Hermes sandboxes receive agent configuration under /sandbox/.hermes during onboarding instead of the OpenClaw plugin path.
You can use that setup directly or adapt it for your own OpenShell integration.
NemoClaw keeps the user workflow on the host while OpenShell enforces the sandbox boundary. The gateway sits between NemoClaw control, the sandbox, inference providers, and external integrations. That placement lets NemoClaw configure the environment without giving the agent direct access to host credentials or uncontrolled network egress.
The diagram has the following components:
For repository layout, file paths, and deeper diagrams, see Architecture.
NemoClaw follows these architecture principles.
Versioned blueprint : Host-side orchestration uses a versioned blueprint and runner that can evolve on its own release cadence. The OpenClaw sandbox plugin stays small and stable inside the container.
Respect CLI boundaries
: The nemoclaw CLI is the primary interface for sandbox management.
Supply chain safety : Blueprint artifacts are immutable, versioned, and digest-verified before execution.
OpenShell-backed lifecycle
: NemoClaw orchestrates OpenShell resources under the hood, but nemoclaw onboard is the supported operator entry point for creating or recreating NemoClaw-managed sandboxes.
Reproducible setup : Running setup again recreates the sandbox from the same blueprint and policy definitions.
NemoClaw is split into integration pieces on the host and in the sandbox image:
The host CLI runs onboarding, validates provider choices, stores configuration, and calls OpenShell commands for gateway, provider, sandbox, and policy operations.
NemoClaw writes Hermes runtime configuration into /sandbox/.hermes during onboarding, including config.yaml, environment files, and platform adapter settings for supported messaging channels.
The blueprint is a versioned YAML package with the sandbox image, policy, inference profile, and supporting assets. The runner resolves and verifies the blueprint before applying it through OpenShell.
This separation keeps agent-specific sandbox assets focused while allowing host orchestration and blueprint contents to evolve on their own release cadence.
When you run nemoclaw onboard, NemoClaw creates an OpenShell sandbox that runs your selected agent in an isolated container.
The host CLI and blueprint runner orchestrate this process through the OpenShell CLI:
After the sandbox starts, the agent runs inside it with all network, filesystem, and inference controls in place.
Inference requests from the agent never leave the sandbox directly.
OpenShell intercepts every inference call and routes it to the configured provider.
During onboarding, NemoClaw validates the selected provider and model, configures the OpenShell route, and bakes the matching model reference into the sandbox image.
The sandbox then talks to inference.local, while the host owns the actual provider credential and upstream endpoint.
If you select the Model Router provider, inference.local routes to a host-side router that chooses from the configured NVIDIA model pool for each request.
For Hermes, runtime model switches through nemoclaw inference set update /sandbox/.hermes/config.yaml without rebuilding the sandbox.
The sandbox starts with a default policy that controls network egress, filesystem access, process privileges, and inference routing.
When the agent tries to reach an unlisted host, OpenShell blocks the request and surfaces it in the TUI for operator approval. Approved endpoints persist for the current session but are not saved to the baseline policy file.
