NemoHermes CLI Commands Reference

View as Markdown

The nemohermes alias is the primary interface for managing Hermes sandboxes through NemoClaw. It is installed automatically by the installer (curl -fsSL https://www.nvidia.com/nemoclaw.sh | NEMOCLAW_AGENT=hermes bash). Most commands in this reference use the same arguments and subcommands across agent variants. Use nemohermes when you want Hermes selected by default. For guidance on choosing between the agent CLIs and the underlying openshell CLI, refer to CLI Selection Guide.

Agent Selection

Use nemohermes for the Hermes variant. It selects Hermes by default during onboarding and for other commands. Use --agent hermes during onboarding or set NEMOCLAW_AGENT=hermes when you need the same selection through another entry point. Hermes-specific sections below describe the built-in Hermes dashboard, the separate OpenAI-compatible API endpoint, Hermes config under /sandbox/.hermes, and provider updates that patch config.yaml.

$nemohermes onboard # selects Hermes by default
$nemohermes my-sandbox connect # connects to a Hermes sandbox

In-Sandbox Commands

Hermes does not use the OpenClaw chat slash command. Use the host-side nemohermes commands for lifecycle, status, policy, and inference operations. The in-sandbox Hermes integration installs the NemoClaw Hermes plugin, which exposes tools for status, environment information, and skill reload support, plus an on_session_start hook.

Hosted Installer Options

The hosted installer accepts options after bash -s --. These options control installation and the onboarding run that follows it.

--local-model-runtime=vllm

Enable the fixed vLLM local model profile. The flag accepts only vllm. It makes the remaining onboarding non-interactive and disables Express profile selection.

$curl -fsSL https://www.nvidia.com/nemoclaw.sh | \
> NEMOCLAW_AGENT=hermes \
> NEMOCLAW_SANDBOX_NAME=my-assistant \
> NEMOCLAW_ACCEPT_THIRD_PARTY_SOFTWARE=1 \
> bash -s -- --local-model-runtime=vllm

The profile selects a fixed catalog model and serving command from the managed-inference catalog. The hosted installer rejects NEMOCLAW_PROVIDER and NEMOCLAW_MODEL before onboarding. The dedicated vLLM onboarder accepts NEMOCLAW_VLLM_MODEL only when the catalog resolves it to the matching fixed recipe. It rejects a model that does not resolve to that recipe and all NEMOCLAW_VLLM_EXTRA_ARGS_JSON values before it installs vLLM. Set NEMOCLAW_VLLM_PORT before installation to publish the fixed serving recipe on another host port.

The hosted installer’s equivalent environment-variable form requires both NEMOCLAW_ENABLE_LOCAL_MODEL_PROFILE=1 and NEMOCLAW_LOCAL_MODEL_RUNTIME. Use the installer flag unless an automation boundary cannot pass installer arguments. For prerequisites, effects, verification, and recovery, refer to Choose a Local Inference Server.

--defer-onboarding

Install Hermes without starting onboarding when NVIDIA hosted inference credentials are not yet available. The equivalent environment variable is NEMOCLAW_DEFER_ONBOARDING=1. The installer defers onboarding only when all these conditions apply:

  • NEMOCLAW_AGENT=hermes is set.
  • No sandbox is registered.
  • No supported NVIDIA inference credential is available.
  • No local model profile is selected.
  • NEMOCLAW_PROVIDER is unset or selects build, cloud, or routed.

If a supported credential or registered sandbox exists, the installer follows the normal onboarding or recovery path. When onboarding is deferred, the installer completes the software installation and reports that Hermes onboarding did not run. After credentials are available, run nemohermes onboard to create the sandbox.

$curl -fsSL https://www.nvidia.com/nemoclaw.sh | \
> NEMOCLAW_AGENT=hermes \
> bash -s -- --defer-onboarding

Hosted Installer Exit Statuses

The hosted installer reports how a run stopped through its exit status. When you interrupt it at a prompt, it exits 130, the same status that nemohermes onboard reports for that interrupt. An interrupted onboarding run still prints [ERROR] Onboarding did not complete successfully. before it exits, so read the exit status rather than that line. The installer preserves no other signal status, and a progress step stopped by SIGTERM also exits 130, so a script that stops the installer itself cannot read 130 as a deliberate interrupt. DGX Station host preparation exits 10 when it requires a reboot and 11 when it requires a new login session, and prints the command that resumes the install. Treat every other non-zero status as a failure.

Standalone Host Commands

The CLI handles host-side operations that run outside the selected agent runtime.

nemohermes help, nemohermes --help, nemohermes -h

Show the top-level usage summary and command groups. Running nemohermes with no arguments shows the same help output.

$nemohermes help

nemohermes --version, nemohermes -v

Print the installed NemoClaw CLI version.

$nemohermes --version

nemohermes completion

Generate a tab-completion script for Bash, Zsh, or Fish from the commands and flags available in the installed CLI. The script completes public global commands, the sandbox-first nemohermes <name> ... grammar, flags, shell choices, and locally registered sandbox names. If you omit the shell name, nemohermes completion detects the target from $SHELL and defaults to Bash when it cannot identify Zsh or Fish. The generated script is bound to the CLI name that created it, so install a separate script for each CLI alias you use. It loads sandbox names from the local registry the first time completion runs and caches them for the rest of that shell session.

For Bash, source the generated script and add the same line to ~/.bashrc for future sessions.

$source <(nemohermes completion bash)

For Zsh, source the generated script and add the same line to ~/.zshrc for future sessions.

1source <(nemohermes completion zsh)

For Fish, write the generated script to Fish’s completions directory.

1mkdir -p ~/.config/fish/completions
2nemohermes completion fish > ~/.config/fish/completions/nemohermes.fish

Start a new shell session to refresh the cached sandbox names after creating or removing a sandbox.

nemohermes resources

Display host hardware inventory and configured sandbox resource profiles. Use --json for machine-readable CPU, memory, GPU, Kubernetes allocatable-capacity, and profile data.

$nemohermes resources [--json]

If the gateway is not running, Kubernetes allocatable fields are omitted and host CPU/RAM totals are still shown.

nemohermes host probe

Inspect host capabilities and gateway authority before onboarding without changing host, Docker, gateway, credential, policy, or sandbox state. Use --json for the schema-versioned report. The command exits with 0 for supported, 2 for incompatible, and 3 for inconclusive.

$nemohermes host probe [--json]

For capability IDs, evidence bounds, and compatibility guidance, refer to System Readiness.

nemohermes agents list

List the installed agent runtimes that can be selected with nemohermes onboard --agent <name>. Use this global command when you need valid runtime names before creating or recreating a sandbox. It lists runtime names with the descriptions from their installed manifests.

$nemohermes agents list

Expected output:

openclaw Gateway-based AI agent with plugin ecosystem (openclaw.ai)
hermes Self-improving AI agent with learning loop (Nous Research)
langchain-deepagents-code Terminal coding agent built on the Deep Agents SDK

nemohermes profiles list

List the serving profiles installed with NemoClaw and evaluate them against the current host. The command reports each profile’s stable ID, display name, inference backend, model, topology, selection mode, support state, estimated downloads, and incompatibility reason. It reads the serving catalog and host readiness state without downloading a model or changing host, gateway, inference, or sandbox resources.

$nemohermes profiles list

Use --json for machine-readable output with the same profile fields.

$nemohermes profiles list --json

Use the stable id value with nemohermes onboard --profile <name>. Display names are accepted when they identify exactly one profile, but stable IDs are suitable for scripts and automation.

nemohermes onboard

Run the interactive setup wizard (recommended for new installs). The wizard creates an OpenShell gateway, registers inference providers, selects the exact managed image (or builds an explicit custom Dockerfile), and creates the sandbox. Use this command for new installs and for recreating a sandbox after changes to policy or configuration.

$nemohermes onboard [--profile <name>] [--non-interactive] [--resume | --fresh] [--recreate-sandbox] [--apf-interceptor] [--gpu | --no-gpu] [--from <Dockerfile>] [--name <sandbox>] [--host-mount <host:/sandbox/path>] [--sandbox-gpu | --no-sandbox-gpu] [--sandbox-gpu-device <device>] [--vllm-gpu-device <index-or-uuid>] [--agent <name>] [--agents <agents.yaml>] [--tool-disclosure <progressive|direct>] [--observability | --no-observability] [--control-ui-port <N>] [--events=jsonl] [--yes | -y] [--no-ollama-autostart] [--yes-i-accept-third-party-software]

For Hermes, use the alias or pass the agent explicitly:

$nemohermes onboard [options]
$nemoclaw onboard --agent hermes [options]

The experimental Portable Hermes path records pending, configuring, and active lifecycle phases under the current user’s rootless Podman authority. If onboarding stops in pending or configuring, correct the reported condition and run nemohermes onboard --experimental-profile portable --resume. Mutation, connection, and recovery commands do not act on an incomplete receipt; status and doctor report its phase. After the receipt reaches active, the supported runtime actions are launch, connect, recover, start, and stop; status and read-only doctor provide diagnostics. Other sandbox commands fail before their action runs while the Portable Hermes receipt exists. The supported commands revalidate the receipt-owned Podman container and do not fall back to Docker.

--agent accepts the canonical manifest names from nemohermes agents list plus common aliases. For example, nemohermes resolves to hermes, while dcode, deepagents, deepagents-code, and langchain resolve to langchain-deepagents-code.

--profile <name>

Select one serving profile from nemohermes profiles list for interactive or non-interactive onboarding. The flag is generic and does not add a model-specific command or flag. NemoClaw maps a unique display name to its stable catalog ID and passes that ID to the managed inference path.

$nemohermes onboard --profile <profile-id>

NemoClaw rejects an unknown, ambiguous, disabled, or incompatible profile before image or model downloads begin. It also rejects --profile when you combine it with NEMOCLAW_PROVIDER, NEMOCLAW_MODEL, NEMOCLAW_VLLM_MODEL, NEMOCLAW_MANAGED_CLUSTER_PEERS, or NEMOCLAW_VLLM_EXTRA_ARGS_JSON overrides. If NEMOCLAW_SERVING_PRESET is already set, it must select the same stable profile ID; a different ID conflicts with --profile. Run nemohermes profiles list to inspect an incompatibility reason before onboarding.

If you omit --profile, onboarding uses the same provider and model defaults as an installation without this feature. The onboarding review screen identifies the resolved profile, recipe, declared model, served model alias, runtime image, support state, and download estimates before confirmation. When onboarding reuses a running vLLM server, its /v1/models response must match the requested profile’s served alias or declared model root. Otherwise, onboarding stops before it records a route that the profile does not declare. After creation, human status shows the profile, recipe, and catalog digest; JSON status includes the complete secret-free servingProfileProvenance record for diagnostics and automation.

--host-mount

On Linux and Windows Subsystem for Linux 2 (WSL2), repeat --host-mount <absolute-host-directory:/sandbox/directory> to expose existing host directories read-only inside the sandbox. The option requires a NemoClaw-managed Docker-driver gateway and does not provide a read-write mode. Refer to Mount a Host Directory for Read-Only Access for validation rules, security considerations, persistence, and verification.

--events=jsonl

Emit a read-only stream of canonical onboarding FSM events as JSON Lines on stdout. Each line is one JSON object with the version 1 envelope:

1{
2 "schemaVersion": 1,
3 "session": "<session-id>",
4 "type": "state.entered",
5 "timestamp": "2026-07-13T12:34:56.789Z",
6 "payload": {
7 "state": "inference",
8 "step": "inference",
9 "context": {
10 "agent": "openclaw",
11 "sandboxName": "alpha",
12 "provider": "nvidia-prod",
13 "model": "nvidia/test-model",
14 "endpointOrigin": "https://integrate.api.nvidia.com",
15 "credentialEnv": "NVIDIA_API_KEY"
16 },
17 "error": null,
18 "metadata": {}
19 }
20}

In this mode, human progress remains available on stderr so stdout stays valid JSONL. Payloads contain only the existing bounded, redacted machine-event context: credential environment variable names may appear, but credential values and secret-bearing URL components are redacted. For a compatible-endpoint route that uses openai-completions, the context includes reasoningEffort as low, medium, high, or endpoint-default. Other provider and API-family routes omit this field. Treat new event type values and new payload fields as additive changes. A breaking envelope or field-semantics change increments schemaVersion.

This surface observes the canonical onboarding session and does not accept input, cancel onboarding, or create another state machine. It does not provide event history, reconnect, or replay; use the existing --resume behavior after an interrupted onboarding process. Closing the output pipe or applying sustained backpressure disables observation without cancelling, rolling back, or otherwise changing onboarding. Without --events=jsonl, terminal output and behavior are unchanged.

--resume and --fresh

NemoClaw records onboarding progress so interrupted runs can continue. Use --resume to continue a resumable onboarding session with the provider, model, sandbox name, agent, observability choice, custom Dockerfile path, read-only host-mount declarations, and any explicitly selected serving-profile provenance recorded by the original run. For a profile-backed session, resume requires the same catalog, preset, and recipe digests and exits before effects if the installed definition changed. Omit --profile to reuse that recorded selection, or pass the same profile explicitly; use --fresh to adopt a changed catalog definition. Sessions without a serving-profile provenance record can resume when their checkpoint uses schema 4, but they cannot acquire a new --profile selection during resume.

Checkpoint schema 4 records whether onboarding uses the default profile or the portable experimental profile. For the portable profile, it also records the current user’s canonical home reported by the operating system, that home’s exact .config directory, the runtime root, rootless Podman endpoint path, and runtime ownership. It does not record ambient Docker or Podman runtime selector values. The runtime authority record contains no credentials. A plain --resume restores the recorded profile. You can also run nemohermes onboard --experimental-profile portable --resume when the recorded profile is portable. NemoClaw rejects an explicit profile that conflicts with the checkpoint before it changes portable configuration, activates the user-scoped Podman socket, or changes gateway and sandbox resources.

Portable resume derives DOCKER_HOST, CONTAINERS_CONF, and NETAVARK_FW again while it holds the onboarding lock. It ignores ambient Docker and Podman runtime selectors during that derivation. NemoClaw scopes the derived values to onboarding and restores the process environment after success or failure. It verifies the current user, canonical roots, socket path and ownership, Podman identity and version, and required configuration before a resumed onboarding step changes resources. Resume stops before writes or activation if an existing socket or configuration path is a symlink, has the wrong owner, or has an unsafe type or mode. NemoClaw can create missing descendants beneath a validated current-user root and reconcile content drift in its own portable configuration files. A missing user-scoped socket after a host reboot can be activated and verified at the recorded path. A new socket inode or a supported Podman upgrade does not invalidate the checkpoint. Portable onboarding always uses the .config directory beneath the canonical home reported by the operating system. HOME and XDG_CONFIG_HOME never select or override this authority. NemoClaw ignores ambient XDG_CONFIG_HOME during onboarding and restores its exact prior presence and value afterward. Resume rejects a checkpoint that records another configuration root. It also rejects stored authority or filesystem ownership drift without falling back to Docker.

Checkpoint Resume Compatibility

An active onboarding session with checkpoint schema 1, 2, or 3 cannot resume because those schemas did not record the default or portable profile authority. NemoClaw preserves the older session and exits before portable configuration, socket activation, or resource changes. Run nemohermes onboard --fresh to discard the active session and start fresh onboarding. If you intend to use the portable experimental profile, run nemohermes onboard --experimental-profile portable --fresh. This compatibility restriction does not prevent NemoClaw from reading a completed older session during status inspection.

Before the configuration review, NemoClaw records the sandbox name and the selected provider and model as an incomplete choice. If onboarding stops at the review prompt, an interactive --resume run shows the prompt again. A non-interactive --resume run reuses the recorded choice and continues to inference setup. After you choose Apply configuration, NemoClaw records the choice before inference setup starts. If inference setup fails, --resume reuses the accepted provider, model, and sandbox name. If you choose Exit onboarding, onboarding exits with a nonzero status and clears those recorded choices. Run nemohermes onboard to make new choices after exit. During a resume without terminal input, --yes or NEMOCLAW_YES=1 also selects non-interactive resume behavior. For a new or fresh session, --yes and NEMOCLAW_YES=1 accept supported confirmations but do not replace --non-interactive. If onboarding returns without reaching the final complete state, the command exits with status 1. When that result is resumable, NemoClaw keeps the session in_progress at its last checkpoint instead of marking it failed, so correct the reported condition and run nemohermes onboard --resume.

Recover a retained sandbox

If onboarding cannot complete after sandbox creation, NemoClaw preserves the sandbox. When available, NemoClaw records and prints the create-attempt label as the exact ai.nvidia.nemoclaw.create-attempt=<value> selector. When available, NemoClaw also records a durable identity fingerprint for recovery. Automatic and explicit resume, reuse, recreation, and fresh onboarding with that sandbox name remain blocked. When the recovery record contains a durable identity fingerprint, run nemohermes <sandbox-name> destroy to attempt identity-bound recovery.

Use the result from destroy to choose the next action:

  • If OpenShell still reports the sandbox present, destroy preserves the record and removes no resources. Do not delete the sandbox manually by mutable name. Give the displayed create-attempt label to an OpenShell administrator when present and ask them to remove that exact sandbox through an identity-bound procedure. Without a label, preserve the terminal output and ask the administrator to identify the exact sandbox from gateway or controller evidence.
  • After the administrator removes the exact sandbox, rerun nemohermes <sandbox-name> destroy.
  • If OpenShell confirms the sandbox is absent, destroy verifies one retained recovery record and its immutable runtime identity. For Docker-backed sandboxes, it also verifies the immutable Docker sandbox identity and removes only qualified residual containers. It clears the matching recovery record only after verified cleanup.
  • If the recovery record is ambiguous or immutable runtime-identity verification fails, cleanup stops and the record remains. For Docker-backed sandboxes, a foreign container, changed Docker identity, or failed Docker probe has the same fail-closed result.

If OpenShell did not return a durable identity fingerprint, destroy cannot complete recovery. A create-attempt label can help an OpenShell administrator identify and remove the exact sandbox, but it does not let NemoClaw retire the record without immutable identity authority. If neither a fingerprint nor a label is available, preserve the terminal output and ask the administrator to identify the exact sandbox from gateway or controller evidence. If NemoClaw reports that it could not save recovery evidence, preserve the terminal output and follow the same escalation.

This fail-closed record keeps only the affected sandbox name unavailable. It is not retired from mutable-name absence alone, and this command does not accept administrator-supplied identity authority. To onboard another sandbox while the record remains unresolved, supply a different explicit name:

$nemohermes onboard --name <new-sandbox-name>

--fresh alone does not clear the recovery record or permit reuse of the retained sandbox name.

Completed onboarding sessions are not resumable. Use --resume only for resumable interrupted or failed sessions, not to change provider, model, agent, or sandbox recreation settings after onboarding has completed. During resume, NemoClaw reruns preflight, gateway, provider, and sandbox repair checks even when the saved session has already reached a later nonterminal onboarding phase. If the recorded session conflicts with flags you pass on the recovery run, NemoClaw exits and tells you to either rerun with the original settings or start over.

An active same-name replacement is separate from ordinary onboarding-step resume. If onboarding printed Journaled replacement before it stopped, rerun the original onboarding command with the same target settings. The replacement can continue without an explicit --resume flag. Refer to Continue an Interrupted Replacement for the identity checks and failure conditions.

Use --fresh to discard the saved onboarding session and start the wizard from the beginning. This clears stale or failed session state before NemoClaw creates a new session record. It also bypasses locally recorded sandbox base-image resolution metadata and reruns normal candidate resolution. --fresh takes precedence over a base-image hint carried from a rebuild, so NemoClaw does not use that recorded hint. The installer also accepts --fresh and forwards it to nemohermes onboard, which skips automatic resume detection. --resume and --fresh are mutually exclusive. For an existing completed sandbox, use --fresh --name <sandbox-name> --recreate-sandbox when you intentionally want onboarding to replace that sandbox with a new provider, model, agent, or startup setting. Use nemohermes <sandbox-name> rebuild when you want NemoClaw to recreate the sandbox from its recorded registry metadata without changing those selections.

--tool-disclosure <progressive|direct>

Choose how the selected agent presents its session-authorized tools to the model. Outside the Portable experimental profile, progressive is the default: OpenClaw and Hermes use their native Tool Search implementations, while Deep Agents Code initially shows its core tools plus search_tools after at least one MCP tool loads successfully. direct restores the previous behavior and presents all registered tools directly. This setting changes model context only; it does not bypass OpenShell policy, credentials, approvals, hooks, or sandbox controls.

The flag takes precedence over NEMOCLAW_TOOL_DISCLOSURE. A new non-Portable sandbox defaults to progressive when neither is set. Fresh Portable onboarding defaults to direct when the flag is absent, even when NEMOCLAW_TOOL_DISCLOSURE is set. Pass --tool-disclosure progressive explicitly to select progressive disclosure for a fresh Portable sandbox. NemoClaw records the selected value with the onboarding session and sandbox so rebuilds preserve it and ambient shell variables cannot silently change an internal rebuild. Model-specific compatibility safeguards may downgrade a selected progressive mode to direct exposure for that model without changing the recorded preference. To change an existing sandbox, recreate it explicitly:

$nemohermes onboard --name my-assistant --recreate-sandbox --tool-disclosure direct

Outside the Portable experimental profile, recreation without an explicit flag or environment value preserves the recorded setting and only falls back to progressive for legacy state. A Portable resume without the flag preserves the mode recorded by the interrupted session. Resuming an interrupted session with a different explicit setting fails with a conflict instead of changing behavior mid-session.

When Docker exposes the required identity metadata, NemoClaw records the base-image resolution on managed sandbox images. During a warm recreate or rebuild, it validates the local image identity and platform, plus the exact repository digest for a published image and any active OpenShell ABI requirement, before reusing it. A valid match avoids candidate discovery and a network pull. Set NEMOCLAW_SANDBOX_BASE_IMAGE_REFRESH=1 to bypass the recorded hint without changing onboarding session handling:

$NEMOCLAW_SANDBOX_BASE_IMAGE_REFRESH=1 nemohermes onboard --recreate-sandbox
$NEMOCLAW_SANDBOX_BASE_IMAGE_REFRESH=1 nemohermes <sandbox-name> rebuild

Base-image selection follows this precedence:

  1. --fresh or NEMOCLAW_SANDBOX_BASE_IMAGE_REFRESH=1 bypasses recorded metadata and reruns normal candidate resolution. These controls are equivalent for base-image selection.
  2. Without a bypass, NemoClaw validates and reuses the recorded hint when possible.
  3. When the hint is absent or no longer valid, NemoClaw performs normal resolution.

After a cache miss, source checkouts require a fresh local build before candidate selection when base-image inputs have dirty or staged changes, or Git cannot inspect the worktree safely. For a clean release checkout or versioned install, NemoClaw first accepts the exact release-version image. If that tag exists locally but fails compatibility validation, NemoClaw refreshes the same tag from the registry once and validates it again. If the release-version image is missing or still incompatible, NemoClaw builds a compatible local base instead of falling back to mutable :latest. For clean unversioned development checkouts, NemoClaw first tries the image tagged with the exact source commit. If that image is unavailable and committed base-image inputs differ from main, NemoClaw requires a compatible local build. When committed base-image inputs match main, NemoClaw tries the image tagged with the newest reachable release version from origin and only uses :latest when no version tag is discoverable. When a stable tag and a prerelease tag share the same version, NemoClaw prefers the stable tag. If origin tag lookup is unavailable, NemoClaw uses the newest reachable local release tag as a fallback. If that nearest release-version image is missing or incompatible, NemoClaw builds a compatible local base instead of falling back to mutable :latest. The required-build path does not reuse an older local tag. If local builds are disabled or the build fails, resolution stops instead of selecting a stale image. When the OpenShell sandbox ABI is required, NemoClaw also rejects a built image that does not report a compatible glibc version.

Explicit base-image overrides are exact: NemoClaw validates the requested ref and fails closed when it cannot be pulled or does not satisfy required ABI, agent runtime, or dependency checks. Otherwise, normal resolution checks compatible images in Docker’s local image store before attempting to pull a missing published candidate. For warm-hint reuse and unversioned development resolution, NemoClaw can reuse another validated local fallback when published candidates are unavailable or incompatible. When the OpenShell sandbox ABI is required, that local fallback must be ABI-compatible. An offline warm recreate or rebuild can therefore continue when the recorded image or another compatible candidate is available locally. When source inputs require a fresh local build, NemoClaw fails the operation if that build cannot be produced and validated instead of substituting an older local tag. When the OpenShell sandbox ABI is required, resolution also fails if no ABI-compatible image can be resolved instead of falling back to an unvalidated cached :latest image.

For Hermes, warm-hint and candidate validation reruns a container probe for the MCP SDK and native Streamable HTTP integration. During normal resolution, NemoClaw tries the exact published digest declared by the final Hermes Dockerfile before release-version and source-commit candidates. The digest must also pass any active OpenShell ABI requirement, and a validated result can be recorded for warm-hint reuse. The final Hermes image accepts only the official published digest tracked by its Dockerfile or a repository-built local base, so an otherwise reachable or ABI-compatible image is not sufficient.

Bypassing the recorded hint does not clear Docker’s local image store or require a network pull. Only --fresh also discards the saved onboarding session; the refresh environment variable affects base-image selection only.

For NemoClaw-managed environments, use nemohermes onboard when you need to create or recreate the OpenShell gateway or sandbox. Avoid openshell self-update, npm update -g openshell, or openshell sandbox create directly unless you intend to manage OpenShell separately and then rerun nemohermes onboard.

Use --fresh to ignore any saved onboarding session and restart the wizard from scratch. This is useful after an interrupted nemohermes onboard run when you want to discard saved state instead of continuing it with --resume.

The installer detects existing sandbox sessions before onboarding and prints a warning if any are found. To make the installer abort instead of continuing, set NEMOCLAW_SINGLE_SESSION=1:

$NEMOCLAW_SINGLE_SESSION=1 curl -fsSL https://www.nvidia.com/nemoclaw.sh | bash

When existing sandboxes were created with OpenShell earlier than 0.0.37, the installer prompts before running the automatic gateway upgrade path. For scripted installs, set NEMOCLAW_ACCEPT_EXPERIMENTAL_OPENSHELL_UPGRADE=1 to allow the automatic path to prepare the current CLI without replacing OpenShell, back up every registered sandbox with the current state manifest, retire an installed gateway whose OpenShell version is outside the current release’s supported range, install the supported OpenShell release, and recover the existing sandboxes. The installer reads that supported range from the prepared current source and stops without retiring the gateway if the installed version is unknown or the range is missing or invalid. When the installed OpenShell version is already supported, the installer keeps the running gateway through the host update. On Linux and macOS, if installed OpenShell lifecycle commands cannot retire the gateway, the installer uses verified NemoClaw-managed service or PID-file evidence for the supported recovery path. For the default gateway on port 8080, Linux recovery first checks a verified active nemoclaw-openshell-gateway.service, while macOS recovery first checks a verified active Homebrew gateway service. Both paths then check a verified NemoClaw-managed gateway PID file for any configured gateway port. When a macOS PID file names a process that is no longer running, the installer removes the stale PID file only after lsof reports no listener and no diagnostic output. If lsof is unavailable, reports permission or other diagnostics, or produces inconsistent listener results, the installer stops before retiring the gateway and preserves the PID file, OpenShell registration, and sandbox backups. After either fallback confirms the gateway process is stopped, the installer tries to remove the selected OpenShell registration and warns if onboarding must replace a stale registration. If neither fallback can verify and stop the process, the installer stops after backup with every sandbox backup preserved. If any registered sandbox cannot be backed up, the installer aborts before it changes the gateway. After the automatic path retires an out-of-range gateway, it forces installation of the OpenShell version pinned by the prepared source before recovery. This mandatory installation applies to source and managed install modes and cannot remain deferred after gateway retirement. If the forced installation fails, the installer does not stage a gateway service or start recovery, preserves the backups, and tells you to rerun with NEMOCLAW_OPENSHELL_UPGRADE_PREPARED=1. On macOS, if the verified Homebrew installation does not resolve executable OpenShell CLI and gateway binaries, the installer also stops before recovery and preserves the backups and prepared recovery state. It does not fall back to a stale user-local OpenShell binary. When the registry contains a pre-fingerprint OpenClaw or Hermes entry with no recorded custom-image evidence, an interactive install asks you to confirm that the listed sandbox used a NemoClaw-managed image. For a non-interactive install, set NEMOCLAW_CONFIRM_LEGACY_MANAGED_RECREATE to the JSON array of names printed by the installer, such as ["my-assistant","preserve-hermes"], only after verifying every named sandbox used a managed image. The confirmation permits those legacy entries to recover onto the current managed image, but it does not override recorded custom-image evidence. After successful recovery, the installer skips generic onboarding. For any registered-sandbox upgrade that you already prepared manually, set NEMOCLAW_OPENSHELL_UPGRADE_PREPARED=1 only after backing up every registered sandbox and retiring the old gateway. This environment variable asserts that those steps are complete, so the installer skips the repeated backup and gateway-retirement phase before it checks whether OpenShell is installed or whether its version is in range. For a non-default gateway, preserve the selected port on the bash side of the install pipeline.

$curl -fsSL https://www.nvidia.com/nemoclaw.sh | NEMOCLAW_GATEWAY_PORT=<selected-port> NEMOCLAW_OPENSHELL_UPGRADE_PREPARED=1 bash

It reuses the latest backups, forces the pinned OpenShell installation, and starts recovery only after that installation succeeds. If the installation fails, rerun the same install-pipeline command to preserve NEMOCLAW_GATEWAY_PORT and NEMOCLAW_OPENSHELL_UPGRADE_PREPARED.

Legacy Upgrade Recovery Scope

Prepared backup recovery for a legacy sandbox restores only the managed state directory recorded in its validated manifest, such as /sandbox/.openclaw or /sandbox/.hermes. Files outside that recorded path, including /sandbox/user-data, are not preserved when the installer recreates the sandbox. Back up those paths outside the sandbox before you continue.

The wizard prompts for a provider first, then collects the provider credential if needed. Supported non-experimental choices include NVIDIA Endpoints, OpenRouter, OpenAI, Anthropic, Google Gemini, and compatible OpenAI or Anthropic endpoints. Credentials are registered with the OpenShell gateway and never persisted to host disk. Refer to Credential Storage for details on inspection, rotation, and migration from earlier releases. The legacy nemohermes setup command is deprecated; use nemohermes onboard instead.

On a qualified DGX Spark, the provider menu lists compatible experimental managed llama.cpp profiles in descending YAML priority order. During interactive onboarding without an explicit provider request, the menu ignores NEMOCLAW_LLAMACPP_RECIPE and marks the unique highest-priority compatible profile as (recommended). The recommended profile appears as Managed llama.cpp: Meta Muse Glimmer 30B on one DGX Spark (recommended). The NVIDIA Nemotron profile appears next without the recommendation marker. The selected menu entry determines the exact recipe even when NEMOCLAW_LLAMACPP_RECIPE names another recipe. Select the same path non-interactively with the repository-owned recipe:

$NEMOCLAW_PROVIDER=install-llama-cpp \
>NEMOCLAW_LLAMACPP_RECIPE=llama-cpp.nemotron-3-nano-30b-a3b.spark-single.v1 \
>NEMOCLAW_SANDBOX_NAME=my-assistant \
> nemohermes onboard --non-interactive --yes-i-accept-third-party-software

Use llama-cpp.muse-glimmer-30b.spark-single.v1 to select the Meta Muse Glimmer recipe explicitly.

Do not set NEMOCLAW_MODEL for the managed llama.cpp path. For prerequisites, external traffic, verification, and recovery, refer to Install Managed llama.cpp on DGX Spark.

After provider selection, the wizard reviews the provider, model, credential state, and sandbox name before registering inference. The interactive review offers these actions:

  • Apply configuration continues to provider registration.
  • Edit inference provider or model returns to provider and model selection.
  • Edit sandbox name prompts for the sandbox name again.
  • Exit onboarding stops onboarding before provider registration.

When you edit inference, NemoClaw clears the credential staged for the discarded selection. NemoClaw preserves the sandbox name. When you edit the sandbox name, NemoClaw preserves the inference selection. The sandbox prompt shows the prior name as its default. After you apply the configuration, routine editing ends. If inference setup fails and offers a back recovery action, you can return to provider and model selection and then review the updated configuration again.

It then prompts for optional web search and messaging channels, builds and starts the sandbox, and asks for a policy tier that controls the default set of network policy presets applied to the sandbox. Four tiers are available:

TierDescription
RestrictedNo tier defaults. Web search or other integrations selected earlier can still add their required presets; deselect them during policy review for baseline-only access.
Balanced (default)Full dev tooling and a selected, supported web search provider. Package installs, model downloads, and inference. No messaging platform access by default.
OpenBroad access across third-party services including supported messaging and productivity presets. Agent-specific unsupported presets are filtered out.
PersonalRequires one broad web authority that lets every sandbox binary open TCP connections to public and private address ranges on destination ports 80 and 443. It replaces overlapping web endpoints while preserving non-web policy. Unspecified, loopback, and link-local ranges remain blocked. Intended only for trusted personal-use workloads.

After selecting a tier, the wizard shows a combined preset and access-mode screen where you can include or exclude individual presets and toggle each between read and read-write access. When Personal is selected during the current onboarding run, personal-open-internet is mandatory for every agent and every onboarding entry point, including Portable. The picker and policy modes control only additional presets; they cannot deselect, skip, or replace Personal’s required web authority. For details on tiers and the presets each includes, refer to Network Policies. When onboarding creates a sandbox with presets, NemoClaw prints the exact finalized create-time policy scope before registering providers or creating the sandbox. NemoClaw does not persist that selection as desired policy state; later lifecycle operations read the current OpenShell policy, including host edits.

In non-interactive mode, set the tier with NEMOCLAW_POLICY_TIER (default: balanced):

$NEMOCLAW_POLICY_TIER=restricted nemohermes onboard --non-interactive --yes-i-accept-third-party-software

Unset, blank, or whitespace-only NEMOCLAW_POLICY_TIER values use the balanced default. In non-interactive mode, any non-blank value must be one of restricted, balanced, open, or personal; otherwise onboarding exits before preflight, gateway, or inference side effects with an error listing the valid options. Interactive onboarding ignores an invalid environment value and shows the normal tier prompt.

NEMOCLAW_POLICY_MODE controls how non-interactive onboarding reconciles the tier-derived suggestions against the sandbox’s currently-applied presets. The default is suggested, which is additive. Onboarding applies tier defaults and preserves any presets you previously added with nemohermes <name> policy add across re-onboards. Use custom with NEMOCLAW_POLICY_PRESETS when you want the explicit list to be authoritative for optional presets. Onboarding removes any optional preset that is not in the list. skip does not add optional tier defaults and retains eligible optional presets already applied. It still applies the required preset for each messaging channel enabled during the same onboarding run so the configured channel can reach its service. For Personal, all modes still apply or retain the mandatory personal-open-internet preset. NemoClaw filters tier suggestions and resume selections by active agent support and the selected web search provider. During automatic suggestion and resume reconciliation, it removes stale web-search selections when they conflict with the active agent or selected provider. The Personal tier instead uses personal-open-internet for web transport and does not select Brave Search or Tavily Search merely to enable ordinary web fetches. This makes keyless fetches available to any sandbox binary, but it does not add a provider-free web_search implementation.

For Hermes, this includes replacing stale nous-web when Tavily is selected. An explicit custom preset list or interactive manual selection remains operator-controlled for additional presets.

Hermes managed-tool gateway selections add matching Hermes-specific policy presets, such as nous-web, nous-image, nous-audio, nous-browser, and nous-code, without applying unsupported OpenClaw-only presets. When Tavily Search is selected, it replaces nous-web as the Hermes web search and extract backend while the other selected Nous tools remain enabled.

ValueBehaviour
suggested (default)Apply tier defaults and preserve any extra presets already applied. Aliases: default, auto.
customApply exactly the optional presets in NEMOCLAW_POLICY_PRESETS. Previously-applied optional presets not in the list are removed. Personal still requires personal-open-internet. Alias: list.
skipDo not add optional tier defaults; retain eligible optional presets already applied. Personal still applies or retains personal-open-internet. Aliases: none, no.

For non-interactive onboarding, you must explicitly accept the third-party software notice:

$nemohermes onboard --non-interactive --yes-i-accept-third-party-software

or:

$NEMOCLAW_ACCEPT_THIRD_PARTY_SOFTWARE=1 nemohermes onboard --non-interactive

For scripted installer runs, pass explicit acceptance to the bash side of the installer pipe:

$curl -fsSL https://www.nvidia.com/nemoclaw.sh | NEMOCLAW_NON_INTERACTIVE=1 NEMOCLAW_ACCEPT_THIRD_PARTY_SOFTWARE=1 bash

If the installer cannot prompt for the notice in a terminal and no explicit acceptance is set, it exits before installing Node.js or the NemoClaw CLI.

Hermes supports Tavily Search through NemoClaw onboarding and does not support Brave Search. To enable Tavily in non-interactive mode, set the provider and matching key.

$NEMOCLAW_WEB_SEARCH_PROVIDER=tavily \
>TAVILY_API_KEY=... \
> nemohermes onboard --non-interactive

Set NEMOCLAW_WEB_SEARCH_PROVIDER=none to disable web search explicitly. When the selector is unset, NemoClaw enables Tavily when TAVILY_API_KEY is available and ignores BRAVE_API_KEY for Hermes. An explicit Tavily selection with no key exits before sandbox creation. A Tavily key that fails validation prints a warning, disables web search for that run, and lets the rest of onboarding continue. Changing or disabling Tavily recreates the sandbox because the Hermes backend, environment placeholder, and credential attachment are part of the image. If you also select the Nous-managed web gateway through Nous Portal OAuth, Tavily replaces nous-web while other selected Nous tools remain enabled. API-key mode is inference-only and does not enable managed Nous tool gateways.

The wizard prompts for a sandbox name. Names must contain 1 to 19 characters. They must be lowercase, start with a letter, contain only letters, numbers, and single internal hyphens, and end with a letter or number. Consecutive hyphens (--) are not allowed. The CLI rejects names that do not match these rules. It also prints a Try: <suggested-slug> recovery line whenever it can derive a valid lowercase, hyphen-separated form from the input, so passing --name MyAssistant reports Try: myassistant. Names that match global CLI commands (status, list, debug, etc.) are rejected to avoid routing conflicts. Use --agent <name> to target a specific installed agent profile during onboarding. The nemohermes onboard --help output lists installed runtime names inline, and nemohermes agents list shows the same runtimes with manifest descriptions.

Use --control-ui-port <N> to choose the host dashboard port for a sandbox. The value must be an integer from 1024 through 65535. This flag takes precedence over CHAT_UI_URL, NEMOCLAW_DASHBOARD_PORT, the previous registry value, and the default port.

Do not use a port from 8642 through 8652 for any agent. NemoClaw allocates each Hermes sandbox’s OpenAI-compatible API port from that range, so it rejects every port in the range as a dashboard port before sandbox creation.

If you enable Slack during onboarding, the wizard collects both the Bot Token (SLACK_BOT_TOKEN) and the App-Level Token (SLACK_APP_TOKEN). Socket Mode requires both tokens. The app-level token is stored in a dedicated slack-app OpenShell provider and forwarded to the sandbox alongside the bot token. The wizard also accepts optional SLACK_ALLOWED_USERS and SLACK_ALLOWED_CHANNELS values so you can restrict Slack DMs, channel @mention users, and channel IDs before the sandbox is created.

If you enable Discord during onboarding, the wizard can also prompt for a Discord Server ID, whether the bot should reply only to @mentions or to all messages in that server, and an optional Discord User ID. NemoClaw includes those values in the generated Discord guild workspace configuration so the bot can respond in the selected server, not just in DMs. If you leave the Discord User ID blank, the guild config omits the user allowlist and any member of the configured server can message the bot. Guild responses remain mention-gated by default unless you opt into all-message replies. If DISCORD_SERVER_ID is set and DISCORD_REQUIRE_MENTION is unset, NemoClaw records the existing mention-only default (DISCORD_REQUIRE_MENTION=1).

If you enable Telegram during onboarding, the wizard can also prompt for whether group chats should reply only to @mentions or to all group messages. Mention-only group replies are the default. Set TELEGRAM_REQUIRE_MENTION=0 for non-interactive onboarding when you want all group messages to trigger replies. For OpenClaw, Telegram group access defaults to TELEGRAM_GROUP_POLICY=open; set TELEGRAM_GROUP_POLICY=allowlist or TELEGRAM_GROUP_POLICY=disabled before non-interactive onboarding when you want stricter group access. Hermes does not have an equivalent disable-groups policy; TELEGRAM_ALLOWED_IDS maps to Hermes TELEGRAM_ALLOWED_USERS, which authorizes those users across DMs, groups, and forums. Pairing and TELEGRAM_ALLOWED_IDS still govern direct messages.

If you cancel a brand-new onboarding run at the policy-tier selector or either policy-preset selector after sandbox creation, NemoClaw preserves the incomplete sandbox, registry entry, and onboarding session for identity-bound recovery. NemoClaw reports the durable sandbox identity fingerprint when it is available. It does not run OpenShell’s mutable-name deletion command because the name may now identify a replacement sandbox. Follow the retained-sandbox recovery procedure to reconcile this cancellation. A fresh run with a different explicit name can continue while the cancelled sandbox name remains blocked.

If you run onboarding again with the same sandbox name and choose a different inference provider or model, NemoClaw detects the drift and recreates the sandbox so the running agent config matches your selection. In interactive mode, the wizard asks for confirmation before delete and recreate. In non-interactive mode, NemoClaw recreates automatically when the stored selection is readable and differs. For managed Deep Agents Code sandboxes, NemoClaw also recreates when the live dcode identity selection is unreadable; other agent paths continue to reuse by default when their stored selection cannot be read. Set NEMOCLAW_RECREATE_SANDBOX=1 to force recreation even when no drift is detected.

Before deleting an existing sandbox during recreation, NemoClaw backs up the workspace state declared by the selected agent profile and restores it into the new sandbox once it is live. This applies whether the existing sandbox is ready or marked not-ready, so cross-version upgrades that pass NEMOCLAW_RECREATE_SANDBOX=1 no longer drop user files from the selected agent workspace. The behaviour matches nemohermes <name> rebuild --force. NemoClaw aborts the recreate when the backup cannot complete in full, including when individual state directories or files fail mid-backup, so failed entries are not silently dropped on delete. If restoration into the replacement does not complete, NemoClaw reports the failed directories, files, and restore reason that are available, preserves the snapshot, leaves the replacement unregistered, and exits nonzero. Run the owner-scoped openshell sandbox delete -g '<gateway>' '<sandbox>' command that onboarding prints, then rerun the original onboarding command. If NemoClaw cannot identify the owning gateway, do not delete a same-name sandbox. Preserve the snapshot for manual recovery. Set NEMOCLAW_RECREATE_WITHOUT_BACKUP=1 to skip the pre-recreate backup. The destination sandbox starts with a fresh workspace.

Before deletion, onboarding prints a Journaled replacement diagnostic with the replacement identifier, recorded OpenShell gateway, and current phase. If the process stops after this point, a later same-target onboarding run continues the active replacement without requiring --resume. It accepts a ready same-name replacement only when the live identity and sandbox registry generation match the journal. It fails closed if the gateway, source, target, durable source registry fields, or replacement settings changed.

For Hermes, the backed-up paths come from agents/hermes/manifest.yaml, including /sandbox/.hermes state such as memories, sessions, skills, plugins, cron, scripts, logs, plans, workspace, messaging platform state, runtime/state.db, and the default kanban board in kanban.db. Kanban backup does not include named boards, attachments, worker logs, scratch workspaces under kanban/, or external directory or worktree targets.

Before creating the gateway, the wizard runs preflight checks. It verifies that Docker is reachable and prints host remediation guidance when prerequisites are missing. Standard onboarding rejects unsupported runtimes such as Podman. The explicit portable experimental profile has one installer-preflight admission exception for the Podman unsupported-runtime finding. It does not waive any other readiness blocker or make Podman generally supported. The preflight also enforces the OpenShell version range declared in the blueprint (min_openshell_version and max_openshell_version). If the installed OpenShell version falls outside this range, onboarding exits with an actionable error and a link to compatible releases. For fresh OpenShell installs, NemoClaw queries published OpenShell releases and asks the installer to use a release that fits the blueprint range. If release metadata is unavailable, the installer uses its bundled fallback pin and the post-install version gate still enforces the range.

When NemoClaw finds an existing gateway to reuse, it probes the host gateway HTTP endpoint before declaring the gateway reusable. If the container is running but the upstream is still warming up (for example, immediately after a Docker daemon restart), NemoClaw rebuilds the gateway instead of trusting stale metadata. On the Docker-driver gateway path, preflight stays read-only when it detects a stale gateway (for example, a Docker-driver runtime env hash drift). It prints a ⚠ Gateway will be recreated when sandbox creation starts notice and defers the actual teardown to step [2/8] Starting OpenShell gateway. This means pressing Ctrl+C between preflight and step [2/8] leaves the running gateway and existing sandbox containers untouched, so nemohermes onboard is safe to run just to check preflight output. An interrupted run prints the resume command and exits with status 130 for Ctrl+C or 143 for SIGTERM. For Linux Docker-driver gateways, onboarding also checks that a helper container on the OpenShell Docker network can reach host.openshell.internal:<gateway-port>. If a host firewall blocks that sandbox path, onboarding exits with a sudo ufw allow from <subnet> to <gateway-ip> port <gateway-port> proto tcp command before it reports the gateway healthy. Set NEMOCLAW_AUTO_FIX_FIREWALL=1 to opt in to automatic UFW remediation for this specific failure: NemoClaw uses sudo -n only, validates the Docker bridge subnet/gateway/port, applies the narrow UFW rule only after a proven TCP reachability failure, and re-probes before continuing. If passwordless sudo, UFW, or active UFW is unavailable, NemoClaw falls back to the manual guidance path without prompting for a password.

For the portable experimental profile, the helper maps host.openshell.internal to the OpenShell Podman host gateway instead of the inspected network gateway. This path does not use Docker bridge UFW remediation. After all portable TCP probe attempts fail, onboarding prints commands for the user-scoped Podman service and socket.

Onboarding prints the same commands when the portable probe cannot reach the user-scoped Podman service. The printed rerun command keeps the portable experimental profile selected. Portable commands reconstruct the current user’s rootless Podman socket authority from NemoClaw state before they use the Docker-compatible API. They do not select an endpoint from ambient Docker or Podman runtime variables or named connections. When podman.service reports inactive and the recorded socket exists, NemoClaw first makes one 10-second API request through the guarded recorded authority. A valid server version classifies the endpoint as warm and avoids starting another socket service. A missing socket or a response without a valid server version enters bounded cold activation. Any socket authority change during this precheck fails at the socket authority stage. When the user-scoped socket-backed service needs activation, NemoClaw activates it and waits through a bounded startup period for a real Podman API response. During cold activation, the first API probe can cause systemd to replace the socket inode. NemoClaw requalifies one such replacement and repeats the probe only when the socket path, device, mode, owner, and complete directory authority remain unchanged. Any other authority change or a second inode replacement fails the readiness check. After cold activation succeeds, later API health checks use the fixed 10-second steady-state deadline. Onboarding and portable sandbox lifecycle commands use this same readiness contract. Failures identify socket authority, service activation, startup API health, or steady-state API health without reporting credentials. NemoClaw does not fall back to Docker or report an absent or unreachable endpoint as healthy. A successful cold path uses the cold timing label and reports activation, API, and total time in milliseconds. A successful warm path uses the warm timing label and reports steady-state API and total time in milliseconds. To tune the existing-gateway HTTP health poll, use NEMOCLAW_REUSE_HEALTH_POLL_COUNT (default 6) and NEMOCLAW_REUSE_HEALTH_POLL_INTERVAL (default 5 seconds). The poll count is clamped to a minimum of 1 so the health probe always runs at least once, and the interval is clamped to a minimum of 0 (no sleep between attempts).

The Docker-driver gateway and the portable experimental profile’s Podman-driver gateway resolve to the same default state directory when they use the same gateway port, because NemoClaw scopes that directory by port, not by driver. Selecting the portable experimental profile on a host that already has a Docker-driver gateway therefore refuses to rewrite that gateway’s config rather than silently repurposing it for Podman. The error names the driver the existing config already uses and the driver this run selected. Docker and Podman gateways cannot reuse one state directory. For NemoClaw-managed state, switch drivers with the applicable nemohermes uninstall path, then retry onboarding. Uninstall preserves externally managed or supervised state; resolve that state through its lifecycle authority instead. To run both drivers concurrently, select an unused gateway port with NEMOCLAW_GATEWAY_PORT=<port> and a separate state directory with NEMOCLAW_OPENSHELL_GATEWAY_STATE_DIR=<path>.

--from <Dockerfile>

Without --from, onboarding through the OpenShell Docker driver for OpenClaw, Hermes, and LangChain Deep Agents Code selects an immutable managed image for the installed release and host architecture. NemoClaw validates the complete three-agent publication cohort before selecting any member. If registry or catalog availability prevents resolution, stock onboarding stops before sandbox creation and does not build a shipped Dockerfile. Catalog evidence that is incomplete, mixed, mutable, wrong-platform, or identity-inconsistent also fails closed before sandbox creation. The portable experimental profile and native Podman are not part of this activation.

Build the sandbox image from a custom Dockerfile instead of the stock NemoClaw image. The supplied Dockerfile defines the complete sandbox image, and NemoClaw does not layer it on top of the stock managed runtime. The entire parent directory of the specified file is used as the Docker build context, so any files your Dockerfile references (scripts, config, etc.) must live alongside it. When the supplied path is the selected agent’s own managed Dockerfile (for example, agents/hermes/Dockerfile in the NemoClaw checkout the CLI runs from), NemoClaw applies one exception and stages the repository root as the build context, exactly as the managed build does, because that Dockerfile copies repository-root paths. This lets you edit the managed Dockerfile in place (for example to add Python packages) and rebuild from it with --from. For this managed exception, onboarding applies the .dockerignore from the repository root. For every other --from path, onboarding applies a .dockerignore from the Dockerfile’s parent directory while calculating the context size and staging files for Docker. NemoClaw also applies additional secret-safety exclusions that override .dockerignore negation rules: credential-style files and directories such as .env*, .ssh/, .aws/, .netrc, .npmrc, secrets/, *.pem, and *.key are still skipped even if .dockerignore tries to include them. Without a .dockerignore, onboarding still skips common large or local-only directories (node_modules, .git, .venv, and __pycache__) while staging this context. Other build outputs such as dist/, target/, or build/ are included unless your .dockerignore excludes them. If the staged context is larger than 100 MB, onboarding prints a warning before the Docker build starts. Move the Dockerfile into a smaller dedicated directory or add .dockerignore entries for generated artifacts to shrink the context. If the directory contains unreadable files (for example, Windows system files visible in WSL), onboarding exits with an error suggesting you move the Dockerfile to a dedicated directory.

NemoClaw builds user-supplied --from contexts with the OpenShell gateway builder. The host-side local BuildKit prebuild is limited to build contexts generated entirely by NemoClaw. On a local Docker-driver gateway, a Local BuildKit build skipped notice is expected and onboarding continues with the custom image.

$nemohermes onboard --from path/to/Dockerfile

The Dockerfile path must exist. Missing paths fail during command parsing before preflight, gateway setup, inference setup, or sandbox creation starts.

The file can have any name; if it is not already named Dockerfile, onboard copies it to Dockerfile inside the staged build context automatically. To create an isolated build context, create a dedicated directory that contains only the Dockerfile and the files it needs:

build-dir/
├── Dockerfile
└── files-used-by-COPY/

For faster custom builds, plan for Docker cache behavior:

  • Treat the first build on a fresh host as a cold build. Cold builds download the base image and package indexes, so they take longer than later warm rebuilds even when NemoClaw is healthy.
  • A warm rebuild reuses cached layers when the base image and earlier layers are unchanged, so it is much faster than the first build.
  • Order Dockerfile instructions from least-changing to most-changing: base image, system packages, dependency manifests, dependency install, then application source. This lets warm rebuilds reuse cached dependency layers instead of reinstalling on every source change.
  • Pin the base image to an explicit tag or digest so warm rebuilds resolve the same cached base instead of pulling a new one.

To diagnose where a slow build spends time, set NEMOCLAW_TRACE=1 and read the phase timings in Onboard Profiling Traces. NemoClaw does not guarantee exact build timings.

All NemoClaw build arguments (NEMOCLAW_MODEL, NEMOCLAW_INFERENCE_PROVIDER_ID, NEMOCLAW_INFERENCE_BASE_URL, etc.) are injected as ARG overrides at build time, so declare them in your Dockerfile if you need to reference them.

NEMOCLAW_INFERENCE_PROVIDER_ID is a non-secret inference route identifier (for example inference for proxied providers, or a provider family such as openai), never a credential; provider credentials stay in OpenShell provider storage. It replaces the former NEMOCLAW_PROVIDER_KEY image argument, whose secret-shaped name triggered a BuildKit SecretsUsedInArgOrEnv warning. The host-side NEMOCLAW_PROVIDER_KEY credential alias is unchanged; this migration only renames the managed image route selector. Custom Dockerfiles that declare either ARG NEMOCLAW_INFERENCE_PROVIDER_ID or the legacy ARG NEMOCLAW_PROVIDER_KEY continue working in v0.0.91. NemoClaw updates whichever supported declaration is present, and runtime consumers read the legacy name as a fallback. Rename the legacy ARG/ENV declaration to NEMOCLAW_INFERENCE_PROVIDER_ID; the legacy fallback is retained for compatibility in this release and may be removed in a future release.

Custom Dockerfiles must declare ARG NEMOCLAW_TOOL_DISCLOSURE=progressive exactly once in the final build stage and promote it into that stage’s runtime environment. The usual runtime contract is:

1ARG NEMOCLAW_TOOL_DISCLOSURE=progressive
2ENV NEMOCLAW_TOOL_DISCLOSURE=${NEMOCLAW_TOOL_DISCLOSURE}

Onboarding and rebuild preflight reject a missing, duplicate, or unconsumed declaration before replacing an existing sandbox.

In non-interactive mode, the path can also be supplied via the NEMOCLAW_FROM_DOCKERFILE environment variable. You must also supply a sandbox name via --name <sandbox> or NEMOCLAW_SANDBOX_NAME so a --from build cannot silently clobber the default my-assistant sandbox.

$NEMOCLAW_NON_INTERACTIVE=1 NEMOCLAW_FROM_DOCKERFILE=path/to/Dockerfile NEMOCLAW_SANDBOX_NAME=my-build nemohermes onboard

If a --resume is attempted with a different --from path than the original session, onboarding exits with a conflict error rather than silently building from the wrong image.

--name <sandbox>

Set the sandbox name without going through the interactive prompt. The same name format and reserved-name rules that the wizard enforces apply here too. Names must contain 1 to 19 characters. They must be lowercase, start with a letter, contain only letters, numbers, and single internal hyphens, and end with a letter or number. Consecutive hyphens (--) are not allowed. Names that match a NemoClaw CLI command (status, list, debug, etc.) are rejected up front.

$nemohermes onboard --non-interactive --name my-build --from path/to/Dockerfile

The flag wins over NEMOCLAW_SANDBOX_NAME. When prompting is possible, NEMOCLAW_SANDBOX_NAME fills the interactive default so you can press Enter to accept it. When prompting is impossible (no TTY or --non-interactive), the env var is also honoured so existing CI scripts keep working. Combining --from <Dockerfile> with non-interactive onboarding requires one of --name or NEMOCLAW_SANDBOX_NAME; otherwise onboarding exits rather than silently defaulting to my-assistant and clobbering the default sandbox.

nemohermes onboard --from

Use a custom Dockerfile for the sandbox image. This variant of nemohermes onboard accepts a --from <Dockerfile> argument to build the sandbox from a user-supplied Dockerfile instead of the default NemoClaw image. The user-supplied context uses the OpenShell gateway builder instead of NemoClaw’s host-side local BuildKit prebuild.

$nemohermes onboard --from ./Dockerfile.custom

GPU Passthrough

When nemohermes onboard detects an NVIDIA GPU on the host, it enables OpenShell GPU passthrough at both the gateway and sandbox level by default. The nvidia-smi probes require a successful result and reject placeholder JMJWOA-Generic-* GPU names unless NemoClaw can prove a supported NVIDIA platform or GPU execution. NemoClaw treats a recognized NVIDIA product model from /sys/class/dmi/id/product_name or /sys/firmware/devicetree/base/model, or a known Tegra device node, as authoritative platform identity. On eligible native or Docker Desktop-backed WSL ARM64 Linux hosts without that firmware evidence, one bounded Docker CUDA workload can prove GPU execution. On those hosts, a single plausible, non-placeholder NVIDIA GPU name also requires that proof when the NVIDIA kernel-driver interface (/proc/driver/nvidia) is absent. For Windows-on-Arm, this proof is a technical detection check and does not change the Unsupported product status or establish platform qualification. Refer to Platform Support and Launch Claims for the current support boundary. For the proof command, timeout control, and failure recovery, refer to GPU Setup Fails with a Placeholder GPU Name. The names-only unified-memory fallback does not run this workload and rejects denylisted names. Other non-firmware-vouched hosts also reject denylisted names. Jetson/Tegra hosts that ship without nvidia-smi continue to be detected via the devicetree firmware fallback (/sys/firmware/devicetree/base/model) or the Tegra device-node fallback (/dev/nvhost-gpu, /dev/nvhost-ctrl-gpu, /dev/nvhost-ctrl, or /dev/nvmap); both bypass the trust-tier gate above. Use --no-gpu to opt out when you want host-side inference providers only and do not need direct GPU access inside the sandbox. Use --gpu to require GPU passthrough and fail fast if an NVIDIA GPU is not detected. Use --sandbox-gpu or --no-sandbox-gpu to control only direct NVIDIA GPU access inside the sandbox. Use --sandbox-gpu --sandbox-gpu-device <device> to select an NVIDIA GPU by index (0), GPU UUID (GPU-...), or full CDI device name (nvidia.com/gpu=0). NemoClaw preserves the selection on resume. Use --vllm-gpu-device <index-or-uuid> to select the host GPU for the vLLM container that NemoClaw installs and manages. This selection is separate from sandbox GPU access, and NemoClaw also preserves it on resume. The selected GPU must satisfy the model’s memory and compute-capability requirements. For native Docker and Podman creation, NemoClaw passes the normalized CDI name through OpenShell driver config; compatibility routes use the equivalent container-runtime selector. Device selection requires explicit sandbox GPU enablement. On ordinary native Linux Docker-driver hosts, NemoClaw uses native OpenShell GPU injection by default and never broadens confinement automatically.

Portable onboarding requires native OpenShell GPU injection for every agent. It does not use NEMOCLAW_DOCKER_GPU_PATCH compatibility routing, so do not set fallback, 1, or another legacy nonzero value for that profile.

Set NEMOCLAW_DOCKER_GPU_PATCH=fallback to explicitly authorize one native attempt followed by one compatibility retry. NemoClaw permits the retry only after it confirms either a trusted host-side GPU routing failure or an explicit driver proof plus exact-container host configuration showing that no GPU was attached. It then saves redacted diagnostics and removes the incomplete sandbox before retrying. Sandbox-reported CUDA output alone never authorizes the broader compatibility envelope, even when the operator enabled fallback. That case fails closed and points to the explicit NEMOCLAW_DOCKER_GPU_PATCH=1 compatibility-only control. NemoClaw retries only after it verifies that no OpenShell-managed Docker container labeled for that sandbox remains; if cleanup cannot be proven safe, onboarding stops and prints cleanup guidance instead. On Docker Desktop WSL and Jetson/Tegra, automatic GPU onboarding uses the compatibility path directly. On ordinary native Linux, the compatibility path uses an available NVIDIA CDI spec before falling back to Docker --gpus all or the NVIDIA runtime. On Docker Desktop WSL, the compatibility path skips CDI and tries Docker --gpus all before the NVIDIA runtime. On Jetson/Tegra hosts, the compatibility path uses the NVIDIA runtime and adds eligible host group IDs for the supported GPU device nodes. These include selected /dev/nvmap, /dev/nvhost-*, and /dev/nvgpu/igpu0/* nodes plus real /dev/dri/renderD* character devices. After compatibility recreation starts, onboarding keeps the pre-patch container as a rollback backup until the replacement passes the Ready, GPU, and applicable local-inference checks. If one of those checks fails before backup removal, onboarding prints failure diagnostics and attempts to restore the pre-patch container. To commit the replacement, NemoClaw first asks OpenShell to stop the sandbox so its durable lifecycle row reaches Stopped before any irreversible Docker mutation. It then stops the exact transaction-owned replacement, removes the rollback backup, and asks OpenShell to start the sandbox so OpenShell owns the Starting lifecycle fence. NemoClaw verifies a Ready row, a working sandbox exec, and that the exact replacement is the sole running labeled container within the final handoff deadline. If that final handoff cannot be confirmed, onboarding exits with the container diagnostics and cleanup guidance instead of reporting success. If rollback fails, onboarding reports that the pre-patch container was not restored and prints container-cleanup guidance. GPU-proof diagnostics are captured before rollback and can print that guidance before the final container state is known, so inspect the sandbox and its labeled Docker containers before running a deletion command.

Prerequisites:

  • Ensure NVIDIA GPU drivers are installed and working.
    • On generic NVIDIA hosts, nvidia-smi must succeed.
    • On Jetson/Tegra hosts shipping without nvidia-smi, the devicetree firmware fallback substitutes.
  • NVIDIA Container Toolkit configured for Docker.

When GPU passthrough is enabled and a gateway already exists without it, onboarding first checks whether replacing the CPU-only gateway is safe. If no other registered sandbox depends on that gateway, or if --recreate-sandbox is recreating the only registered sandbox with the same name, onboarding cleans up the stale gateway and continues. If other sandboxes depend on the gateway or Docker state is unclear, onboarding exits without cleanup and prints targeted destroy or gateway-removal guidance. To add GPU to an existing sandbox, rerun with --recreate-sandbox. Leave NEMOCLAW_DOCKER_GPU_PATCH unset or set it to auto for native-only GPU onboarding on ordinary native Linux. Set NEMOCLAW_DOCKER_GPU_PATCH=fallback to explicitly opt into one bounded native-to-compatibility retry on ordinary native Linux. Set NEMOCLAW_DOCKER_GPU_PATCH=0 to require native OpenShell GPU injection on ordinary native Linux or Jetson/Tegra. Set NEMOCLAW_DOCKER_GPU_PATCH=1 to use only the compatibility path on ordinary native Linux. Other legacy nonzero values keep that behavior through the v0.0.x release line and will be removed in v0.1.0. Use NEMOCLAW_DOCKER_GPU_PATCH=0 on Jetson/Tegra only for troubleshooting because it bypasses Tegra device-group propagation and CUDA may not initialize. Docker Desktop WSL ignores NEMOCLAW_DOCKER_GPU_PATCH=0 because GPU passthrough on that runtime requires the compatibility patch. Use --no-sandbox-gpu, --no-gpu, or NEMOCLAW_SANDBOX_GPU=0 when you want to disable sandbox GPU passthrough on Docker Desktop WSL.

nemohermes list

List all registered sandboxes with their model, provider, and policy presets. Pass --json for machine-readable output that includes a schemaVersion, the default sandbox, recovery metadata, and the sandbox inventory. When the latest resumable onboarding session owns the matching inference-route reservation but has not created a sandbox, text output shows it under Incomplete onboarding with the recorded step and resume command. JSON output reports the same state in incompleteOnboarding; it remains separate from sandboxes and never affects the default sandbox. When present, incompleteOnboarding contains name, status (failed or in_progress), step (a string or null), interrupted (a boolean), and resumable: true; otherwise it is null. NemoClaw does not expose stale reservations that belong to another onboarding session. Each sandbox row reports activeSessionCount as a nonnegative integer when the SSH-session probe is available and null when it is unavailable. Each sandbox row reports agent as a string in both text and JSON output, never null. The row reports openclaw when the registry records no agent for the sandbox. The row reports unknown for a sandbox that nemohermes list recovers from the live OpenShell gateway. The gateway sandbox list does not expose the agent. The row does not include the former derived connected boolean. Sandboxes with an active SSH session are marked with a indicator so you can tell at a glance which sandbox you are already connected to in another terminal.

When a sandbox has a recorded dashboard port, the output includes its local dashboard URL. The default sandbox in text and JSON output honors the same environment override order as host-level status and tunnel commands: NEMOCLAW_SANDBOX_NAME, then NEMOCLAW_SANDBOX, then SANDBOX_NAME, then the registry default.

$nemohermes list [--json]
$nemohermes list --json

nemohermes use <name>

Promote a registered sandbox to the default. This is the first-class replacement for hand-editing ~/.nemoclaw/sandboxes.json; it updates the registry through the same atomic, lock-guarded path that nemohermes onboard uses for the initial default. Subsequent commands and the NEMOCLAW_SANDBOX_NAME resolution order then pick up the new default automatically. Pass --json to receive a machine-readable result indicating whether the registry was updated, the sandbox was already the default, or the name is unknown.

nemohermes use is a thin selector and never mutates the sandbox itself. It fails with a non-zero exit and a known-sandbox list when the requested name is not registered, so scripts can branch safely on the outcome.

$nemohermes use <name>
$nemohermes use <name> --json

nemohermes launch <name>

Connect to a sandbox and start its agent in one host-side command. Use it instead of running nemohermes <name> connect and then typing the agent command inside the sandbox.

launch runs the complete preflight from nemohermes <name> connect when no launch-readiness lease is usable. That path includes the readiness wait, in-sandbox agent process recovery, and inference-route reconciliation. A successful complete preflight can publish a credential-free launch-readiness lease with a fixed 24-hour lifetime on Linux. Lease acceptance and publication are currently Linux-only and require a secure, independently writable OS per-user runtime authority under /run/user/<numeric-uid>. It never uses caller-provided environment variables to select this authority. On macOS, launch runs the complete preflight every time and does not publish a launch-readiness lease.

During that lease, another launch still verifies these conditions:

  • The owning OpenShell gateway reports the exact sandbox identity in the Ready or Running state.

  • The sandbox registry, agent manifest, and interactive command match the recorded identity, and the current OpenShell policy is readable and valid. The lease stores no policy hash, so trusted host-side policy changes do not invalidate launch readiness.

  • The recorded inference selection matches the live route, and inference.local returns HTTP 2xx from its semantic probe when inference is configured. This is stricter than the HTTP 200–499 reachability diagnostic used by ordinary connect.

  • The agent runtime and its required host-side forwards pass their semantic health checks.

Hermes and LangChain Deep Agents Code retain their existing session setup on the lease-accepted path.

After these checks pass, launch can skip duplicate recovery, readiness polling, and inference-route repair. The lease does not replace a health check or authorize repair. For missing, expired, malformed, inaccessible, mismatched, or unhealthy evidence, NemoClaw fences any prior acceptable evidence before it runs the complete preflight. Ordinary launch continues only when NemoClaw proves that no old authority or evidence can exist, or durably rotates the runtime epoch. If an old epoch might exist and cannot be durably rotated, launch stops before complete preflight or recovery. Its redacted guidance asks you to repair the current user’s secure OS runtime authority and NemoClaw state permissions, then retry. A failed live check never becomes a successful launch because a lease exists.

Immediately before the first mutation in the complete preflight, the producer revalidates its sandbox-global runtime epoch while holding the sandbox lifecycle lock followed by the owning gateway lock. It holds both locks through all mutations in the complete preflight, final state capture, and publication. If another producer has replaced the epoch, the stale producer makes no changes and re-inspects the newer lease.

The 24-hour lifetime does not extend when you launch repeatedly. Exiting the agent with /exit does not revoke the lease. If state changes before expiry, NemoClaw fences the old evidence and runs the complete preflight. A successful preflight in that interval keeps the original start and expiry time. After expiry, a successful complete preflight starts a new 24-hour lease only when publication succeeds.

If unsafe or malformed authority history makes the prior lease timeline untrustworthy, NemoClaw durably invalidates the old epoch and starts one conservative 24-hour quarantine. Both wall time and monotonic uptime must span the full quarantine, and publication remains disabled during it. Repeated attempts do not extend the quarantine. After it elapses, the next successful complete preflight can publish a new fixed 24-hour lease. You do not create or refresh this lease manually, and launch has no lease-control flags. After lease validation or the automatic fallback that runs the complete preflight, launch starts the sandbox’s agent in your terminal instead of opening a sandbox shell.

The agent command comes from the sandbox’s agent manifest. If the sandbox registry names a non-OpenClaw agent without a readable local agent manifest, launch exits before starting an in-sandbox command.

AgentCommand
OpenClawopenclaw tui
Hermeshermes
LangChain Deep Agents Codedcode
$nemohermes launch <name>

The sandbox name is required, and the command takes no flags. The sandbox must already exist in the local NemoClaw state. If it is not registered locally, launch exits before it runs an OpenShell command or readiness recovery and reports that the sandbox is not registered in the local NemoClaw state. When the agent exits, you return to the host shell.

launch returns the agent’s exit code.

When you want a shell inside the sandbox rather than an agent session, use nemohermes <name> connect.

nemohermes <name> connect

Connect to a sandbox by name. Bare nemohermes connect (no sandbox name) connects to the registry default. NemoClaw uses the stored default when it names a non-pending registered sandbox, then falls back to the first non-pending registration. If only pending registrations remain, the command exits non-zero and tells you to wait for onboarding or remove the incomplete sandbox. If the registry remains empty after recovery, it tells you to run nemohermes onboard. A registered sandbox literally named connect keeps the name-first reading. If the sandbox is not yet in the Ready phase, connect polls openshell sandbox list every few seconds and prints the current phase. This gives you progress output right after onboarding, when the 2.4 GB image is still pulling, instead of a silent hang. Control the wait budget with NEMOCLAW_CONNECT_TIMEOUT in integer seconds. An interactive connection defaults to 120 seconds, while --probe-only and nemohermes <name> start default to 300 seconds so a scripted health check can wait through a cold sandbox start. When the deadline expires, connect exits non-zero with the last-seen phase.

On a TTY, a one-shot hint prints before dropping into the sandbox shell. The hint is agent-aware. It names the correct TUI command for the sandbox’s agent and reminds you to use /exit to leave the chat before exit returns you to the host shell. Set NEMOCLAW_NO_CONNECT_HINT=1 to suppress the hint in scripted workflows. If the sandbox is running an outdated agent version, a non-blocking warning prints before connecting with a nemohermes <name> rebuild hint. If another terminal is already connected to the sandbox, connect prints a note with the number of existing sessions before proceeding. Multiple concurrent sessions are allowed.

While a session opened by connect remains active, NemoClaw watches for a Shields auto-relock that occurs after the connection begins. When one occurs, the host terminal prints one warning for that event on stderr, explains that restricted operations can now fail, and shows the exact nemohermes <name> shields down --timeout ... command to run on the host. The connected session remains open. If the Shields audit cannot be read, NemoClaw keeps the session open and might not print the advisory warning.

Without --probe-only, connect does not pull a model itself, but it does inspect managed-vLLM install variables such as NEMOCLAW_VLLM_MODEL and NEMOCLAW_VLLM_EXTRA_ARGS_JSON if you exported them in the same shell. An unknown model slug, malformed extra-args JSON, or a gated model (for example deepseek-r1-distill-70b) with no HF_TOKEN or HUGGING_FACE_HUB_TOKEN exits non-zero with the same error the installer would emit, before any sandbox readiness probe or SSH attach. Unset the managed-vLLM variable, or fix the value, before retrying a regular connection. connect --probe-only skips this install preflight so stale managed-vLLM variables cannot block recovery.

For an active Portable Hermes sandbox, connect --probe-only can resume only the stopped Ollama runner named by the published receipt. The recover command uses the same inference recovery path, but ordinary connect does not. Follow Recover Portable Published Ollama for authority checks, route proof, rollback, and failure handling.

Before reading or changing the live OpenShell gateway inference route, connect verifies the shared provider and sandbox metadata. When the live route differs and the metadata is compatible, connect warns and re-points the route to the target sandbox’s recorded provider and model. Refer to Use Shared Gateway Routes for provider-global identity, route drift, and hard-error recovery. Use nemohermes inference set --provider <provider> --model <model> to make an intentional compatible route change outside the connect flow. Before it opens SSH, connect probes https://inference.local/v1/models from inside the sandbox with the selected agent’s trusted CA and proxy context. HTTP 200 through 499 confirms that the route is reachable. When the probe returns a recognized broken result, connect attempts DNS or route repair and verifies the route again. When the initial probe cannot return a trusted result, connect fails closed before health-driven repair and before opening SSH. It prints a bounded, redacted last-probe detail and points you to nemohermes <name> doctor. If the sandbox is registered locally but missing from a healthy gateway, connect preserves the registry entry and points you to rebuild --yes, onboard, or destroy instead of deleting the metadata needed for recovery.

After a host reboot, the OpenShell gateway rotates its SSH host keys. connect detects the resulting identity drift, prunes stale openshell-* entries from ~/.ssh/known_hosts, and retries automatically. You no longer need to re-run nemohermes onboard after a reboot in this case.

$nemohermes my-assistant connect [--probe-only]
$nemohermes connect

On Linux, the --probe-only flag is the infrastructure producer for launch-readiness evidence. It validates a usable lease and exits without duplicate recovery. Otherwise, it fences prior evidence, waits for the sandbox, verifies or repairs its in-sandbox agent process and host-side forwards, and publishes evidence only after every probe succeeds. It rechecks the sandbox on its recorded OpenShell gateway after the readiness wait and never restarts the shared host gateway. If an old runtime epoch might exist and cannot be durably rotated, the command exits nonzero before complete preflight or recovery and gives redacted repair guidance. A securely absent runtime authority and receipt let ordinary launch run the complete preflight without optimization if new authority creation fails, but on Linux connect --probe-only still exits nonzero because it could not publish launch-readiness evidence. A runtime failure and, on Linux, a failure to publish evidence for an otherwise healthy runtime also exit nonzero with different diagnostics.

Infrastructure must run the command as the same final numeric user that later runs launch. Run it only after the final durable home and state volume is mounted and after policy and network provisioning is complete. On Linux, that user also needs a secure, independently writable OS per-user runtime authority under /run/user/<numeric-uid>. Do not redirect this authority with caller environment variables. Do not use a graphical or login-session identifier as the deployment ordering boundary. On macOS, connect --probe-only runs the complete preflight, including recovery and probes. After a successful probe and recovery, it prints a note that launch-readiness evidence is unavailable on this platform and exits zero. The next launch runs the complete preflight. On Linux, the publication-failure diagnostic is redacted and does not print filesystem paths or environment values.

Every connect --probe-only completion prints at most one credential-free Probe timing: line. The line always reports these stages in this order, with cumulative whole-millisecond durations:

  • readiness waits for the sandbox state.
  • authority validates launch-readiness authority and evidence.
  • lifecycle reuses or recovers the Portable lifecycle when applicable.
  • gateway verifies the owning gateway path.
  • processes verifies or repairs managed in-sandbox processes.
  • forward verifies or restores required host forwards.
  • inference verifies the selected inference route.
  • pairing settles OpenClaw operator pairing when applicable.
  • publication publishes launch-readiness evidence on Linux.

The line also reports total, lifecycleAction=skipped|reused|recovered|failed, forwardAction=skipped|verified|restored|failed, and result=ready|failed. A failed probe adds failedStage=<stage> or failedStage=unknown. Stages that do not apply or do not run report 0ms. Timing collection and output are fail-open: clock or writer failures do not change the readiness work, command diagnostics, or exit status. Use the command exit status, not a duration or action field, as the readiness decision.

Run it for health checks and scripted readiness probes; users continue to run only nemohermes launch <name>.

Use nemohermes launch <name> when you want launch-readiness validation, an automatic fallback that runs the complete preflight, and then the agent instead of a sandbox shell.

nemohermes <name> exec

Run a single command non-interactively in a running sandbox via the OpenShell exec endpoint. The command runs as the sandbox user with HOME=/sandbox, so in-sandbox tooling resolves NemoClaw-provisioned config the same way it does for connect and openshell sandbox connect. This is the supported substitute for docker exec on the sandbox container; raw docker exec runs as root and lands on HOME=/root, where the selected agent config is not present. For a registered sandbox, NemoClaw selects its recorded owning OpenShell gateway before the workdir probe and command dispatch. If gateway selection fails, exec stops without running the sandbox command.

Hermes config resolves under /sandbox/.hermes.

$nemohermes my-assistant exec -- hermes --version
$nemohermes my-assistant exec --workdir /sandbox/workspace -- ls -la

Everything after -- is forwarded verbatim to the sandbox command, including flags the inner command needs.

The exit code is the remote command’s exit code.

By default, NemoClaw inherits caller stdin only when it is a terminal. Non-terminal or unavailable stdin is closed so SSH, CI, and other one-shot commands cannot wait on an inherited pipe. Pass --stdin to forward an intentional pipe, or --no-stdin to close terminal stdin explicitly.

$printf 'hello\n' | nemohermes my-assistant exec --stdin -- cat
$ssh dgx-spark 'nemohermes my-assistant exec --no-stdin -- pwd'

OpenShell preserves line endings and quote characters inside each command argument, so inline scripts and heredocs can be passed as one argument after --. For example, a shell variable keeps the multi-line script in one argv element:

$script=$'cat <<\'EOF\'\nline one\nline two\nEOF'
$nemohermes <name> exec -- bash -lc "$script"

NUL bytes are still rejected in command arguments. Line breaks are accepted only in command argv: --workdir remains single-line, and NemoClaw does not expose OpenShell request-environment injection on this command.

FlagDescription
--workdir <dir>Working directory inside the sandbox. The directory is checked before the command runs; if it does not exist, NemoClaw reports error: --workdir: <dir> does not exist inside the sandbox and exits with status 1 without invoking the inner command.
--tty / --no-ttyAllocate a pseudo-terminal; defaults to auto-detection (on when stdin and stdout are terminals)
--timeout <seconds>Timeout in seconds (0 means no timeout)
--stdin / --no-stdinForce caller stdin forwarding or closure (default: inherit terminal stdin; close non-terminal or unavailable stdin).

nemohermes <name> agent

The agent wrapper rejects Hermes sandboxes with guidance for the Hermes HTTP API. Each Hermes sandbox exposes an OpenAI-compatible API inside the sandbox on its own port, which defaults to 8642, so non-interactive use does not need a wrapper command. When another sandbox or a host listener already holds 8642, the sandbox receives the next free port from 8642 through 8652. The rejection message names that port and the openshell forward start command for it. Run openshell forward list to read the host bind for each of that sandbox’s forwards.

Forward the port and POST chat completions directly:

$openshell forward start --background 8642 my-hermes
$curl -sN http://127.0.0.1:8642/v1/chat/completions \
> -H 'Content-Type: application/json' \
> -d '{"model":"<onboarded-model>","messages":[{"role":"user","content":"What is 2+2?"}],"stream":true}'

Advanced Sandbox Maintenance Commands

The following commands are available for targeted host-side maintenance, but they are not part of the top-level public command list.

nemohermes <name> config get

Read the sanitized agent configuration from a sandbox. The output removes credential-bearing sections before printing. Use --key to read one dotpath and --format to choose JSON or YAML output.

$nemohermes my-assistant config get
$nemohermes my-assistant config get --key model.default --format yaml
FlagDescription
--key <dotpath>Print one value from the sanitized config
--format json|yamlOutput format. Defaults to JSON

nemohermes <name> config set

Write one value into the agent configuration in a sandbox. The command validates every HTTP and HTTPS URL in the value, including URLs nested inside JSON objects or arrays. It pins an HTTP host to the validated IP address. Configuration changes are unavailable while shields are up, so lower shields with nemohermes <name> shields down first.

$nemohermes my-assistant config set --key agents.defaults.model.primary --value nvidia/nemotron
$nemohermes my-assistant config set --key agents.defaults.timeoutSeconds --value 600 --restart
FlagDescription
--key <dotpath>Dotpath to update in the config. Required
--value <value>Value to write. The command parses a JSON value when it can, and otherwise writes the text as a string. Required
--restartRestart a supported OpenClaw or Hermes gateway after writing
--config-accept-new-pathWrite a dotpath that does not already exist in the config

The command treats a dotpath that does not already exist in the config as a possible typo. An interactive run asks for confirmation before writing the new dotpath. A run without a TTY, or a run with NEMOCLAW_NON_INTERACTIVE=1, refuses the write. Pass --config-accept-new-path, or set NEMOCLAW_CONFIG_ACCEPT_NEW_PATH=1, to write the new dotpath without the confirmation. If the confirmation reaches the end of input, for example when you press Ctrl-D or run the command from a harness that closes stdin, the command exits non-zero without writing and repeats the same guidance.

The command refuses to write gateway or any dotpath under gateway., which holds credentials.

For Hermes, the command validates the complete candidate configuration with the bundled Hermes schema before it writes configuration or integrity metadata. An incomplete structural object is rejected without changing the configuration or hashes. Private URLs remain rejected unless the existing Hermes configuration explicitly sets security.allow_private_urls: true. That opt-in allows private URLs for any Hermes configuration value. Public hostnames still receive DNS validation and pinning. Hermes can restart its gateway when it applies a configuration change. Use --restart when the command must request and verify that restart. config set changes config.yaml only. Hermes startup and rebuild can update managed .env keys and their integrity hashes without printing their values.

nemohermes <name> shields

Manage the sandbox config lockdown posture from the host. Use shields status to inspect the current state, shields up to lock the sandbox config and restore the captured restrictive policy, and shields down to temporarily unlock the config for maintenance.

For the full mutability matrix, refer to Understand Runtime Changes.

$nemohermes my-assistant shields status
$nemohermes my-assistant shields up
$nemohermes my-assistant shields down --timeout 5m --reason "maintenance"
SubcommandDescription
shields statusShow whether lockdown is configured, active, temporarily unlocked, or in error
shields upLock the sandbox config and restore the saved restrictive policy
shields downTemporarily unlock the sandbox config. Supports --timeout, --reason, and --policy

If OpenShell rejects the permissive policy before it is applied, shields down returns an error and keeps the sandbox in the Shields up state. The command clears the provisional Shields down record and timer, and shields status remains UP. If that record cannot be cleared and NemoClaw writes the rejection marker, shields status derives UP from that marker. The auto-restore timer and transition remain the recovery authority. If the rejection marker also cannot be written, shields status reports the incomplete transition as an error.

If a config path is unsafe, for example a symlink at the Hermes config.yaml path, shields down refuses that path before it weakens policy, writes a provisional Shields down record, or starts a timer. The command returns an error and shields status remains UP. If an unsafe path appears after the preflight and a provisional Shields down record already exists, the command restores the restrictive policy when it can but keeps the Shields down record until config protection is positively re-verified. This fail-closed behavior also applies when unlock fails after a partial mutation, and requires manual intervention if re-lock cannot be confirmed.

If shields up reports that the config remains unlocked or drifted, confirm that the sandbox is running and ready, then retry nemohermes <name> shields up. If the retry still fails, rebuild a known-good baseline with nemohermes <name> rebuild --yes.

Host-side config and inference writes, snapshot mutation, sandbox destruction, and shields transitions serialize per sandbox.

Host-side gateway recovery uses the same per-sandbox serialization.

For a current NemoClaw-managed Hermes image on the Docker driver, shields status is a recovery and reconciliation command, not only a display command. It first recovers any retained exact runtime provider state mutation, then applies and verifies the declared recursive posture. A result exits with status 0 only after the command verifies that posture. A status check can therefore complete work retained by an interrupted host process.

If provider recovery restores lockdown while the persisted Shields posture still says mutable, status prints ERROR (runtime-provider recovery restored lockdown), exits with status 2, and tells you to retry the intended Shields transition. If live verification of a mutable default or timed Shields down posture fails, status prints NOT CONFIGURED (DRIFTED...) or DOWN (DRIFTED...), exits with status 2, and directs you to run nemohermes <name> shields up to reconcile and verify lockdown. Status does not report UP, DOWN, or mutable-default with exit status 0 when the provider cannot verify the exact recursive posture.

While an exact provider fence is active, ordinary direct-container, SSH, and OpenShell command transports are refused before a sandbox process starts. They report Runtime provider state mutation owns direct-container execution for sandbox '<name>'; retry after the provider fence is released. Recover and retry as follows:

  1. Let the active Shields or recovery command finish.
  2. Run nemohermes <name> shields status.
  3. Retry the original command only after provider verification completes and the command exits with status 0.

Older managed Hermes images use the sealed-plan transition only when the current provider capability is proved absent. Custom images and legacy Dockerfile workflows remain on their existing transition contract and do not use provider-state-mutation-v2.

Before shields down opens a new window, NemoClaw must revoke any stale auto-restore timer authority. If marker cleanup fails, the command reports Cannot revoke stale auto-restore timer authority and stops before policy capture, state writes, config unlock, replacement-timer startup, or audit writes. The sandbox retains its existing configuration and policy posture, and the stale timer authority remains. Resolve the reported timer-marker error on the trusted host, then retry shields down. When a timed Shields window reaches its deadline, auto-restore closes the per-sandbox lifecycle deadline gate before it restores lockdown. nemohermes <name> shields status can finish cleanup for a completed, abandoned auto-restore, but live or ambiguous ownership remains fail-closed. For retry budgets, containment behavior, and safe remediation for each retained-artifact state, see Timed Shields Windows.

Shields treats OpenShell’s current policy as authoritative. shields down captures that document as bounded transaction state and preserves its live MCP entries in the temporary relaxed policy without consulting a policy ownership manifest. Restoration performs a three-way reversal of only the changes made by that Shields transaction: a host-side edit made while Shields is down is preserved, while an unchanged temporary value is restored to its pre-transition value. The snapshot and forward document are deleted when the transaction completes; neither becomes durable desired policy state.

nemohermes <name> recover

Repair a stopped in-sandbox gateway and re-establish host-side forwards without opening an SSH session. Use this after a sandbox crash or whenever nemohermes <name> status reports that the sandbox container or agent gateway is not running.

For a stopped, non-paused Docker-driver container, recover starts the existing container before it waits for OpenShell readiness. It leaves a running or paused container unchanged. If Docker cannot start the container, recover continues to the readiness check and reports the resulting failure.

recover waits up to 30 seconds to acquire the per-sandbox lifecycle lock. After acquisition, it holds the lock until gateway recovery and forward repair finish.

For built-in OpenClaw and Hermes sandboxes, recover sends an authenticated lifecycle request through registry-scoped privileged direct-container control. The host selects the controller from the live container topology. In a direct root-entrypoint container, the request reaches the root PID 1 supervisor. In an OpenShell-managed container, the request enters the root-owned mode 0500 managed controller through a sanitized root exec while OpenShell remains PID 1. It does not use ordinary openshell sandbox exec or an in-sandbox manual relaunch as a fallback. When the root-owned managed controller attests two unchanged zero-supervisor process scans with a stable PID 1 and reports SUPERVISOR_NOT_RUNNING, a local Docker-driver sandbox with the legacy keepalive startup can enter a transactional container recreation. The recreation uses a credential-free managed startup command, pins the registered container identity, and retains the previous container for rollback. Before recreation, NemoClaw backs up the state directories and files declared by the agent manifest. NemoClaw waits for the exact replacement to pass managed gateway health and OpenShell re-registration before it restores state. After state restoration, it restarts the gateway in the exact replacement container and requires an authenticated ok result. It then runs the managed settle check. It commits only after the replacement identity, state restoration, gateway restart, and settle check pass. At the final commit handoff, NemoClaw asks OpenShell to stop the sandbox before it mutates either exact container. After OpenShell acknowledges that stop, NemoClaw stops the exact replacement, removes the rollback container, and asks OpenShell to start the sandbox through its authoritative lifecycle path. This preserves OpenShell’s stopped/starting event fence while stale Docker removal snapshots settle; raw Docker stop/start events cannot strand the lifecycle row in Error or Deleting. If the authoritative stop fails, NemoClaw leaves both containers intact. If the start or final Ready/exec/exact-container proof fails after rollback-container removal, NemoClaw reports that automatic rollback is unavailable. If OpenShell re-registration, state restoration, or a later gateway check fails, NemoClaw attempts to roll back the replacement. The primary dashboard or API host forward stays stopped. NemoClaw removes the temporary state backup after a successful restore or rollback. If state restoration and rollback both fail, it retains the backup and prints host recovery guidance. Mounted state remains available, but a committed swap does not retain other writable-layer changes. It is idempotent. When recover repairs a stopped built-in OpenClaw or Hermes gateway, it repeats the recovery action only for these exact transient results:

  • Status 1 with blank stdout and exactly one stderr line: SUPERVISOR_NOT_RUNNING, SUPERVISOR_DISCOVERY_PENDING, PRIVILEGED_CONTROL_UNAVAILABLE, GATEWAY_HEALTH_TIMEOUT, or SUPERVISOR_BUSY.
  • Status 137 with blank stdout and stderr.
  • Status 1 with blank stdout and exactly one stderr line, Error response from daemon: Container <id> is restarting, wait until the container is running.

For the Docker result, <id> must be a 64-character lowercase hexadecimal ID that matches the selected registry-owned container. Recovery makes at most 11 controller attempts in total. It stops after 3 of those attempts return SUPERVISOR_BUSY. The managed controller emits SUPERVISOR_DISCOVERY_PENDING only when an incomplete process-table scan during startup cannot yet prove either one exact supervisor or clean supervisor absence. That result delays recovery but cannot authorize container recreation or accept a supervisor identity; a later request must perform the complete identity proof again. Managed settle confirmation treats exact SUPERVISOR_BUSY and SUPERVISOR_DISCOVERY_PENDING results as inconclusive within its configured window. Status 137 and the Docker restart result remain terminal during that confirmation. The managed supervisor startup waiter accepts the four exact startup results, SUPERVISOR_BUSY, and the two container-transition results within its separate 11-attempt bound. Unbound container IDs, reformatted Docker errors, status 137 with nonblank output, and other diagnostic results are terminal. NemoClaw treats SUPERVISOR_UNAVAILABLE as terminal because the managed controller uses it for integrity refusals, ambiguous discovery, and process-identity changes. It does not repeat the recovery action or treat the settle probe as inconclusive, and instead prints host-side restart and rebuild guidance. Other controller failures also stop immediately. Only an exact SUPERVISOR_NOT_RUNNING result that remains after the bounded startup retries can enter transactional legacy keepalive recreation. The pinned controller probe must then confirm the missing supervisor before recreation proceeds. If the gateway is already running, the command exits zero without force-restarting it; it can still re-evaluate supported safety checks and check or recover host-side forwards. Use nemohermes <name> gateway restart when you deliberately need a running gateway to reload runtime configuration or plugins.

$nemohermes my-assistant recover

For a published receipt-owned Portable Ollama runner, recover uses the same inference recovery path as connect --probe-only. Follow Recover Portable Published Ollama for authority checks, route proof, rollback, and failure handling.

For an active Portable Hermes receipt, recover starts only the exact receipt-owned Podman container when it is stopped. If authenticated health is not ready after that start, recovery launches the receipt-owned nemoclaw-start command once and waits for authenticated Hermes health. For an already-running container, recovery does not launch the startup command, does not stop the container, and only waits for authenticated health. If a container or OpenShell identity check, reconnect check, or health check later fails after recovery started the container, NemoClaw stops that exact container. It then requires Podman to report the container as exited and OpenShell to report Error or Stopped. If NemoClaw cannot prove that rollback, the command reports both the recovery failure and the rollback failure.

recover re-evaluates the documented Hermes secret boundary against /sandbox/.hermes/.env and the supervisor runtime environment on every run, including when the gateway is already healthy. If the file contains raw secret-shaped values (for example a pasted Telegram, Discord, or Slack bot token in place of the expected openshell:resolve:env:<name> placeholder), the command exits non-zero and prints the offending key. The direct root-entrypoint supervisor stops a running gateway after this refusal, while the managed controller refuses before signaling the observed child. Replace each flagged value with the openshell:resolve:env:<name> placeholder and re-run. The direct root-entrypoint supervisor verifies the strict root-owned config hash. The managed controller verifies that strict hash when both Hermes config inputs are root-owned and locked. Mutable config under the managed topology has no durable root-owned hash anchor and retains the same trust and time-of-check/time-of-use limits as managed cold start. If the boundary validator or supervisor helper is missing, recovery fails closed, names the sandbox, explains that /sandbox/.hermes/.env could not be re-evaluated, and leaves an otherwise healthy gateway untouched. Rebuild an older sandbox image with nemohermes <name> rebuild --yes before retrying.

While a NemoClaw cron restore gate exists, Hermes recover keeps the same lifecycle lock through restore validation and gate release. That controller call has a 130-second host timeout; the earlier 30-second limit applies only to lifecycle-lock acquisition.

After gateway and forward recovery, Hermes recover also checks for a NemoClaw cron restore gate retained by an interrupted rebuild. It validates the restored cron jobs and scripts before it clears that gate, and it leaves an independent Hermes operator drain active. A validation failure leaves the NemoClaw gate in place so new Hermes turns and cron dispatch remain blocked.

The privileged control path requires a running direct sandbox container that belongs to the named registry entry. Supported built-in images use either a direct root entrypoint or the OpenShell-managed process shape with OpenShell as PID 1 and exactly one nonroot nemoclaw-start supervisor. An arbitrary nonroot entrypoint that does not match the supported OpenShell-managed process shape fails with the privileged control unavailable failure layer. Kubernetes and other deployments without a matching direct container also fail with that layer.

nemohermes <name> gateway restart

Force-restart the supported in-sandbox gateway process through the controller for the live container topology. Use this after runtime configuration or plugin changes that the agent reads only at gateway startup, such as Hermes Langfuse plugin settings. Unlike recover, this command restarts a healthy gateway instead of exiting after the health probe.

$nemohermes my-assistant gateway restart [--quiet|-q]

On success, the command reports that the gateway was restarted, health passed, and forwards were checked or recovered. It also checks the dashboard forward, messaging forward, and manifest-declared agent forwards. --quiet suppresses progress lines but still prints refusal diagnostics. In the direct root-entrypoint topology, PID 1 stops only the gateway child whose process ID and process start identity match the tracked child, applies the restart seal, and launches the replacement under the separate gateway UID. In the OpenShell-managed topology, the installed root controller verifies a stable OpenShell to nemoclaw-start to gateway process shape, holds a root-only lifecycle lock, publishes one root-owned exit authorization bound to the exact gateway process ID, kernel start identity, and live controller identity, pidfd-targets the observed child, waits for the nonroot entrypoint supervisor to respawn it under the sandbox UID, and proves the replacement listener and HTTP health. That managed process proof prevents PID reuse from redirecting the signal but cannot establish provenance against a malicious same-UID process or create gateway and agent UID isolation. For Hermes, the entrypoint supervisor also owns the dashboard process, internal API relay, dashboard relay, and gateway log stream. The managed nonroot supervisor continuously repairs those processes, stops an alive but deaf gateway after four consecutive failed health checks, and quarantines relaunch after five unexpected exits or failed replacement candidates within 60 seconds until sandbox recreation. That authorization keeps an authenticated host-requested exit out of the crash budget while its exact root controller remains live; it records host intent for the exit but does not claim that the host signal was the only possible cause in the shared-UID topology. The host repairs only the host-side OpenShell forwards after the supervisor reports a healthy gateway.

For Hermes, both controllers validate /sandbox/.hermes/.env against the secret-boundary guard and validate the supervisor runtime environment before restart. The direct root-entrypoint supervisor verifies /sandbox/.hermes/config.yaml and .env against the root-owned strict hash and relaunches the process as the gateway user. The managed controller verifies the strict hash when both config inputs are root-owned and locked, but mutable managed config retains cold-start-equivalent trust and time-of-check/time-of-use limits. Neither controller recomputes a trusted strict hash to adopt direct in-sandbox edits. Use supported host commands such as nemohermes <name> config set and nemohermes inference set for intended runtime configuration changes because those commands update the managed config metadata together. When a strict hash is available and does not match, the command reports the config hash mismatch failure layer. Hermes host config writes, shields transitions, and lifecycle seals share one root-only mutation lock. Config writes are bound to the digest of the matching read and atomically refresh the strict and compatibility hashes before the prior ownership and mode posture is restored. The shields transition keeps that lock through recursive filesystem updates, verification, and content-seal capture, and replaces sensitive inodes before lockdown. If a concurrent lifecycle request reports SUPERVISOR_BUSY, or a config or shields command reports Hermes config mutation is already in progress, wait for the active operation to finish and retry. Run nemohermes <name> shields down before a Hermes config or inference change; these commands refuse to mutate a shields-up sandbox.

The command can fail at these layers: unsupported agent, privileged control unavailable, supervisor not running, secret-boundary refusal, unsafe config path, config hash mismatch when a strict hash is available, MCP reconciliation refusal, relaunch quarantined, launch failure, health timeout, or forward recovery failure. relaunch quarantined means the in-sandbox supervisor stopped attempting relaunch after a startup refusal or repeated gateway exits, so restart and recovery report the supported repair, nemohermes <name> rebuild --yes, instead of a retry. An older direct-container image without the matching supervisor or managed controller helper reports privileged control unavailable and requires nemohermes <name> rebuild --yes. Ordinary OpenShell exec and manual in-sandbox relaunch are not fallback paths. Terminal agents do not have a gateway runtime and fail as unsupported.

nemohermes <name> stop

Stop the sandbox’s local runtime container while preserving all of its state. Workspace files, credentials, network policies, the registry entry, and the OpenShell sandbox record stay in place. Use this to free CPU, memory, and GPU resources without destroying the sandbox; use nemohermes <name> destroy when you want to delete it instead.

$nemohermes my-assistant stop

For an active Portable Hermes receipt, stop targets only the exact receipt-owned Podman container and waits for its terminal stopped state without using Docker as a fallback. A pending or configuring receipt instead directs you to resume Portable onboarding. Portable Hermes does not run the Docker provider’s channel hook or the generic post-stop dashboard-forward cleanup.

For OpenClaw-managed gateways, the command first asks the in-sandbox gateway to shut down its channels gracefully; non-Portable agent-managed gateways (for example Hermes) are supervised inside the sandbox and shut down with the container’s stop signal. Then the container stops; a container stuck in a crash loop is stopped the same way, which also disarms its restart policy.

Except for Portable Hermes, after the container stops NemoClaw attempts to stop that sandbox’s host dashboard forward. If the container does not stop, NemoClaw leaves the dashboard forward running. The shared host gateway, tunnel services, and any local NIM inference container serve other sandboxes and keep running. Stopping an already-stopped sandbox succeeds. Except for Portable Hermes, NemoClaw also attempts to remove any leftover dashboard forward for that sandbox. The command is available only when NemoClaw holds local-container authority. Portable profiles use receipt-owned Podman authority; non-Portable local-container paths use the default Docker driver or the vm driver. Remote drivers such as kubernetes are unavailable, and an unreachable selected runtime produces an outage report instead of a guessed container state.

nemohermes <name> start

Restart a sandbox container that was stopped with nemohermes <name> stop or by a host reboot, then repair the in-sandbox gateway and host-side forwards the same way nemohermes <name> recover does.

$nemohermes my-assistant start

For an active Portable Hermes receipt, start follows the exact Podman container, supervisor, authenticated health, and rollback contract documented for recover; it does not fall back to Docker. A pending or configuring receipt instead directs you to resume Portable onboarding.

Starting an already-running sandbox skips the container start and still runs the gateway and forward health checks. A paused container is unpaused. If the container was removed entirely, start fails and points you to nemohermes <name> rebuild.

Before it repairs the gateway and host forwards, start waits for OpenShell to report the sandbox in the Ready or Running state, using the same 300-second budget and NEMOCLAW_CONNECT_TIMEOUT override as connect --probe-only. When that deadline expires, start keeps the existing container, exits non-zero, and prints the NEMOCLAW_CONNECT_TIMEOUT value to use on the next run.

After the gateway and forward checks pass, start sends one inference request through https://inference.local using the sandbox’s recorded provider and model. A gateway that answers the /v1/models probe can still reject an inference request or return an invalid result, so the command exits non-zero in either case. It prints the probe result, including the HTTP status when the route returned one, and points you to the sandbox doctor command. Each run sends one 16-token request through the stored provider credential, so start waits up to 30 seconds for it and consumes provider tokens on a hosted route. When the sandbox records no provider or no model, start skips the request and exits 0. doctor still classifies an HTTP 401 or 403 route response as reachable, so correct the provider credential when start reports one of those statuses.

nemohermes <name> status

Show sandbox-scoped status, health, and inference configuration for one registered sandbox. Use this form when you care about a specific sandbox’s live OpenShell state, agent runtime, inference health, GPU proof, permissions, and recovery hints. Do not pass a sandbox name to nemohermes status; that command is the global all-sandbox/service overview. NemoClaw resolves the sandbox’s recorded owning OpenShell gateway before querying live state. If another gateway is active, it selects the owner and queries again instead of trusting a result from the sibling gateway.

For Portable Hermes, status reports Portable lifecycle phase: pending, configuring, or active from the receipt authority without running Docker or OpenClaw status work. An active receipt must match its sandbox registry lifecycle identity; a mismatch fails instead of reporting status from another runtime.

For a compatible-endpoint route that uses openai-completions, the text output prints Reasoning effort as low, medium, high, or endpoint-default. The line is omitted for another provider or API family.

Pass --json to emit a structured per-sandbox report instead of the text renderer. The JSON output includes at least schemaVersion, name, found, agent, agentDisplayName, agentRuntime, dcodeAutoApprovalMode, model, provider, recordedRoute, liveRoute, routeDrift, phase, gatewayState, inferenceHealth, rpcIssue, hostGpuDetected, sandboxGpuEnabled, sandboxGpuMode, sandboxGpuDevice, openshellDriver, openshellVersion, policies, policiesAvailable, failureLayer, terminalRuntimeHealth, servingProcessHealth, and dockerPaused. policies is derived from the current OpenShell policy; NemoClaw does not persist a second preset list or baseline-exclusion ledger. policiesAvailable is false when that live policy cannot be read or parsed, distinguishing an unavailable result from a verified empty policies array; text status prints Policies: unavailable for the same state. The schema-version 1 model and provider fields keep their established live-route meaning when the gateway route is readable. Use recordedRoute for the sandbox’s durable provider and model and liveRoute for the gateway-global route. When the live shared route differs, text output prints both routes and JSON output sets routeDrift.live, routeDrift.recorded, and routeDrift.canConnect. When routeDrift.canConnect is false, connect cannot safely restore the recorded route because provider-global identity differs or required route or gateway metadata is incomplete. Refer to Use Shared Gateway Routes for the route-sharing workflow. openshellDriver and openshellVersion are always strings (falling back to "unknown" when the registry has no value), so consumers can rely on typeof checks. agent is always a string and reports openclaw when the registry records no agent for the sandbox. failureLayer is null when no preflight failure was detected and otherwise one of docker_unreachable, sandbox_container_stopped, or sandbox_dashboard_port_conflict; when set, inferenceHealth is suppressed to null so automation does not see a stale remote-provider healthy status during a local outage. inferenceHealth.ok reports whether the inference route returned a structurally valid result for one request sent from inside the sandbox. The result must match Chat Completions, Responses, or Anthropic Messages for the selected route. An empty body, malformed JSON, provider-error envelope, or wrong response shape reports unhealthy, even with a 2xx status. The probe captures at most 64 KiB and does not include the response body in diagnostics. The route probe treats any final HTTP status from 200 through 499 as reachable, so a route with an invalidated provider credential answers HTTP 401 while the route is up. The request uses the live gateway route’s provider and model, and falls back to the recorded values when the live route is unreadable. When the live provider matches the recorded provider, the request uses the sandbox’s recorded API family, even when only the model differs. This includes openai-responses. When the live provider differs, NemoClaw does not carry the recorded API family to the live provider. An ordinary run sends one 16-token request through the stored provider credential, with a 30-second timeout, and consumes provider tokens on a hosted route. When the same status run recovers a managed gateway, it retries the route and inference request together up to three total attempts, with a two-second delay between failed attempts. Each attempt can consume another 16 tokens on a hosted route. When NemoClaw sends an inference request, inferenceHealth.subprobes reports the route probe result as the route reachability hop, so a failing verdict still shows that the route itself answered. inferenceHealth.failureLabel reports why the inference request failed:

  • unauthorized when the route rejected it with HTTP 401 or 403.
  • unhealthy when the route returned another failing HTTP status or an invalid 2xx response body.
  • unreachable when the request returned no HTTP status, including a probe that could not run.

A host-side upstream probe under inferenceHealth.subprobes stays a diagnostic and does not change inferenceHealth.ok, because the sandbox route is the one the agent uses. When the route probe failed, or the sandbox records no provider or no model, NemoClaw skips the inference request and inferenceHealth reports the route probe result alone. dockerPaused is true when NemoClaw detects that the Docker-driver sandbox container is paused. In that case, text output keeps OpenShell’s authoritative phase but prints a docker unpause <container> recovery hint instead of sending you directly to rebuild. For terminal runtime sandboxes, the command also checks cgroup OOM kill counters. If the counter records an OOM kill, text output prints Runtime health: degraded (... OOM kill recorded) and points you to nemohermes <name> rebuild; JSON output reports terminalRuntimeHealth.kind: "degraded" with the OOM kill count and source counter path. For a present gateway runtime, text output prints Serving process (<agent> gateway): not checked, and JSON output reports servingProcessHealth: { "checked": false }. The existing inference probes run in a fresh sandbox command, so they do not attest that the long-running gateway process has equivalent inference access. NemoClaw does not probe the serving process yet. For terminal runtimes, servingProcessHealth is null and the text output omits this line because there is no long-running gateway process. The command exits non-zero when the sandbox is missing locally, the gateway state is not present, the gateway reports a schema/protobuf mismatch (mirrored as rpcIssue), failureLayer is non-null, the authoritative in-sandbox inference route fails or cannot be probed, or a terminal runtime sandbox reports a recorded OOM kill. When the canonical text command targets an unregistered name, it reports that the sandbox is not registered and tells you to run nemohermes list. The alias form nemohermes <name> status --json requires the sandbox to be registered locally; the canonical form nemohermes sandbox status <name> --json is the one to use from automation that may run against an unknown sandbox name, since it still emits a JSON document with found: false instead of a text error.

For a sandbox that owns managed llama.cpp, text output also reports the recipe ID, model digest, image reference, https://inference.local/v1 endpoint, and lifecycle state. It does not print the managed API key or its fingerprint. The lifecycle state is one of these values:

StateMeaning
preparingThe gateway-scoped owner exists, but receipt.json is absent.
runningThe exact receipt-owned container is running under the recorded Docker authority.
stoppedThe exact receipt-owned container exists but is stopped.
absentThe finalized receipt exists, but its exact container is absent.
conflictThe Docker authority or runtime identity differs from the receipt.
unknownNemoClaw cannot read or prove the state.

The managed llama.cpp check forces a nonzero exit for absent, conflict, or unknown. Other sandbox and inference checks can also make the command fail. Rerun the same NEMOCLAW_PROVIDER=install-llama-cpp and NEMOCLAW_LLAMACPP_RECIPE onboarding selection to recover a stopped or interrupted runtime. Inspect and correct an identity conflict before retrying.

$nemohermes my-assistant status
$nemohermes my-assistant status --json
$nemohermes sandbox status my-assistant --json

The command probes https://inference.local/v1/models from inside the sandbox, and when that probe reports the route reachable it sends one inference request over the same route. That inference request is the authoritative inference health check, and both checks exercise the route that agent traffic uses. The main Inference line reports one of these states:

StateMeaning
healthyThe route returned a structurally valid result for the inference request.
unauthorizedThe route rejected the inference request with HTTP 401 or 403.
reachableThe route returned an HTTP status from 200 through 499 and NemoClaw did not send an inference request.
unhealthyThe route returned HTTP 500 through 599, another failing status, or an invalid 2xx response body.
unreachableThe route had a transport failure, returned no final HTTP status (000 or an interim 100 through 199), returned an invalid status outside 100 through 599, or the inference request returned no HTTP status.
not probedNemoClaw could not run the authoritative route probe from a reachable sandbox.
not verifiedNemoClaw could not verify the sandbox or gateway state, so it skips inference probing.

An authentication response on the route probe alone confirms that the route is reachable, not that provider credentials are valid. nemohermes <name> doctor sends no inference request, so it reports an HTTP 401 or 403 route response as reachable and exits 0 where status reports unauthorized. The command can also print direct host-side provider checks such as Inference (upstream) and provider-specific subprobes. For supported remote providers, this diagnostic sends an authenticated request to the configured model and accepts only a recognized Chat Completions, streaming Chat Completions, or Anthropic Messages response. It uses a 3-second connection timeout, a 5-second total timeout, and an 8-token output limit. If the request reaches the time limit, NemoClaw reports the provider as not probed and leaves model health unverified instead of reporting it as unhealthy. These checks are diagnostic only and do not override the authoritative inference.local result or determine the command exit status.

The Inference (upstream) check authenticates with the host credential that NemoClaw resolves for the provider, such as NVIDIA_INFERENCE_API_KEY. The gateway stores the provider credential that the sandbox route uses. The CLI cannot read the stored value back, so the two credentials can hold different secrets. When the inference.local route has already served the inference request, an unauthorized result on Inference (upstream) describes the host credential. NemoClaw then reports that check as not probed and names both credential sources. An Inference (upstream) check that fails for another reason, such as unreachable, still reports its own state. Local backend and auth proxy checks, such as Inference (auth proxy), always report their own state and their own repair step. nemohermes <name> doctor sends no inference request, so it always reports the Inference (upstream) state that it measured.

Local providers add host-side backend diagnostics. For Local Ollama, the command can also print an Inference (auth proxy) diagnostic when a proxy token is available. Use these diagnostics to identify a failing auxiliary hop after checking the main Inference line.

For cloud-only providers, the output omits the NIM status line unless a NIM container is registered or an unexpected NIM container is running.

When the sandbox’s recorded driver is docker and the host Docker daemon is not reachable, the command prints the docker_unreachable failure layer with the message Docker daemon is not reachable. as the first line of stdout, suppresses the host-side Inference probe (which otherwise hits the remote provider directly and is misleading when the local stack is down), and exits with a non-zero status.

When the host Docker daemon is reachable but the per-sandbox container is stopped, the initial preflight records the sandbox_container_stopped failure layer and suppresses the host-side Inference probe. If the owning OpenShell gateway is healthy but no longer lists the registered Docker-driver sandbox, status attempts post-reboot recovery from the labeled container. It waits for Docker readiness, restores the in-sandbox gateway and host forwards, and refreshes preflight before probing inference. A successful recovery clears the stale stopped-container failure.

When status finds the sandbox but cannot prove its agent delivery chain, it exits non-zero and reports the sandbox_recovery_failed state. Address the reported recovery layer, then run the displayed nemohermes <sandbox-name> recover command. If the sandbox’s recorded dashboard port is also held by a foreign listener, the header escalates to the sandbox_dashboard_port_conflict failure layer with the message sandbox container is stopped and the dashboard port is held by a foreign listener. so the operator can recover the port before restarting the sandbox.

If the sandbox or gateway cannot be verified, the command exits non-zero instead of reporting healthy inference from stale registry state. When a locally registered sandbox is missing from the live gateway, status preserves the registry entry for inspection and directs the operator to remove that stale entry with nemohermes <name> destroy --yes before clean onboarding. Rebuild cannot recreate a missing sandbox because no authoritative OpenShell policy remains.

Gateway and dashboard health checks treat HTTP 401 from device auth as a live service, not as an offline gateway.

When sandbox GPU passthrough is enabled, the Sandbox GPU line includes the last CUDA usability proof state. It reports (CUDA verified), (CUDA unverified), or (last CUDA proof failed: <label>) so automation and operators can distinguish configured GPU passthrough from proven CUDA access. Failed proofs include remediation guidance for the detected platform.

An SSH sessions line reports how many active SSH sessions the sandbox has, or none; the line is omitted when the session probe is unavailable.

The sandbox list in the status output includes the dashboard port suffix for sandboxes with a recorded dashboard port.

The Policy section displays the live enforced policy (fetched via openshell policy get --full), which reflects presets added or removed after sandbox creation. When OpenShell reports an active policy version, the displayed YAML version line uses that active version instead of the static schema version. If the sandbox is running an outdated agent version, the output includes an Update line with the available version and a nemohermes <name> rebuild hint.

When NemoClaw detects a messaging overlap between sandboxes in the selected OpenShell gateway’s sandbox registry, the output includes a cross-sandbox overlap warning. The command cannot report overlaps in an independent OpenShell gateway’s registry. The command also tails /tmp/gateway.log inside the default sandbox and flags Telegram 409 Conflict errors that indicate a duplicate consumer for the bot token.

$nemohermes my-assistant status

Checking the Hermes version

Refer to Update Sandboxes for the Hermes version pin and rebuild policy.

nemohermes <name> status prints the running Hermes version on the Agent line:

$nemohermes my-assistant status

Expected output:

...
Agent: Hermes v<version>
...

If the sandbox is running an older Hermes version than this NemoClaw release expects, status and connect add an Update line pointing at nemohermes <name> rebuild to pick up the newer version. The rebuild reuses the existing sandbox name and persisted credentials, so messaging tokens and provider keys carry over.

nemohermes <name> doctor

Run a focused health check for one sandbox and the host services it depends on. The command checks the local CLI build, Docker daemon, OpenShell CLI, NemoClaw gateway container, gateway port mapping, live sandbox state, inference route, configured-provider model invocation, Ollama reachability, and the cloudflared tunnel state.

For gateway-based agents, it also reports messaging channel conflicts within the selected OpenShell gateway’s sandbox registry.

doctor also checks whether the sandbox registry contains the metadata required for snapshot, rebuild, upgrade, recovery, and reboot. When lifecycle metadata is incomplete, the report names the missing or invalid fields and affected operations without printing stored values. Dashboard metadata is required only for agents that manage a dashboard. The Registered gateway binding result depends on the sandbox registry:

  • For a registered sandbox with a valid binding, doctor reports a successful check with the resolved gateway name.
  • For a registered sandbox with an invalid binding, the check fails, and doctor does not select, probe, or recover a gateway from that binding.
  • For an unregistered sandbox name, doctor uses the gateway selected by NEMOCLAW_GATEWAY_PORT for its other gateway checks and omits the Registered gateway binding check.

For Portable Hermes, doctor reports a Portable lifecycle check with the receipt phase. The pending and configuring phases produce a warning, while active passes when the receipt and registry authority agree. This read-only path does not run Docker or OpenClaw checks, and doctor --fix is not supported while the Portable Hermes receipt exists.

For inference health, doctor treats the probe to https://inference.local/v1/models from inside the sandbox as authoritative. HTTP responses from 200 through 499, including 401 and 403, pass this check. HTTP 500 through 599, interim 100 through 199, transport failures with status 000, invalid status values, and an unavailable authoritative probe fail the check. Direct provider and upstream probes use the same authenticated model-invocation checks as status and remain diagnostic only, so their failure does not fail doctor when the authoritative in-sandbox route is reachable. For gateway runtimes, doctor also reports an informational Serving process: not checked result because its fresh sandbox probes do not attest the long-running gateway process. This result does not fail the readiness check. Terminal runtimes omit it because they have no long-running gateway process. The Inference Route check warns when either the provider or model is unknown. After the gateway is healthy, run nemohermes <name> status to refresh the route information.

Warnings do not make the command fail. Failed checks, including a failed or unavailable authoritative inference route, exit non-zero so scripts can use doctor as a readiness gate. Use --json for machine-readable output. For a compatible-endpoint route that uses openai-completions, the JSON report includes an informational Inference check labeled Reasoning effort. The check reports low, medium, high, or endpoint-default and never includes credentials. Because the check has info status, it does not change the command’s exit status.

For a sandbox that owns managed llama.cpp, doctor adds secret-free identity and runtime checks. The runtime check passes only when the exact container is running. It warns for preparing or stopped, and it fails for absent, conflict, or unknown. The recovery hint tells you to rerun onboarding for the same sandbox so NemoClaw can use the persisted receipt and create journal.

$nemohermes my-assistant doctor [--json]
FlagDescription
--jsonEmit the report as JSON

nemohermes <name> exec

Run a command non-interactively inside a running sandbox through the OpenShell exec endpoint. The command runs as the sandbox user with HOME=/sandbox. Use -- to separate exec options from the command you want to run inside the sandbox.

The command exits with the remote command’s exit code.

$nemohermes my-assistant exec [--workdir <dir>] [--tty|--no-tty] [--timeout <s>] [--stdin|--no-stdin] -- <cmd> [args...]

By default, NemoClaw inherits caller stdin only when it is a terminal. Non-terminal or unavailable stdin is closed so SSH, CI, and other one-shot commands cannot wait on an inherited pipe. Pass --stdin to forward an intentional pipe, or --no-stdin to close terminal stdin explicitly.

OpenShell preserves line endings and quote characters inside each command argument, so inline scripts and heredocs can be passed as one argument after --. For example, a shell variable keeps the multi-line script in one argv element:

$script=$'cat <<\'EOF\'\nline one\nline two\nEOF'
$nemohermes <name> exec -- bash -lc "$script"

NUL bytes are still rejected in command arguments. Line breaks are accepted only in command argv: --workdir remains single-line, and NemoClaw does not expose OpenShell request-environment injection on this command.

FlagDescription
--workdir <dir>Set the working directory inside the sandbox. The directory is checked before the command runs; if it does not exist, NemoClaw reports error: --workdir: <dir> does not exist inside the sandbox and exits with status 1 without invoking the inner command.
--tty, --no-ttyAllocate or disable a pseudo-terminal; defaults to auto-detection
--timeout <s>Timeout in seconds. Use 0 for no timeout
--stdin, --no-stdinForce caller stdin forwarding or closure (default: inherit terminal stdin; close non-terminal or unavailable stdin).

nemohermes <name> logs

View sandbox logs. Use --follow to stream output in real time. Use --tail <lines> or -n <lines> to limit the number of returned lines. Use --since <duration> to show recent logs only, such as 5m, 1h, or 30s. The command reads both agent gateway output and OpenShell audit events, so policy denials appear alongside the gateway log stream. If one log source is unavailable, NemoClaw prints a warning and keeps reading the remaining source. NemoClaw’s --tail <lines> flag is a line-count flag; the lower-level openshell logs --tail flag means follow live output, so use openshell logs <sandbox> -n <lines> when running OpenShell directly for a fixed line count.

$nemohermes my-assistant logs [--follow] [--tail <lines>|-n <lines>] [--since <duration>]

nemohermes <name> dashboard-url

Print the browser dashboard URL for a running Hermes sandbox. Hermes manages dashboard sessions itself, so this command prints a plain URL without an OpenClaw #token= fragment. The built-in dashboard is forwarded on port 18789 by default.

$nemohermes my-assistant dashboard-url
$nemohermes my-assistant dashboard-url --quiet

The Hermes OpenAI-compatible API is separate and serves /v1 on a per-sandbox port that defaults to 8642. Run openshell forward list to read the host bind for the dashboard and API forwards.

nemohermes <name> gateway-token

Print the Hermes API bearer token for a running sandbox to stdout. NemoClaw retrieves the sandbox’s API_SERVER_KEY, which authenticates OpenAI-compatible clients on the forwarded API port. During a normal sandbox lifecycle, the token is generated once for each sandbox home. Different sandbox homes receive different tokens. NemoClaw preserves it across a gateway restart, sandbox stop and start, and host OpenShell gateway restart. When you rebuild or replace the sandbox, the replacement home receives a new token. At gateway startup, NemoClaw also generates a new token when API_SERVER_KEY is missing or is not exactly 64 lowercase hexadecimal characters. If an ordinary restart changes the token while the existing API_SERVER_KEY was present and valid, collect the before and after sandbox identity plus redacted mint logs and report it as a bug. Capture the token and pass it in the Authorization header:

$TOKEN=$(nemohermes my-assistant gateway-token --quiet)
$curl -fsS -H "Authorization: Bearer $TOKEN" \
> http://127.0.0.1:8642/v1/models

Treat the token like a password. Do not log it, share it, or commit it to version control.

The sandbox must be running for nemohermes my-assistant gateway-token --quiet to retrieve the token. Use this supported command instead of reading or editing .hermes/.env directly. For browser access to the dashboard, use nemohermes my-assistant dashboard-url.

nemohermes <name> destroy

Stop managed local inference resources, remove the host-side Docker image built during onboard, and delete the sandbox. This removes the sandbox from the registry. For Ollama-backed sandboxes, destroy also asks Ollama to unload currently loaded models and clears stale auth proxy state on a best-effort basis. For Model Router sandboxes, destroy keeps the process and recovery identity when another sandbox uses the port or when session, process, or absence checks are inconclusive. It also preserves a replacement onboarding session when the captured session identity changed. If the captured session uses the destroyed sandbox name with another router port, destroy clears only the sandbox association and preserves that router’s recovery identity. For lock order, same-port peer handling, and cleanup checks, refer to Set Up Model Router.

If destroy warns that it could not identify or stop a listener for the deleted sandbox:

  1. Inspect the current listener process immediately before you stop anything.
  2. Stop it only if its command line identifies the Model Router on the named port.
  3. Do not stop the router recorded by a preserved session for another port.
  4. Do not stop a previously reported process ID if its command line no longer matches.

This command attempts to wipe the manifest-defined agent state while its persistent volume is mounted, then removes the sandbox. OpenShell can retain the per-name persistent volume after sandbox deletion. If the wipe cannot complete, onboarding with the same name can resurface old files. Do not rely on a retained volume as a backup. Back up your workspace first with nemohermes <name> snapshot create or refer to Create and Restore Snapshots. If you want to upgrade the sandbox while preserving state, use nemohermes <name> rebuild instead.

If another terminal has an active SSH session to the sandbox, destroy prints an active-session warning and requires a second confirmation before it proceeds. Pass --yes, -y, or --force, or set NEMOCLAW_NON_INTERACTIVE=1, to authorize deletion without prompting in scripted workflows. These controls do not suppress the active-session warning. The warning lists the detected process IDs, and destroy still terminates those sessions with a Broken pipe error.

Before changing a Docker-backed sandbox, NemoClaw inspects every container with the requested openshell.ai/sandbox-name label. The command continues when Docker returns no matching containers. For one matching container, the command continues only when all these labels have the required values:

  • openshell.ai/managed-by=openshell
  • A nonempty openshell.ai/sandbox-workspace
  • A nonempty openshell.ai/sandbox-id

In an ordinary destroy flow, if the initial inspection cannot complete, more than one container matches, a matching container has conflicting or incomplete labels, or Docker returns malformed identity data, destroy exits before changing sandbox resources. Retained-sandbox recovery accepts multiple managed containers only when every immutable sandbox ID matches the retained recovery fingerprint. The identity checks still apply with --force, --yes, or NEMOCLAW_NON_INTERACTIVE=1; those controls authorize confirmation but do not authorize an unproven container identity. NemoClaw rechecks the identity after read-only preflight, before provider cleanup, and synchronously at the sandbox-deletion boundary. If a later recheck detects drift or fails, destroy refuses sandbox deletion, restores managed MCP preparation when possible, preserves local ownership state, and reports any earlier cleanup already performed. If OpenShell reports the sandbox absent after preflight captured one matching Docker container, destroy rechecks and removes only that container ID. If Docker reports another OpenShell-managed container, removal fails, or NemoClaw cannot confirm removal, destroy exits nonzero and preserves the registry entry. Correct the reported Docker state, then rerun destroy. If Docker cannot complete the inspection, correct the reported Docker error before you rerun destroy. For common recovery steps, refer to Docker is not running and Docker permission denied on Linux.

If destroy reports conflicting, incomplete, or malformed identity data, inspect the matching containers:

$docker ps -a --no-trunc \
> --filter "label=openshell.ai/sandbox-name=my-assistant" \
> --format 'table {{.ID}}\t{{.Label "openshell.ai/managed-by"}}\t{{.Label "openshell.ai/sandbox-workspace"}}\t{{.Label "openshell.ai/sandbox-id"}}'

The labels show what each container claims. They do not prove container ownership.

Do not remove or recreate a container until you verify its purpose, ownership, and data-retention requirements. Removing or recreating a container can discard state that is not stored in a volume.

Resolve a conflict through the workflow that created the conflicting container. Docker cannot change labels on an existing container. Rerun the query after you resolve the conflict. Rerun destroy only when the query returns one complete expected label set that you verified belongs to the target sandbox, or no containers after you independently confirm that the sandbox is absent.

If the Hermes sandbox has managed MCP entries, shields must be down before destroy can scrub their adapter configuration. Use nemohermes <name> shields down --timeout 15m --reason "MCP maintenance", allowing at least 15 minutes per configured server. If sandbox deletion is refused after destroy has restored lockdown, NemoClaw opens an owner-bound timed rollback window, restores the preserved MCP state, and re-locks shields; the timer retains auto-restore authority if the host process exits.

If a shields auto-restore timer is active, destroy holds the same per-sandbox transition through state wipe and deletion. It restores and verifies lockdown and revokes the active timer before deletion. It clears the remaining local shields state only after deletion succeeds. If the pre-delete re-lock fails, the command warns and attempts to destroy the sandbox. If the destroy operation succeeds, it destroys the sandbox and deletes its unguarded configuration. If the destroy operation fails, NemoClaw keeps the local shields state and the auto-restore timer. Detached auto-restore uses one 7-attempt recovery budget to restore lockdown. Waiting for a verified live sandbox mutation owner does not consume an attempt. The deadline gate remains closed during that wait. If the recovery budget is exhausted, durable containment blocks new sandbox mutations. Run nemohermes <name> shields status and follow its exact-generation recovery guidance. If deletion fails after hardening, the command keeps the surviving sandbox’s locked shields state instead of cleaning it up as though deletion succeeded. By default, unattended final-sandbox destroys (--yes, --force, or NEMOCLAW_NON_INTERACTIVE=1) remove the shared NemoClaw gateway on macOS so the host listener is released, while Linux preserves it for reuse. Pass --cleanup-gateway to force removal, or --no-cleanup-gateway to force preservation. These flags always override both NEMOCLAW_CLEANUP_GATEWAY and the platform default. If the pre-delete workspace wipe completes with a nonzero status, destroy continues, but the retained volume may still contain old files. Use a different sandbox name to avoid reusing that retained volume. If workspace cleanup reaches its 60-second timeout, NemoClaw cannot confirm the remote result. NemoClaw stops before provider cleanup and sandbox deletion, attempts to restore any prepared MCP state, and preserves the local registry entry. Run nemohermes <name> status to check or start the recorded OpenShell gateway. If a shields auto-restore timer remains active, run nemohermes <name> shields status to verify bounded recovery or follow its durable-containment guidance, then retry destroy only after shields recovery permits it. If no timer remains active, retry after the recorded gateway is available. Cleaning up the gateway after the last sandbox also purges the shared cluster volume that retains the per-name persistent volume. If NemoClaw detects active SSH sessions before destroy, it warns that destroy terminates them with a Broken pipe error and lists their process IDs. This warning prints before the confirmation prompt and when --yes or --force skips that prompt. If final gateway cleanup finds a live PID-file process whose command line does not prove it owns the target gateway, destroy exits non-zero after sandbox and registry deletion and skips gateway and volume removal. NemoClaw preserves the per-gateway PID file and runtime marker so you can inspect the process. Stop only the listener that matches the target gateway, then rerun destroy to converge cleanup. When the default-port gateway runs under the packaged OpenShell gateway service, gateway cleanup stops that service before it reaps host processes, so the gateway port is released instead of being rebound by the service manager. The service is stopped, not disabled or removed, and the next onboarding run starts it again. On headless Linux, the packaged service can exist while its systemd user manager is unavailable and the gateway runs through the standalone fallback. For this recognized manager-unavailable failure only, destroy uses the per-gateway PID file when the service is not enabled for automatic activation. If the recorded PID is live, its command line must match the exact gateway name and port before destroy stops it. If the recorded process has exited, destroy continues only after it verifies that the gateway port is free. If a live PID does not prove gateway ownership or the port remains occupied, destroy exits non-zero and preserves the runtime evidence for inspection. For any other service stop failure, destroy exits non-zero after sandbox and registry deletion, prints the status command for the service, and skips gateway and volume removal. If the OpenShell command completes with a gateway transport error and the sandbox has no managed MCP ownership state, --force removes only NemoClaw’s local registry entry and local artifacts. Gateway-side deletion remains unconfirmed, shared host-service and gateway teardown are skipped, and the sandbox and retained volume may still exist if the gateway returns. Start the gateway with nemohermes <name> status and retry destroy when you need a confirmed deletion. If the OpenShell sandbox deletion command reaches its 60-second timeout, NemoClaw cannot confirm whether OpenShell deleted the sandbox. NemoClaw preserves the local registry entry under both --yes and --force. Run nemohermes <name> status to check or start the recorded OpenShell gateway. If the preceding output also reports a failed pre-delete re-lock, run nemohermes <name> shields status to verify recovery or follow its durable-containment guidance, then retry destroy only after shields recovery permits it. Otherwise, retry after the recorded gateway is available. Managed MCP ownership disables the local-only fallback because exact provider cleanup requires the retained ownership state, and other delete failures remain fatal. A failed pre-delete re-lock also disables the local-only fallback, because the auto-restore timer is then the only authority that can lock the configuration again after the gateway returns.

$nemohermes my-assistant destroy [--yes|-y|--force] [--cleanup-gateway|--no-cleanup-gateway]

After OpenShell confirms deletion of a sandbox that owns managed llama.cpp, destroy revalidates the exact container, internal network, lifecycle journal, and gateway-scoped receipt. It removes those resources by inspected ID, then removes the API key and managed ownership state. It preserves the shared ~/.cache/huggingface/ cache. If exact cleanup fails, destroy preserves the sandbox registry entry and ownership state so you can correct the reported conflict and retry.

nemohermes <name> policy get

Export the sandbox’s round-trippable OpenShell base policy as YAML. The command runs openshell policy get --base, validates the returned policy, and strips the OpenShell metadata header. The default output is suitable for review, editing, and later use with openshell policy set. The command exits non-zero when OpenShell fails, returns an empty response, or returns content that is not valid policy YAML.

$nemohermes my-assistant policy get > current-policy.yaml

Use --raw only to inspect the unparsed OpenShell response, including its metadata header:

$nemohermes my-assistant policy get --raw

Do not pass --raw output to openshell policy set because the metadata header is not part of the policy document.

FlagDescription
--rawPrint the unparsed openshell policy get --base response, including its metadata header.

nemohermes <name> policy add

Add a policy preset to a sandbox. Presets extend the baseline network policy with additional endpoints. Before applying, the command shows which endpoints the preset would open and prompts for confirmation. The scope comes from the exact preset YAML and includes each endpoint’s host, port, access, protocol, TLS, and enforcement settings, allowed methods and paths, and binary allowlist. When a lifecycle operation reapplies a preset, NemoClaw compares it with the live policy and reports whether the preset opens new egress, replaces a drifted entry, or is already effective with no new egress.

$nemohermes my-assistant policy add

To apply a specific preset without the interactive picker, pass its name as a positional argument:

$nemohermes my-assistant policy add pypi --yes

The positional form is required in scripted workflows. Set NEMOCLAW_NON_INTERACTIVE=1 instead of --yes for the same non-interactive behavior. If the preset is already present with identical content, the command reports no changes. If its content differs, NemoClaw previews the change and asks for confirmation before applying it again.

Every mutation starts from the round-trippable base document returned by OpenShell, merges the requested built-in or custom content, submits the complete document, and verifies the live result. NemoClaw stores no applied-preset list or custom-policy copy in its registry. Custom preset names are encoded in namespaced keys in the live policy so later policy list and policy remove commands can derive them from OpenShell. If the live policy cannot be read or parsed, the command exits without writing a replacement.

With --from-file or --from-dir, pass a repeatable --trusted-private-host <exact-host-or-ip> option to admit matching RFC1918, carrier-grade network address translation (CGNAT), or IPv6 unique local endpoints. The option is invalid for built-in presets. You can supply exact hosts through NEMOCLAW_TRUSTED_PRIVATE_HOSTS instead, and NemoClaw combines the variable with command options. NemoClaw resolves each matching exact host and adds generated allowed_ips pins to an in-memory copy of the preset. User-authored allowed_ips remains rejected. Dry-run output shows the generated pins. Applying the preset places those pins in the current OpenShell policy, which rebuild carries forward without re-resolving ambient DNS.

FlagDescription
--from-file <path>Apply a custom preset YAML file instead of a built-in preset
--from-dir <path>Apply every custom preset YAML file in a directory in lexicographic order
--trusted-private-host <exact-host-or-ip>Admit one private endpoint host from a custom preset and generate address pins; repeat for additional hosts
--yes, --forceSkip the confirmation prompt (requires a preset name, --from-file, or --from-dir)
--dry-runPreview the endpoints a preset would open without applying changes

Use --dry-run to audit a preset before applying it:

$nemohermes my-assistant policy add --dry-run

Apply a custom preset file when you need to grant access to an endpoint that is not covered by a built-in preset:

$nemohermes my-assistant policy add --from-file ./presets/my-internal-api.yaml

For a trusted private endpoint, preview the generated pins before applying them:

$nemohermes my-assistant policy add \
> --from-file ./presets/my-internal-api.yaml \
> --trusted-private-host api.corp.example \
> --dry-run

For batch workflows, apply all preset files from a directory:

$nemohermes my-assistant policy add --from-dir ./presets/ --yes

Review every host in custom preset files before applying them. Custom presets bypass the built-in preset review process and can widen sandbox egress.

nemohermes <name> policy list

List available policy presets and show which ones match the current OpenShell policy. Built-in rows are scoped to the active agent. Custom preset rows are decoded from namespaced keys in that live document. NemoClaw does not cross-reference a local preset registry or display baseline-exclusion records.

Each active preset is annotated with display-time provenance:

  • [from <tier> tier] means the name appears in the current tier definition.
  • [from <agent> agent] means the name is an agent-specific preset for the active agent.
  • [user-added] covers other live presets.
  • [source unverified (gateway unreachable)] appears only when OpenShell cannot be read; no local policy fallback is shown.

Provenance tags are inferred from the sandbox’s current tier and agent metadata at display time and are not persisted per preset. A preset whose name appears in the sandbox’s current tier YAML is labelled [from <tier> tier] even when an operator added it manually with policy add after onboarding. Agent-specific preset names are only labelled [from <agent> agent] when the active agent matches that label.

$nemohermes my-assistant policy list

nemohermes <name> policy remove

Remove a previously applied policy preset from a sandbox. The command derives applied presets from the current OpenShell policy, prompts you to select one, shows the endpoints that would be removed, and asks for confirmation before narrowing egress.

$nemohermes my-assistant policy remove

To remove a specific preset non-interactively, pass its name as a positional argument:

$nemohermes my-assistant policy remove pypi --yes

Set NEMOCLAW_NON_INTERACTIVE=1 as an alternative to --yes. Without a preset name, policy remove reports the same two picker errors as policy add and exits non-zero. If the preset is unknown or absent from the live OpenShell policy, the command exits non-zero with a clear error. When NemoClaw cannot query OpenShell, it refuses the mutation instead of consulting a local policy record.

FlagDescription
--yes, --forceSkip the confirmation prompt (requires a preset name)
--dry-runPreview which endpoints would be removed without applying changes

Unchecking a preset in the onboard TUI checkbox also removes it from the sandbox.

nemohermes <name> policy exclude <key>

Remove one exact entry from the current OpenShell policy after previewing the egress and support impact that the change removes. The preview names the supported features that may stop working. The command refuses an entry that does not have a reviewed feature-impact disclosure. No exclusion record or replay journal is written: OpenShell’s resulting policy is the complete state, and rebuild carries that live document forward. The command refuses to exclude a key that an applied preset also requires, because removing that live key would remove the preset’s access. The critical managed_inference entry cannot currently be excluded pending product direction. Use --force or --yes for explicit non-interactive acknowledgement, or --dry-run to preview without changing the sandbox. A run with NEMOCLAW_NON_INTERACTIVE=1, or a run without a terminal on stdin, does not prompt and requires one of those acknowledgement flags.

$nemohermes my-assistant policy exclude nous_research --dry-run
$nemohermes my-assistant policy exclude nous_research --force

To restore an entry, run nemohermes <name> policy restore <key> --dry-run to preview the current baseline egress, then run it with --force after review. If the current baseline no longer defines the key, the command reports that there is nothing to restore and leaves the live OpenShell policy unchanged.

nemohermes <name> policy restore <key>

Restore one entry from the current agent baseline into the current OpenShell policy. --dry-run lists the egress that restoration would allow again; after review, --force applies it. Both paths require explicit acknowledgement unless you use --dry-run; use --force or --yes for non-interactive acknowledgement. As with policy exclude, a run with NEMOCLAW_NON_INTERACTIVE=1, or a run without a terminal on stdin, does not prompt. The command writes no exclusion record or journal and verifies the resulting live OpenShell policy before returning.

$nemohermes my-assistant policy restore nous_research --dry-run
$nemohermes my-assistant policy restore nous_research --force

The restore command accepts these flags:

FlagDescription
--yes, -y, --forceSkip the confirmation prompt
--dry-runPreview the egress restoration or stale-record cleanup without applying changes

nemohermes <name> policy explain

Print a redacted summary of the current OpenShell policy context for a sandbox so an agent or operator can reason about what is allowed, what is blocked, and how to request a change. The output covers inferred tier and preset context, allowed host categories, known unapplied presets, policy-change commands, and the support boundaries between NemoClaw, OpenShell, and the agent. Raw policy YAML, rule bodies, and credential metadata are deliberately not included.

$nemohermes my-assistant policy explain

Pass --json to emit the same context as a structured object for agent consumption:

$nemohermes my-assistant policy explain --json

The context also documents how a failed host or integration attempt should be classified. The classifications are blocked-by-policy, missing-approval, unsupported, and unknown, so the agent can pick a remediation step instead of surfacing a lower-level network error.

FlagDescription
--jsonEmit the policy context as a structured JSON object for agent consumption

nemohermes <name> hosts-add

Add a host alias to the sandbox pod template. Use this when a sandbox needs a stable LAN-only name, such as a local SearXNG or internal model endpoint, without dropping to docker exec and kubectl patch. Host alias commands use the legacy Kubernetes gateway Sandbox resource path. In that older topology, the openshell-cluster-nemoclaw container runs an embedded k3s cluster with a sandboxes.agents.x-k8s.io custom resource definition, and an agent-sandbox-controller reconciles each Sandbox resource into the agent pod. They are not supported on Docker-driver or VM-driver sandboxes because those drivers do not run the gateway cluster container that owns this resource.

$nemohermes my-assistant hosts-add searxng.local 192.168.1.105

The command validates the hostname and IP address, rejects duplicate hostnames, and patches spec.podTemplate.spec.hostAliases on the sandbox resource.

FlagDescription
--dry-runPrint the JSON patch for the resulting hostAliases list without applying it

nemohermes <name> hosts-list

List host aliases configured on the sandbox resource.

$nemohermes my-assistant hosts-list

nemohermes <name> hosts-remove

Remove a hostname from the sandbox hostAliases list.

$nemohermes my-assistant hosts-remove searxng.local
FlagDescription
--dry-runPrint the JSON patch for the resulting hostAliases list without applying it

nemohermes <name> channels list

List the messaging channels supported by the sandbox’s agent runtime with a short description. Telegram, Discord, Slack, WeChat, WhatsApp, and Microsoft Teams are available for OpenClaw and Hermes. WeChat, WhatsApp, and Microsoft Teams are experimental. OpenClaw and Hermes also support experimental Google Chat.

The command reads the sandbox registry to select agent-compatible channel manifests. It does not inspect messaging credentials or the live sandbox runtime.

$nemohermes my-assistant channels list

nemohermes <name> channels add <channel>

Register a messaging channel with the sandbox and rebuild so the image picks up the new channel. Channel enrollment uses these credential and pairing flows:

  • Token paste (telegram, discord, slack, teams): the command prompts for required channel inputs. It registers secret credentials with the OpenShell gateway and saves non-secret configuration for rebuilds.
  • Host-side QR (wechat, experimental): the command renders an iLink QR code on the host and you scan it from WeChat on your phone. On confirm, NemoClaw captures the bot token, registers it with the OpenShell gateway, and stores non-secret per-account metadata (WECHAT_ACCOUNT_ID, WECHAT_BASE_URL, WECHAT_USER_ID) for the in-sandbox bridge. NemoClaw automatically adds the scanning operator’s WeChat user ID to WECHAT_ALLOWED_IDS. Supply additional comma-separated IDs to authorize more DM senders. NemoClaw advertises WeChat for both OpenClaw (the @tencent-weixin/openclaw-weixin plugin) and Hermes (the built-in iLink WeChat adapter).
  • In-sandbox QR (whatsapp, experimental): the command records the channel without a host-side token or OpenShell credential provider. NemoClaw advertises WhatsApp for OpenClaw and Hermes sandboxes; after rebuild, run openclaw channels login --channel whatsapp for OpenClaw or hermes whatsapp for Hermes. This intentionally leaves QR-created mutable session state in the sandbox until you unpair it or clear the durable agent state.

Google Chat uses an experimental token-paste flow for the service-account JSON on both agents. OpenClaw also requires interactive public-webhook confirmation and prompts for optional app-principal configuration during enrollment. Hermes instead prompts for the Google Cloud project ID, complete Pub/Sub subscription name, and email sender allowlist. It pulls inbound events from Pub/Sub over REST and does not create a public webhook endpoint.

After registering the channel, NemoClaw asks whether to rebuild immediately. Running add for an already-configured channel overwrites the stored credentials where applicable. The operation is idempotent. Static channel credentials use a validated endpointless OpenShell provider profile so the gateway can replace their sandbox placeholders. NemoClaw validates the existing profile, provider type, and credential keys before it reuses a provider. A missing, malformed, conflicting, or incompatible provider state stops the operation before reuse. Hermes Discord uses its dedicated static provider type because its policy binds the Discord API and Gateway endpoints. Channel names are trimmed and lowercased before NemoClaw stores credentials, names bridge providers, or prints rebuild messages. NemoClaw requires the matching built-in network policy preset YAML to be present. A missing or malformed preset YAML (no network_policies: section) aborts channels add before any token prompt, registry write, or rebuild prompt. After validating that preset, NemoClaw discloses its effect before prompting for credentials or changing gateway or registry state. It prints the exact effective egress scope when the preset would open or replace access, or reports that no new egress would be opened when the preset is already effective. The --dry-run path prints the same disclosure without collecting credentials or applying changes. With the preset file in place, NemoClaw applies it to the sandbox before the rebuild so the bridge has egress to its upstream API. When the apply step itself fails after the registry write on a fresh add, NemoClaw attempts to roll back the bridge providers, the messagingChannels entry, and any staged environment credentials, then exits without prompting for a rebuild; if any gateway-side step (provider detach or delete) fails the rollback continues and prints a Rollback could not fully clean <surfaces> warning so the operator can clean up manually. When the same failure happens on a re-add of an already-enabled channel, NemoClaw restores the prior messagingChannels entry, restores staged environment credentials when available, restores registry credential hashes, and attempts to re-upsert the prior bridge providers, but flags gateway-providers as residual because the in-flight upsert may have left the gateway with the new token; verify the gateway bridge before relying on the channel. Restore the preset YAML and re-run nemohermes <name> channels add <channel>. For Telegram, Discord, and Slack, a rebuild triggered by channels add also verifies that the selected bridge starts and reports credential, startup, or plugin discovery warnings.

$nemohermes my-assistant channels add telegram
FlagDescription
--dry-runValidate the channel name and matching policy preset without prompting for credentials, contacting the gateway, or rebuilding
--forceAdd the channel despite a credential conflict, shared-resource conflict, or incomplete required check. This flag is the only conflict override.

Slack requires both SLACK_BOT_TOKEN (bot user OAuth) and SLACK_APP_TOKEN (app-level Socket Mode token); the command prompts for each in turn. The conflict check compares only sandboxes in the selected OpenShell gateway’s sandbox registry. It cannot detect Slack token reuse across independent OpenShell gateways. Run only one active Slack sandbox on each OpenShell gateway, and use distinct Slack bot and app tokens across gateways. Optional Slack allowlists come from SLACK_ALLOWED_USERS and SLACK_ALLOWED_CHANNELS at rebuild time. Telegram and Discord mention mode default to 1 when no environment, session, or saved state value exists for that setting. Discord applies that default only when a server ID is configured. A run with NEMOCLAW_NON_INTERACTIVE=1, or a run without a terminal on stdin, fails fast on any missing token and shows no rebuild prompt. Instead, the change is queued and you are told to run nemohermes <name> rebuild manually. An SSH command without -t, a service unit, or a CI job has no terminal on stdin, so it does not need NEMOCLAW_NON_INTERACTIVE=1 to reach this path. If you omit the required <channel> argument, the CLI prints the channels add <channel> usage with the supported channel list instead of falling back to top-level help.

nemohermes <name> channels remove <channel>

Clear the stored credentials for a messaging channel and rebuild the sandbox so the image drops the channel. Running remove for a channel that was never configured is a no-op against the credentials file and still triggers the rebuild prompt. When the bridge provider is attached to a live sandbox, NemoClaw detaches it before deleting the provider from the OpenShell gateway. If the matching built-in policy preset is applied, NemoClaw also removes that preset from the current OpenShell policy so the upstream API is no longer allow-listed after the channel is gone. No session preset list exists to synchronize.

For QR-paired channels (today: WhatsApp), NemoClaw destructively clears the in-sandbox session directories before the rebuild so the state_dirs backup does not restore the auth blob and let the channel reconnect:

  • OpenClaw: /sandbox/.openclaw/<channel>/ (for example /sandbox/.openclaw/whatsapp/).
  • Hermes: /sandbox/.hermes/platforms/<channel>/ (for example /sandbox/.hermes/platforms/whatsapp/). For WhatsApp, NemoClaw also clears the current Dashboard profile at /sandbox/.hermes/profiles/dashboard-home/platforms/whatsapp/session/ and the legacy migration source at /sandbox/.hermes/dashboard-home/platforms/whatsapp/session/.

The cleanup tries openshell sandbox exec first and falls back to SSH if the exec wrapper does not return the success sentinel. If both transports fail (the sandbox is stopped, the gateway is down, or SSH cannot reach it) the command refuses to proceed to the rebuild and asks you to start the sandbox and re-run, so a half-removed state cannot leave stale Baileys auth files behind for the next rebuild to restore.

$nemohermes my-assistant channels remove telegram
FlagDescription
--dry-runReport the channel that would be removed without clearing credentials or rebuilding

As with channels add, NEMOCLAW_NON_INTERACTIVE=1 or a run without a terminal on stdin skips the rebuild prompt and queues the change for a manual nemohermes <name> rebuild. channels start and channels stop follow the same rule. If you omit the required <channel> argument, the CLI prints the channels remove <channel> usage with the supported channel list.

Host-side removal is the supported path because managed startup (or an explicit custom image build) materializes agent channel config as image-owned state (/sandbox/.openclaw/openclaw.json for OpenClaw and /sandbox/.hermes/.env for Hermes); agent-specific channel removals inside the sandbox would modify the running config but not persist changes across rebuilds.

nemohermes <name> channels stop <channel>

Pause one configured messaging channel without clearing its credentials. The command verifies that the sandbox’s agent runtime supports the channel before reading configured or disabled channel state. It then requires the channel to be configured for the sandbox. The channel is marked disabled in the per-sandbox registry, and the rebuild omits its runtime configuration, token upsert, and startup effects. Generic channel providers and refresh bridges remain detached while the channel is stopped.

When a stopped Hermes Discord channel keeps a credential-bound policy, the rebuild retains and attaches only the validated static provider that the policy requires. It does not start Discord or recreate the provider credentials. The provider remains registered with the OpenShell gateway, so a later channels start brings the bridge back without re-entering tokens.

$nemohermes my-assistant channels stop telegram
FlagDescription
--dry-runReport the channel that would be disabled without updating the registry or rebuilding

Use channels stop instead of channels remove when you want to pause a bridge temporarily. channels remove is destructive to credentials; channels stop is not.

nemohermes <name> channels start <channel>

Re-enable a channel previously paused with channels stop. The command verifies that the sandbox’s agent runtime supports the channel before reading configured or disabled channel state. It then requires the channel to be configured for the sandbox. NemoClaw removes the channel from the disabled list and records it as enabled in the messaging plan. The rebuild uses that plan to attach the existing bridge provider before applying its matching built-in network policy preset to the replacement sandbox. Before updating the disabled list, NemoClaw prints the exact effective egress scope when the preset would open or replace access, or reports that no new egress would be opened when the preset is already effective. If the command queues the change without rebuilding, the running sandbox keeps its existing bridge and network policy until you run nemohermes <name> rebuild.

$nemohermes my-assistant channels start telegram
FlagDescription
--dry-runReport the channel that would be re-enabled without updating the registry or rebuilding

nemohermes <name> channels status

Run messaging channel status checks. Without --channel, the command prints a compact summary for every configured channel, including registration, policy coverage, and non-secret rendered config comparisons. For channel and agent combinations that support a detailed probe, the summary adds a Runtime health: not checked in summary view pointer instead of running the probe, so it never reads as healthy without an explicit check. With --channel, it prints the detailed status for that channel.

For an OpenClaw WhatsApp sandbox, --channel whatsapp probes the sandbox to separately report pairing/session state, the Noise WebSocket connection, inbound event delivery, and policy coverage. A paired channel with no observed inbound delivery exits non-zero with verdict idle so an unhealthy bridge cannot pass as healthy. The detailed WhatsApp probe stays focused on QR/session runtime diagnostics and does not include rendered-config comparison lines. For a Hermes WhatsApp sandbox, --channel whatsapp first checks the shared gateway path and the profiles/dashboard-home path for creds.json. The status compatibility probe has this contract:

PropertyContract
OwnerThe NemoClaw WhatsApp status hook owns the probe.
ScopeThe hook reads only platforms.whatsapp.extra.session_path from /sandbox/.hermes/config.yaml when the durable session path has no creds.json. The hook does not write the field or configure Hermes.
ValidationThe value must be an absolute path under /sandbox/.hermes with no . or .. segment.
Supported stateThe durable Hermes WhatsApp session remains /sandbox/.hermes/platforms/whatsapp/session. The compatibility field is not a supported NemoClaw setup or session-storage control.
Support periodKeep the probe only while a supported Hermes image can place dashboard-paired credentials outside the durable path.
RetirementIssue #8947 tracks removal after every supported Hermes image uses the durable path for dashboard pairing and gateway startup.

After validation, the command checks the configured path and reports a Session path override signal. An unsupported path produces a warning, and the report uses the default gateway path. If the dashboard path has credentials and the gateway path is empty, the report tells you to run nemohermes <sandbox> channels remove whatsapp and then nemohermes <sandbox> channels add whatsapp, because a rebuild restores the legacy session instead of dropping it. Pair again from the dashboard so credentials use /sandbox/.hermes/platforms/whatsapp/session. Rerun nemohermes <sandbox> channels status --channel whatsapp. NemoClaw does not treat a Hermes session file as live inbound-health evidence.

For Telegram, --channel telegram probes the sandbox to report the gateway process, Bot API reachability, and inbound delivery alongside the config comparison. Detailed non-wait JSON keeps the schema-version-1 {schemaVersion,sandbox,channel,report} envelope. When a probe-capable channel is paused, the command skips the live probe, returns report.verdict as info with paused registration and runtime-health signals, and exits 0. It classifies the state as healthy, idle, token_rejected, unreachable, not_started, policy_gap, config_gap, unknown, or probe_failed. A network or egress failure, or a non-authentication Bot API startup HTTP error, produces unreachable; a 401 or 404 response produces token_rejected. It reads the gateway’s own startup and poll log breadcrumbs rather than issuing its own Bot API request, so the resolved bot token never leaves the gateway. The verdict reflects the most recent evidence in the log window, so a bridge that recovered after a blocked start reports healthy while one blocked again reports unreachable. Telegram health is probed only for OpenClaw sandboxes; a Hermes Telegram sandbox uses the basic config report.

For OpenClaw Slack, --channel slack reports registration, policy coverage, the account runtime, Socket Mode transport, and the account probe. Add --wait to poll these conditions until Slack becomes operational, a terminal error occurs, or the timeout expires. The default timeout is 180 seconds, and --timeout <seconds> requires --wait. NemoClaw treats the timeout as the total budget for polling and live probes, limits each live probe to the remaining budget, and starts no probe at or after the deadline. Use --json with --wait for a structured readiness result with readiness.state, readiness.category, readiness.reason, readiness.retryable, readiness.attempts, readiness.elapsedMs, readiness.lastTransitionAt, and readiness.lastObserved. Slack --wait applies only to OpenClaw sandboxes and uses its manifest-defined check; other channel manifests return readiness_not_supported until they define one. For an OpenClaw sandbox, if Slack is paused with channels stop, the command skips the live probe and returns one terminal result with readiness.reason set to channel_paused. On timeout, the command exits nonzero with readiness.state, readiness.category, and readiness.reason set to timeout; its readiness.retryable mirrors the last observed state, whose category and reason preserve the underlying cause.

For registered channel details and the compact summary, the status output compares non-secret config inputs from the sandbox registry against the values rendered into the agent config, such as Telegram group policy in openclaw.json or mention mode in Hermes config. Secret inputs, including tokens, are not printed. If the registry contains a non-secret expected value but NemoClaw cannot read or check the rendered source, the comparison is a warning and the detail includes (not checked). Optional unset inputs remain informational.

$nemohermes my-assistant channels status
$nemohermes my-assistant channels status --channel whatsapp
$nemohermes my-assistant channels status --channel telegram
$nemohermes my-assistant channels status --channel slack --wait --timeout 180 --json
FlagDescription
--channel <channel>Channel to inspect in detail
--waitWait for the selected channel’s manifest-defined readiness check (requires --channel)
--timeout <seconds>Stop waiting after this number of seconds (default: 180; requires --wait)
--jsonEmit the status or readiness report as JSON; non-ready terminal and timeout results exit nonzero

Each live probe is bounded by an in-sandbox openshell sandbox exec with a hard timeout. The WhatsApp probe returns strict OpenClaw status JSON to the host, where NemoClaw allowlists pairing, liveness, connection-state, and timestamp fields before rendering the report and discards phone-number and free-text error fields. The Hermes WhatsApp probe returns fixed session-presence booleans to the host. When the shared gateway path is empty, a sandbox-local parser can also return the configured WhatsApp session path. The parser does not return other Hermes configuration values. NemoClaw validates the path before it uses the path in a second session-presence probe. The Telegram probe returns only matched gateway log lines to the host, where NemoClaw reduces them to fixed classifications without rendering the raw lines, message bodies, or tokens. The Slack probe returns OpenClaw status JSON to the host. NemoClaw reduces it to allowlisted account booleans, credential availability, probe success, fixed error categories, and timestamps; the rendered and JSON readiness reports omit tokens and free-text errors.

nemohermes <name> mcp list

List MCP servers configured for a sandbox. The command reports the selected agent’s MCP support status and, for each configured server, whether the generated OpenShell provider, policy, and agent adapter are present.

$nemohermes my-assistant mcp list [--json]
FlagDescription
--jsonEmit sandbox, support, and MCP server state as JSON without credential values

nemohermes <name> mcp add

Add an MCP Streamable HTTP server to a sandbox. Pass --url for the MCP endpoint and the required single --env KEY bearer credential for the sandbox-side MCP client. Pass a repeatable --trusted-private-host <exact-host-or-ip> option to admit an exact RFC1918, CGNAT, or IPv6 unique local destination for the current command. The declaration must equal the normalized host from --url. For managed MCP, use a DNS hostname for an IPv6 unique local address because NemoClaw has not qualified direct IPv6-literal MCP URLs. You can supply exact hosts through NEMOCLAW_TRUSTED_PRIVATE_HOSTS instead, and NemoClaw combines the variable with command options. NemoClaw records the resulting exact trust intent and address pins, so restart, rebuild, and restore do not depend on the ambient environment. NemoClaw registers that credential in an OpenShell provider, installs a generated OpenShell protocol: mcp policy for the target endpoint, attaches the provider to the running sandbox, and writes only an OpenShell resolver placeholder for the recorded key into the agent configuration. Inline --env KEY=VALUE is rejected because it would expose the value in NemoClaw process arguments. Load the variable from a secret manager or masked prompt, export it without recording the value in shell history, and pass only --env KEY. All endpoints must use HTTPS. The full URL and path are persisted and displayed, so URLs cannot contain userinfo, query strings, fragments, known secret-shaped path material, percent-escaped or glob-style paths, or port zero. Server names must start with a letter and contain at most 64 letters, digits, hyphens, or underscores, and endpoint hostnames must use canonical lowercase DNS labels. NemoClaw rejects invalid names and endpoints before it writes lifecycle state or changes OpenShell resources. NemoClaw generates a narrow protocol: mcp policy for the destination, literal path, adapter binaries, pinned addresses, explicit MCP methods, and a 131,072-byte request-body limit. OpenShell 0.0.106 evaluates that policy before replacing the attached provider placeholder in the allowed request header. NemoClaw imports the endpointless nemoclaw-mcp-v1 profile and binds the dedicated provider to that endpoint with credential_binding.provider. OpenShell withholds the credential before the binding is active and outside the bound host, port, and path. The sandbox client connects directly through OpenShell’s existing egress path, and NemoClaw does not run a host-side MCP data-plane bridge, proxy, relay, or listener. After the add commits, NemoClaw freshly verifies the exact generated policy, expected provider attachment, recorded provider ID, nemoclaw-mcp-v1 type, valid resource version, and exactly one credential key matching the recorded key. If those readiness checks pass, it sends a differential pair of wire-level MCP initialize requests from inside the sandbox — one with the placeholder header and one with an unresolvable control bearer — to verify that OpenShell resolves the credential on egress; otherwise it reports an inconclusive probe skipped result and sends no request. Neither outcome fails the committed add, and --no-probe skips this check. For full setup details, see Add an MCP Server.

Hermes MCP add, restart, and remove mutate managed config and are refused while shields are up. Hermes includes the credential revision from the readiness check in the resolver placeholder and preserves it through inspection, rollback, and lifecycle reconciliation while OpenShell still reports it. Run nemohermes <name> shields down --timeout 15m --reason "MCP maintenance" before the mutation, then run nemohermes <name> shields up after it; list and status remain read-only. Allow at least 15 minutes per configured server for an all-server restart or destroy; rebuild opens its own crash-recoverable maintenance window. Keep shields down until the command returns; a concurrent relock refuses the config commit and can leave an earlier policy/provider stage for the next retry to converge.

$export GITHUB_MCP_TOKEN=ghp_...
$nemohermes my-assistant mcp add github --url https://api.githubcopilot.com/mcp/ --env GITHUB_MCP_TOKEN
$unset GITHUB_MCP_TOKEN

For a private endpoint, use its URL host:

$export LOCAL_MCP_TOKEN='replace-with-secret-manager-value'
$nemohermes my-assistant mcp add local-tools \
> --url https://mcp-host.corp.example/mcp \
> --env LOCAL_MCP_TOKEN \
> --trusted-private-host mcp-host.corp.example
$unset LOCAL_MCP_TOKEN

nemohermes <name> mcp status

Inspect MCP server state for one server or for all configured servers. Status includes OpenShell provider presence and credential-key shape, provider attachment, generated policy content match, adapter registration, current host-variable availability, and the selected agent’s MCP support mode. For a trusted private endpoint, status also compares current DNS answers with recorded pins without changing the policy. Text output reports private address pins: match, drift, or unresolved. JSON output reports the same value in trustedPrivateTarget.state and includes the recorded pins. When a single server is named, status requests a differential wire-level credential-resolution probe. It sends no probe traffic unless the exact generated policy matches the effective gateway policy, the expected provider attachment is confirmed, and the live provider has the recorded ID, nemoclaw-mcp-v1 type, a valid resource version, and exactly one credential key matching the recorded key; a readiness failure reports unknown with a probe skipped detail. When ready, the same MCP initialize is sent from inside the sandbox once with the recorded resolver placeholder header and once with a deliberately-unresolvable control bearer. Classification uses the two HTTP status codes plus curl exit codes for transport, timeout, and policy-denial outcomes; response bodies are never captured or printed. A verified verdict requires the placeholder request to be accepted (HTTP 2xx) while the control is rejected — the only outcome that proves a valid credential was on the wire. Identical HTTP 400, 401, or 403 rejections raise a warning that names the hypotheses — the placeholder forwarded verbatim, an expired or revoked credential that resolved correctly, or (for HTTP 400) endpoint request validation — and tells you to verify the stored credential first. For HTTP 401 or 403, a confirmed-valid credential means the host is not rewriting placeholders and agent runtimes receive the same auth failure and skip the server; HTTP 400 remains inconclusive because the endpoint may reject the probe request itself. Every other outcome — differing rejections (an endpoint may reject two different literal bearers differently), endpoints that skip authentication, endpoint outages, policy denials, and unreachable sandboxes — reports as unknown rather than blaming the credential rewrite, and a persisted URL that fails the current authenticated-endpoint boundary is never probed.

Pass --tools with one server name to request a live tool inventory. The shared client runs through the managed registration’s existing OpenShell credential provider and policy; OpenShell injects the credential at that boundary, and the runtime never accepts it as an argument, environment value, or authorization option. It performs initialize, notifications/initialized, and paginated tools/list, then attempts to close the MCP session and transport. Cleanup errors do not replace the bounded discovery result. It retains and returns deterministic tool names only, never prints the other tool-definition fields returned by tools/list, and never calls a tool. The operation is bounded by total and per-request timeouts plus response-byte, page, tool-count, cursor-length, and tool-name limits.

Use --tools only with a configured endpoint you trust to advertise names while authenticated. The endpoint controls its returned names and can derive them from the request or credential it receives; NemoClaw validates and bounds the text but cannot prove that the endpoint did not encode credential-derived data in an otherwise valid name.

The toolDiscovery JSON field contains ok, count, tools, and truncated, plus a redacted detail on failure or a bounded partial result. These names are the server’s point-in-time advertised tools, not an attestation of the exact tools visible to the model after agent filters, progressive disclosure, or session state. An older sandbox image without the shared client reports that the sandbox must be rebuilt.

Tool discovery is opt-in and sends authenticated network traffic to the configured endpoint. Passing --tools suppresses the named-server credential-resolution probe that otherwise runs by default. Pass --probe --tools to request both checks explicitly. An unsuccessful discovery does not remove the ordinary provider, policy, environment, or adapter status from the result.

$nemohermes my-assistant mcp status [server] [--json] [--probe|--no-probe] [--tools]
FlagDescription
--jsonEmit status as JSON without credential values
--probeRequest the wire-level credential-resolution probe for every listed server; entries that fail readiness checks are skipped
--no-probeSkip the probe; it defaults on only when a single server is named
--toolsRequest advertised tool names from one trusted configured endpoint through its managed credential provider; suppresses the implicit credential probe unless --probe is also passed

nemohermes <name> mcp restart

Refresh one MCP server registration, or every server on the sandbox when no server is supplied. Restart reapplies the generated policy, reattaches the OpenShell provider when needed, and refreshes the sandbox agent adapter registration. For a trusted-private entry, restart replays recorded address pins without resolving the endpoint again or widening the policy. For a public entry, restart resolves the hostname again and refreshes the policy with the current validated public addresses. If the recorded host variable is exported, restart replaces the provider credential and waits for its new opaque revision. Otherwise, restart reuses an existing provider whose current metadata match the registry. A missing provider requires the variable to be exported before retrying. An existing provider with the profile-less legacy generic type must be removed and added again with its credential exported. OpenShell 0.0.106 cannot bind that provider to an MCP endpoint, so restart and rebuild fail closed instead of activating it. When that provider is already absent but its name still blocks sandbox exec, restart first detaches only the dangling sandbox-spec reference, then runs the agent capability probe before changing a live provider or policy.

Hermes shields must be down for this config mutation. Keep them down until the command returns; a concurrent relock refuses the config commit and can leave an earlier policy/provider stage for the next retry to converge.

$nemohermes my-assistant mcp restart [server]

nemohermes <name> mcp remove

Remove an MCP server from a sandbox.

Hermes shields must be down for this config mutation. Keep them down until the command returns; a concurrent relock refuses the config commit and can leave an earlier policy/provider stage for the next retry to converge.

For an ordinary managed entry, NemoClaw unregisters the sandbox agent adapter, removes the exact owned generated policy, detaches and deletes the recorded OpenShell provider, and clears the sandbox registry entry. For a stored legacy entry whose credential name is no longer accepted, it first detaches the exact provider so adapter cleanup cannot start with that credential attached. Deep Agents teardown does not require managed MCP capability v2 from the old image. For a v1 image, NemoClaw removes the exact registry-owned entry from the legacy .mcp.json while preserving unrelated user state; a replacement image must pass the v2 capability check before post-rebuild providers or policy are restored. The command fails closed on observed drift. --force may remove a modified same-name agent adapter entry, but provider deletion still requires the recorded ID and credential key plus an accepted managed provider type, and policy deletion still requires exact owned content. An exact legacy generic provider is accepted only for cleanup. Residuals preserve registry state. OpenShell 0.0.106 mutates providers by name, so do not concurrently replace a managed provider through another OpenShell client during this command.

When an interrupted destroy leaves a prepared-only transaction, deletion is not durably confirmed. If the sandbox is still live, run nemohermes <name> mcp remove <server> --force with the affected server name. NemoClaw clears the prepared marker only after cleanup succeeds without residuals and no bridge entries remain. A failed cleanup, a wrong server name, residual resources, or any remaining bridge entry preserves the marker for another retry.

A pending marker, including a transaction with both prepared and pending markers, means the registry records that OpenShell deletion was already confirmed. mcp remove --force refuses this state. Run nemohermes <name> destroy to finish the idempotent provider and policy cleanup.

$nemohermes my-assistant mcp remove github [--force]
FlagDescription
--forceRemove same-name adapter config and continue exact-ownership provider and policy cleanup. For a prepared-only destroy, attempt recovery when the sandbox is still live and clear the marker only after residual-free cleanup drains every bridge entry.

nemohermes <name> skill install <path>

Deploy a skill directory to a running sandbox. The command validates the SKILL.md frontmatter, which requires a name field. It uploads selected non-dot regular files while preserving their subdirectory structure. It then performs agent-specific post-install steps.

$nemohermes my-assistant skill install ./my-skill/

The skill directory must contain a SKILL.md file with YAML frontmatter that includes a name field. Skill names must contain only alphanumeric characters, dots, hyphens, and underscores.

Hermes plugins are different from NemoClaw skills. skill install uploads agent skills, while Hermes plugin configuration is managed by the Hermes runtime and the NemoClaw Hermes plugin baked into the sandbox image. The NemoClaw Hermes plugin reloads installed skills when a new chat session starts. Start a new Hermes chat session after an install or update; a gateway restart is not required.

Run nemohermes <name> skill install --help to print usage for this subcommand. If you pass a plugin-shaped directory to skill install, the CLI prints a plugin-specific hint instead of treating it as a missing skill file.

Files with names starting with . (dotfiles) are skipped and listed in the output. Files with unsafe path characters are rejected to prevent shell injection. Symlinks and other non-regular paths are rejected rather than followed or copied.

For OpenClaw and Hermes, an existing sandbox skill is updated in place and chat history is preserved. Deep Agents supports only fresh-name installs because its active skill directory is shared with agent-authored content. Follow the agent-specific activation guidance above after installation.

nemohermes <name> skill remove <skill>

Remove an installed skill from a running sandbox by skill name when the selected agent supports automatic removal. The command validates the skill name before it applies the agent-specific removal behavior below.

Start a new Hermes chat session for the removal to take effect. A gateway restart is not required.

$nemohermes my-assistant skill remove my-skill

Use the skill name from the SKILL.md frontmatter, not the local directory name. Skill names must contain only alphanumeric characters, dots, hyphens, and underscores, and cannot be . or ...

nemohermes <name> sessions

List Hermes conversation sessions in the sandbox. NemoClaw invokes hermes sessions list via openshell sandbox exec, forwards native Hermes flags such as --source and --limit, and streams the output unchanged.

$nemohermes my-assistant sessions
$nemohermes my-assistant sessions --source cli --limit 20

nemohermes <name> sessions list

Invoke hermes sessions list inside the sandbox. NemoClaw forwards native Hermes flags such as --source and --limit and streams the output unchanged.

$nemohermes my-assistant sessions list
$nemohermes my-assistant sessions list --source cli --limit 20

nemohermes <name> sessions delete <id>

Invoke hermes sessions delete <id> --yes inside the sandbox to remove a session from the Hermes store. Pass a native Hermes session id from sessions list (for example 20260727_130357_cb2b61). The OpenClaw-only --agent, --keep-transcript, --json, and --verbose flags are not supported on a Hermes sandbox.

$nemohermes my-assistant sessions delete 20260727_130357_cb2b61

nemohermes <name> sessions export

Export a Hermes sandbox’s session history from the running sandbox to the host. The command invokes the in-sandbox hermes sessions export against a staging path under /sandbox/.nemoclaw-staging, then downloads the resulting single JSONL stream to the host. Hermes stores session history in a SQLite database, so the command refuses positional keys, --format tar, and --include-trajectory with a clear error when the sandbox is Hermes. --agent accepts only hermes as a no-op alias on a Hermes sandbox and rejects any other value. The host destination defaults to ./sessions-<sandbox>.jsonl; --out picks a different path.

$nemohermes my-assistant sessions export
$nemohermes my-assistant sessions export --agent hermes --out ./sessions-my-assistant.jsonl
$nemohermes my-assistant sessions export --json
FlagDescription
--agent hermesOptional no-op alias accepted only on a Hermes sandbox. Any other value is rejected.
--out <path>Host destination. Defaults to ./sessions-<sandbox>.jsonl.
--jsonPrint the export manifest as JSON instead of a status line.

Session JSONL can contain pasted secrets, such as API keys or tokens, so exported files are written owner-only (0600). The in-sandbox staging artefact is additionally created with umask 077 and removed after the host download completes. If the staging cleanup fails, the command warns with the retained path and a manual removal command. The retained artifact can contain session JSONL with pasted secrets. Run the exact removal command from the warning, then inspect that same retained path to confirm it no longer exists.

The export keeps its original success or failure result, so a cleanup warning after a successful download does not make the export fail.

nemohermes <name> download <sandbox-path> [host-dest]

Host-side wrapper around openshell sandbox download that checks the live sandbox. The command confirms before and after transfer that the source remains a file or directory. Symbolic links, source-type changes, and other special source types are refused. If the command cannot confirm the source type, it exits without publishing. The command downloads to a fresh private temporary directory on the host, verifies that OpenShell wrote an artifact, publishes the artifact to your destination, and removes the temporary directory. An existing destination directory is resolved to its canonical path before publication. The command refuses an existing file destination that is a symbolic link and a new destination below a symbolic-link parent. Regular files are published through a private temporary entry and atomically replace an existing regular file. Relative host destinations resolve against the caller’s working directory. Absolute host destinations do not use caller-working-directory resolution. With no host-dest the destination defaults to the current directory.

$nemohermes my-assistant download /sandbox/.hermes/state.db ./
$nemohermes my-assistant download /sandbox/.hermes/logs/ ./logs/

nemohermes <name> upload <host-path> [sandbox-dest]

Host-side wrapper around openshell sandbox upload, symmetric to the download wrapper. With no sandbox-dest the destination defaults to /sandbox/ inside the sandbox.

$nemohermes my-assistant upload ./local-file /sandbox/
$nemohermes my-assistant upload ./backups/state.db /sandbox/.hermes/state.db

nemohermes <name> rebuild

Upgrade a sandbox to the current agent version while preserving workspace state. The command backs up workspace state, captures the current OpenShell policy into a private temporary handoff, destroys the old sandbox, recreates it with the current image, and restores workspace state. Credentials are stripped from backups before storage. The replacement receives the captured OpenShell document directly; NemoClaw does not reconstruct policy from preset records. The replacement uses the recorded compatible-endpoint reasoning mode, reasoning effort, and web search selection instead of ambient shell values. When same-gateway legacy sandbox records use the selected supported provider but omit its credential environment-variable name, rebuild fills only those missing names from the provider’s canonical configuration. The target update and peer metadata migration use one registry update. Conflicting credential environment-variable names, custom endpoints, or API families still stop the rebuild. Incomplete routes and invalid gateway bindings also stop the rebuild. NemoClaw checks the shared route again immediately before deleting the original sandbox. Rebuild preserves the recorded sandbox GPU enablement mode and, for an explicitly enabled sandbox, its recorded device selector. It re-resolves the Docker-driver GPU route from the current host and current NEMOCLAW_DOCKER_GPU_PATCH value, so native-only, explicitly authorized native-with-fallback, and compatibility-only routing may differ from the original onboarding run. A rebuild preserves the recorded tool-disclosure mode unless --tool-disclosure explicitly changes it; it ignores an ambient NEMOCLAW_TOOL_DISCLOSURE value while recreating the sandbox. A rebuild preserves the recorded Deep Agents Code observability choice and matching local OTLP policy state unless --observability or --no-observability explicitly changes them. A rebuild preserves the recorded Deep Agents Code auto-approval capability unless --dcode-auto-approval explicitly changes it. A sandbox onboarded with an explicit GPU opt-out (stored as sandboxGpuMode: "0", plus legacy registry entries that only record gpuEnabled: false) is recreated with the same opt-out, so the inner onboard --resume skips the Docker CDI GPU preflight on hosts without an NVIDIA GPU. Auto-mode sandboxes remain auto.

$nemohermes my-assistant rebuild [--yes|-y|--force] [--verbose|-v] [--tool-disclosure <progressive|direct>] [--dcode-auto-approval <disabled|thread-opt-in>] [--observability|--no-observability]
FlagDescription
--yes, -ySkip the confirmation prompt.
--forceSkip the confirmation prompt and continue when no state directory was preserved or a manifest-declared state file failed. NemoClaw restores any captured entries; after a total failure, it recreates from registry metadata only. If a pre-mutation no-op cannot execute in a sandbox with managed MCP servers, it may preserve the registered MCP intent through host-side recovery.
--verbose, -vLog SSH commands, exit codes, and session state (also enabled by NEMOCLAW_REBUILD_VERBOSE=1)
--tool-disclosure <progressive|direct>Change the model-visible tool catalog during this transactional rebuild. Use this path for sandboxes with managed MCP servers so their providers and adapter state are preserved.
--dcode-auto-approval <disabled|thread-opt-in>Change the managed Deep Agents Code thread auto-approval capability. thread-opt-in is accepted only for managed Deep Agents Code sandboxes and is rejected for other agents or custom images. Enabling prints a warning, and either value requires sandbox recreation.
--observability, --no-observabilityEnable or disable managed trace export for a LangChain Deep Agents Code sandbox during the transactional rebuild. This path preserves managed MCP providers and adapter state.

If another terminal has an active SSH session to the sandbox, rebuild prints an active-session warning and requires confirmation before destroying the sandbox. Pass --yes, -y, or --force to skip the prompt in scripted workflows.

The sandbox normally must be reachable for the backup step to succeed. If an archive command preserves at least one state directory, rebuild keeps the captured backup entries and reports the manifest-defined paths that could not be archived. If a manifest-declared state file fails, rebuild exits before destroying the original sandbox even when it preserved state directories, unless you explicitly pass --force. If every state directory fails, rebuild exits before destroying the original sandbox even when it captured loose files, unless you explicitly pass --force. With --force, NemoClaw preserves any captured loose files in the partial manifest and restores them after recreation. If the backup produced nothing usable, it continues from recorded registry metadata without restoring prior sandbox state. Use this recovery path only when losing the state that could not be backed up is acceptable. For a sandbox with managed MCP servers, --force probes sandbox execution before MCP teardown. If that no-op cannot run, NemoClaw requires complete bridge entries plus exact provider and target identities, without trying an in-sandbox adapter scrub or changing MCP lifecycle state. Each bridge must record the adapter for the sandbox.s recorded agent. It rechecks the registry, recorded gateway, resolved targets, and provider identities immediately before deletion; incomplete adds, drift, or ambiguous bridge state stop before deletion. Policy is not part of that ownership proof; rebuild independently captures the complete current OpenShell policy and hands it to replacement creation. NemoClaw sends the delete request and every deletion-confirmation lookup to the sandbox’s exact recorded gateway. Across every rebuild path, NemoClaw does not attempt to stop local NIM until sandbox deletion is positively confirmed, then attempts NIM cleanup on a best-effort basis. When openshell sandbox delete exits nonzero, an exact recorded-gateway lookup distinguishes explicit absence from a confirmed Ready or Running sandbox. Any other phase or probe failure is ambiguous. Explicit absence continues the rebuild. Confirmed intact state triggers an attempt to restore prepared MCP state and any shields lockdown that rebuild temporarily opened. NemoClaw reports any MCP or shields restoration failure and does not present the operation as a successful rollback. Ambiguous state preserves MCP ownership and recovery metadata without attempting to stop NIM or claiming the original sandbox remains intact, and the rebuild process skips its immediate shields relock. Failures after a successful exec probe do not switch to the host-side path. Before backup or deletion, rebuild also refuses an incomplete MCP destroy transaction. For a prepared-only transaction, the redacted diagnostic points to nemohermes <name> mcp remove <server> --force when the sandbox is still live. For a pending or both-marker transaction, it points to nemohermes <name> destroy because the registry records that OpenShell deletion was already confirmed. Before backup or deletion, rebuild checks the staged messaging configuration against other sandboxes in the selected OpenShell gateway’s sandbox registry. A rebuild cannot detect messaging conflicts in an independent OpenShell gateway’s registry. A conflict aborts with the original sandbox registered and intact so you can resolve the conflict before retrying. After OpenShell accepts the sandbox deletion, rebuild waits until OpenShell explicitly reports that the old sandbox is absent. Only then can NemoClaw perform any required local registry removal and begin creating the replacement. If OpenShell does not confirm absence within the bounded wait, including when gateway transport errors block the probes, rebuild exits nonzero before registry removal or replacement creation and preserves both the local registry entry and the state backup. Restore OpenShell connectivity and confirm the sandbox’s live state before you retry, and keep the printed backup path for recovery. Before deletion, rebuild records a replacement journal that binds the operation to the recorded gateway, source identity, and target settings. Rerunning the same rebuild continues from the recorded boundary or accepts the proven replacement instead of deleting it again. A mount-free journal written before host-mount identity binding remains resumable. An older journal that used host mounts fails closed because it cannot prove the original host source identity, even when the visible mount settings are unchanged. Preserve the sandbox, onboarding session, printed backup, exact error, and Journaled replacement diagnostic, then follow the legacy journal guidance in Continue an Interrupted Replacement. Use --verbose to print the replacement identifier, gateway, and journal phase. Refer to Continue an Interrupted Replacement for the recovery procedure and fail-closed conditions. When rebuild starts with shields up, NemoClaw opens a 30-minute shields-down window for backup and recreation. A detached auto-lock timer remains active until NemoClaw commits a successful shields-up state, so it can attempt to restore lockdown if the host rebuild process exits unexpectedly.

After restore, the command restores Hermes manifest-defined state and starts the rebuilt Hermes gateway with the regenerated /sandbox/.hermes config. A rebuild creates a new sandbox home and a new Hermes API bearer token. After the rebuild succeeds, retrieve the replacement token with nemohermes my-assistant gateway-token --quiet before reconnecting API clients. For an older Hermes image that predates sealed shields transitions, rebuild is the only workflow authorized to use the descriptor-safe compatibility transition. The compatibility path verifies the strict root-owned hash and the in-tree hash, publishes fresh config inodes to revoke retained write descriptors, and restores the trusted lock posture if the transition cannot finish. Ordinary shields up and shields down commands refuse the older protocol and direct you to rebuild.

nemohermes update

Check for a NemoClaw CLI update and, when requested, run the maintained installer flow. This command is a discoverable CLI wrapper around the supported installer path. The update request and every redirect require HTTPS:

$curl -fsSL --proto '=https' --proto-redir '=https' https://www.nvidia.com/nemoclaw.sh | bash
$nemohermes update [--check] [--fresh] [--allow-downgrade] [--yes|-y]
FlagDescription
--checkShow the current version, latest maintained version, install type, and maintained update command without changing anything.
--freshReinstall the maintained build for a clean re-clone of ~/.nemoclaw/source; useful to repair a broken install. Does not reset onboarding state. By default, runs only when the maintained build is the same version or newer than the installed version.
--allow-downgradeAllow --fresh to reinstall when the maintained build is older than the installed version or the versions cannot be ordered. This can downgrade the host installation.
--yes, -ySkip the confirmation prompt and run the maintained installer flow.

nemohermes update updates the host-side NemoClaw installation. The maintained installer flow follows the admin-promoted lkg release tag by default, so it may trail the newest semver or latest tag while validation completes. Because of that, an install can be newer than the maintained tag. Without --allow-downgrade, --fresh runs only when the maintained build is the same version or newer than the installed version. When the maintained tag resolves, the command passes that repository revision to the installer, so a later tag change cannot select a different build for that update. It reports the reason and exits non-zero in these cases:

  • The installed version is newer than the maintained tag.
  • The versions cannot be ordered.
  • The maintained tag does not resolve to a version.

NemoClaw cannot order a git describe version against a different prerelease on the same release line. Rerun with --allow-downgrade to reinstall regardless; --yes waives the confirmation prompt only and never accepts a downgrade on its own. It does not replace nemohermes upgrade-sandboxes; use that command to inspect or rebuild existing sandboxes after the CLI has been updated. When the command is running from a source checkout, it reports that state and does not replace the checkout with a global package install.

nemohermes upgrade-sandboxes

Rebuild sandboxes whose base image is older than the one currently pinned by NemoClaw. NemoClaw resolves the digest of ghcr.io/nvidia/nemoclaw/sandbox-base:latest from the registry, then compares it against the digest each sandbox was created with. Sandboxes that match the current digest are left alone. NemoClaw also checks the build fingerprint recorded on each managed sandbox image. A sandbox needs upgrade when its agent version is stale, when its recorded NemoClaw image fingerprint differs from the running CLI, or both. When the target version is older than the recorded one (for example after reinstalling with an older NEMOCLAW_INSTALL_TAG), the stale listing marks the change with a (downgrade) suffix instead of framing it as a routine upgrade. Custom Dockerfile sandboxes are not classified by image drift because rebuilding them onto the default image would drop the custom image. Legacy sandboxes without a recorded fingerprint opt into this check after their next rebuild. A recorded sandbox that is not observed in any phase on its own recorded gateway is reported as not found there, with remediation guidance — this typically means its gateway registration or Docker image was removed (for example by nemohermes uninstall, which preserves sandboxes.json but removes both).

$nemohermes upgrade-sandboxes [--check] [--auto] [--yes|-y]
FlagDescription
--checkInspect sandbox state without rebuilding. Exits nonzero when it reports stale state, an unknown version, a backup recovery condition, or a sandbox missing from its recorded gateway. Inspect each diagnostic before you select a remediation.
--autoRebuild every stale sandbox without prompting. Used by the installer to upgrade in place.
--yes, -ySkip the confirmation prompt for the rebuild plan.

Before it inspects a gateway or starts a rebuild, the command validates every registered sandbox name against the NemoClaw sandbox name format. Route-only reservations are not sandboxes and are excluded from this validation. If the command finds incompatible names, it lists each name before any gateway inspection or rebuild. With --check, the command then returns without changing state. In a mutating mode, it exits with a nonzero status. NemoClaw does not truncate or rename a registered sandbox identity. Follow Update Sandboxes to transfer state to a compatible replacement before you rerun the command.

Each rebuild reuses the same workspace backup-and-restore flow as nemohermes <name> rebuild, so workspace files survive the upgrade. If the registry or required managed-image catalog evidence is unavailable, NemoClaw fails closed instead of selecting an unpinned image. Restore registry access, then rerun the command so NemoClaw can validate the exact image digest. During installer recovery, a registered sandbox that is not Ready can also be rebuilt from its validated latest backup. That recovery requires a NemoClaw-managed image fingerprint or the installer’s explicit confirmation for a listed pre-fingerprint OpenClaw or Hermes entry. The legacy confirmation never overrides recorded custom-image evidence. A custom OpenClaw sandbox is recoverable only when the selected backup independently carries complete authoritative image-plugin provenance.

nemohermes backup-all

Back up registered sandboxes that are running or have an eligible stopped Docker-driver container to ~/.nemoclaw/rebuild-backups/. A registered docker-driver sandbox whose container is stopped is started for the duration of the backup and returned to its stopped state afterward. If the container cannot be returned to the stopped state, the command fails and reports that the container was left running. Sandboxes that are not running and cannot be started this way are skipped with remediation guidance.

For each eligible sandbox, backup-all holds one lifecycle transaction through the complete backup. Within that transaction, it starts a stopped container when required, opens a 30-minute shields-down window when the sandbox starts with Shields up, copies sandbox state, restores the previous Shields state, and returns any container it started to the stopped state. If the timer expires during the transaction, the deadline gate blocks new mutations and waits for the exact backup owner to finish without signaling it. An initial lock or unlock failure marks that sandbox as failed, and backup-all continues with the next sandbox. A failure to restore the previous Shields state stops backup-all before it processes another sandbox.

$nemohermes backup-all

Before an OpenShell upgrade, the installer prepares the current release CLI and uses it to run backup-all in strict mode. Strict mode requires every registered sandbox to produce a fresh backup and aborts before gateway changes if any sandbox is skipped or fails. When strict mode reports a skipped sandbox, start that sandbox or its container and rerun the installer or nemohermes backup-all.

A running sandbox whose in-sandbox SSH endpoint does not answer fails its backup and aborts the run. For a standalone nemohermes backup-all run, set NEMOCLAW_SKIP_UNREACHABLE_SANDBOX_BACKUP=1 exactly to skip such sandboxes instead of failing. Other values such as true, yes, or 0 are not accepted. This variable does not weaken the installer’s strict pre-upgrade requirement. A skipped sandbox’s uncommitted state is not included in its last successful backup.

nemohermes <name> snapshot create

Create a timestamped snapshot of sandbox state. Snapshots are stored in ~/.nemoclaw/rebuild-backups/<name>/. The command requires shields to be down and keeps the shields check and backup under one per-sandbox transition. If the timer expires during a long-running backup, the deadline gate blocks new mutations and waits for the exact backup owner to finish. Auto-restore does not signal the backup process. If ownership becomes ambiguous, NemoClaw attempts to record durable containment and reports exact-generation recovery guidance. If the containment commit fails, NemoClaw retains any exact lifecycle and deadline gates it already owns. A state-directory failure that prevented gate publication also prevents normal mutation-lock acquisition. Correct the reported state-directory write failure, then run nemohermes <name> shields status to resume recovery or receive exact-generation recovery guidance. Snapshot metadata does not contain policy presets or exclusions.

$nemohermes my-assistant snapshot create
FlagDescription
--name <label>Attach a human-readable label to the snapshot so you can restore by name later

Names must be 1 to 63 characters from [A-Za-z0-9._-], start with an alphanumeric character, and cannot look like a version selector (v1, v2, …). Duplicate names per sandbox are rejected; pick a different name or delete the existing snapshot first.

$nemohermes my-assistant snapshot create --name before-upgrade

When a directory or state file cannot be captured, the command reports the failed items, removes the incomplete snapshot, and exits nonzero. A removed snapshot does not appear in snapshot list and cannot be restored, so a later restore cannot select a capture that never completed. When removal fails, the command reports the listed snapshot path and exits nonzero. Remove that directory manually before you run snapshot restore because the incomplete capture remains selectable.

nemohermes <name> snapshot list

List available snapshots for a sandbox as a table of version, name, timestamp, and path. Versions (v1, v2, …) are computed on read from timestamp-ascending order, so v1 is the oldest snapshot and vN is the newest. Snapshots created before this feature landed are numbered retroactively.

$nemohermes my-assistant snapshot list

nemohermes <name> snapshot restore [selector] [--to <dst>] [--force] [--yes|-y]

Restore sandbox state from a snapshot. For an in-place restore, the sandbox must be running. If no selector is provided, the latest snapshot is used. Restore removes files added after the snapshot only from state directories selected for cleanup. It preserves directories that exist only in the target manifest or whose backup failed. State replacement and mutable-config permission repair run under the same per-sandbox transition. In-place restore does not change the OpenShell policy. A cross-sandbox clone reads the source live policy and hands that document to destination creation. If the timer expires during restore work, the deadline gate blocks new mutations and waits for the exact restore owner to finish. Auto-restore does not signal the restore process.

The selector accepts any of:

  • A version (v1, v2, …, vN) from snapshot list.
  • A name passed to snapshot create --name.
  • A timestamp.

Pass --to <dst> to restore the snapshot into a different sandbox instead of the source. When dst does not exist, it is auto-created from the source image. For a Docker- or VM-driver source, the source can be stopped when its registry entry records both the sandbox image and a complete inference route. For a Kubernetes-driver source, the pod image must remain resolvable through its gateway. No re-onboarding is needed when those prerequisites are present. For a new destination, NemoClaw requires its owning gateway to report Ready state and a valid live identity. It revalidates that identity immediately before registration. The destination receives a new lifecycle generation and does not inherit the source sandbox’s generation. If the destination is not Ready with the same valid identity, the command exits nonzero before registration or state restore. The created destination remains unregistered, so --force cannot select it for deletion. Run the exact owner-scoped deletion command printed by the failure:

$openshell sandbox delete -g '<owning-gateway>' '<destination>'

After OpenShell deletes the destination, rerun the original snapshot restore --to command.

When dst already exists, snapshot restore --to <dst> refuses by default to avoid silently mutating the destination’s filesystem. To overwrite an existing destination, pass --force: the command deletes dst, then recreates it from the source’s image and restores the snapshot into the fresh copy. If the existing destination has an active shields timer, the force path restores and verifies lockdown, revokes the timer, and then deletes the destination. It clears the remaining local shields state only after deletion succeeds. The --force path prompts interactively to confirm the destination name before deleting. Pass --yes (or set NEMOCLAW_NON_INTERACTIVE=1) to skip the prompt. The snapshot selector, source image, and durable inference route are validated before any deletion. If any prerequisite is invalid, restore stops before it deletes dst.

$# restore latest snapshot in-place
$nemohermes my-assistant snapshot restore
$
$# restore by version
$nemohermes my-assistant snapshot restore v3
$
$# restore by user-assigned name
$nemohermes my-assistant snapshot restore before-upgrade
$
$# restore by timestamp
$nemohermes my-assistant snapshot restore 2026-04-21T07-35-55-987Z
$
$# clone v3 into a new sandbox
$nemohermes my-assistant snapshot restore v3 --to my-assistant-clone
$
$# overwrite an existing destination with v3, non-interactively
$nemohermes my-assistant snapshot restore v3 --to my-assistant-clone --force --yes

When --to names an existing sandbox, restore refuses to overwrite it unless you pass --force. With --force, NemoClaw confirms the destructive restore unless you also pass --yes or run with NEMOCLAW_NON_INTERACTIVE=1. Use this path only when the destination sandbox can be replaced by the selected snapshot.

nemohermes <name> share mount

Mount the sandbox filesystem on the host machine via SSHFS for bidirectional file sharing. Files edited on the host appear instantly inside the sandbox, and vice versa.

$nemohermes my-assistant share mount

Expected output:

✓ Mounted /sandbox → ~/.nemoclaw/mounts/my-assistant
ArgumentDefaultDescription
sandbox-path/sandboxRemote path inside the sandbox to mount
local-mount-point~/.nemoclaw/mounts/<name>Local directory to mount onto (auto-created)

Prerequisites:

  • sshfs must be installed on the host (sudo apt-get install sshfs on Linux, brew install macfuse && brew install sshfs on macOS).
  • The sandbox must be running.
  • The remote sandbox path must exist. NemoClaw verifies it against the target sandbox before invoking sshfs and prints a connect, then ls <path> check when the probe fails.
  • Sandboxes created before the openssh-sftp-server base image update must be rebuilt with nemohermes <name> rebuild.
  • The local mount path must be on a writable filesystem; FUSE creates the mount on the host side. If the default ~/.nemoclaw/mounts/<name> lives on a read-only filesystem, pass an explicit writable path as the second positional argument.
$# mount a specific path to a custom local directory
$nemohermes my-assistant share mount /sandbox/workspace ~/my-workspace

nemohermes <name> share unmount

Unmount a previously mounted sandbox filesystem.

$nemohermes my-assistant share unmount
ArgumentDefaultDescription
local-mount-point~/.nemoclaw/mounts/<name>Local directory to unmount

nemohermes <name> share status

Check whether the sandbox filesystem is currently mounted.

$nemohermes my-assistant share status

Expected output:

● Mounted at ~/.nemoclaw/mounts/my-assistant
ArgumentDefaultDescription
local-mount-point~/.nemoclaw/mounts/<name>Local directory to check

openshell term

Open the OpenShell TUI to monitor sandbox activity and approve network egress requests. Run this on the host where the sandbox is running.

$openshell term

For a remote server, connect through SSH and run openshell term on that server.

nemohermes tunnel start

Start optional host auxiliary services. This is the cloudflared tunnel when cloudflared is installed, which exposes the dashboard with a public URL. Channel messaging is not started here; it is configured during nemohermes onboard and runs through OpenShell-managed constructs.

$nemohermes tunnel start

By default, NemoClaw starts a Cloudflare quick tunnel and prints the generated *.trycloudflare.com URL when cloudflared reports it. Set CLOUDFLARE_TUNNEL_TOKEN to start a Cloudflare named tunnel instead. The named tunnel hostname and localhost:<dashboard-port> route must already be configured in the Cloudflare dashboard. NemoClaw passes the token to cloudflared through the TUNNEL_TOKEN environment variable, so the token does not appear in the cloudflared command-line arguments.

$export CLOUDFLARE_TUNNEL_TOKEN=<cloudflare-tunnel-token>
$nemohermes tunnel start

nemohermes start remains as a deprecated compatibility command. It exits successfully after printing guidance for nemohermes <name> start and nemohermes tunnel start; it does not start either resource itself.

nemohermes tunnel stop

Stop host auxiliary services that nemohermes tunnel start started (for example cloudflared).

Use nemohermes <name> channels stop <channel> when you only want to pause one messaging bridge.

$nemohermes tunnel stop

The command asks NemoClaw to stop an in-sandbox gateway only when NemoClaw directly owns that process. Supervisor-owned agent runtime processes remain managed inside their sandbox. The command leaves agent-owned host forwards and the managed OpenShell gateway port available.

nemohermes stop remains as a deprecated legacy full stop. In addition to stopping tunnel services, it attempts to stop the selected agent’s host forwards when the sandbox uses a manifest-resolved non-OpenClaw agent. It also attempts to safely release an unshared OpenShell gateway port whose ownership NemoClaw can verify. Shared gateways remain running, and ambiguous ownership fails closed without releasing the port. Use nemohermes tunnel stop when the shared gateway should remain available.

nemohermes tunnel status

Show the current cloudflared public-URL tunnel status for the selected or default sandbox dashboard. The output reports whether cloudflared is running, stopped, or stale, and includes the same recovery hint used by nemohermes status. Selection honors NEMOCLAW_SANDBOX_NAME, then NEMOCLAW_SANDBOX, then SANDBOX_NAME, then the registry default.

$nemohermes tunnel status

nemohermes start

Deprecated. Use nemohermes <name> start for a stopped sandbox or nemohermes tunnel start for the optional public-URL tunnel.

This compatibility command prints migration guidance and exits successfully without changing sandbox or tunnel state.

nemohermes stop

Deprecated legacy full stop. Use nemohermes tunnel stop when the shared gateway should remain available.

This command stops tunnel services and, for a manifest-resolved non-OpenClaw agent, attempts to stop the selected agent’s host forwards. It attempts to release the managed OpenShell gateway port only when the gateway is unshared and ownership is safely resolved; otherwise it preserves the gateway. When no sandbox name resolves, gateway release requires a valid, explicitly set NEMOCLAW_GATEWAY_PORT; a bare command leaves the process-wide default gateway running and reports Host services stopped; managed gateway not released. If NemoClaw attempts the release but cannot confirm it, the command reports that outcome and does not claim that all services stopped. For manifest-resolved non-OpenClaw agents, it also requests cleanup of host-forwarding resources that nemohermes tunnel stop leaves running. The command is retained for compatibility with full-stop automation. Supervisor-owned agent runtime processes remain managed inside their sandbox.

nemohermes status

Show the global sandbox list and the status of host auxiliary services (for example cloudflared). This command is host-wide. It summarizes registered sandboxes, the default sandbox’s live inference route, gateway health, and host services.

For gateway-based messaging agents, it also reports messaging overlap warnings within the selected OpenShell gateway’s sandbox registry. Use nemohermes <name> status when you need one sandbox’s live health and recovery guidance. Pass --json for machine-readable output with registered sandboxes, service state, inference routes, and health details. When the latest resumable onboarding session owns the matching inference-route reservation, it appears under Incomplete onboarding in text and as incompleteOnboarding in JSON. When present, incompleteOnboarding contains name, status (failed or in_progress), step (a string or null), interrupted (a boolean), and resumable: true; otherwise it is null. It is not counted as a registered sandbox and does not trigger sandbox or gateway health probes. Each JSON sandbox row reports agent as a string, never null. The row reports openclaw when the registry records no agent for the sandbox. This command reads the registry without gateway recovery, so it never reports unknown. For each listed sandbox, the text output includes the configured inference provider and model plus the number of active SSH sessions when the session probe is available. Host-service PID lookup honors NEMOCLAW_SANDBOX_NAME, then NEMOCLAW_SANDBOX, then SANDBOX_NAME, then the registry default.

$nemohermes status
$nemohermes status --json

When at least one sandbox is registered and the named NemoClaw gateway is unreachable, unhealthy, or attached to a different sandbox, the command prints a gateway: down [state] (reason) line between the sandbox list and the host-service list. The command classifies the failing layer when possible: the named gateway port is not accepting connections, the named gateway is running but not Connected, the active OpenShell gateway points at a different name, or the named gateway is not configured at all. It then prints the gateway recovery guidance for your host. That guidance names nemohermes onboard when NemoClaw starts the gateway process. When another deployment owns that process, the guidance directs you to start it with the owning deployment and run openshell gateway select <gateway>. It exits with code 1 so shell scripts and CI can detect the degraded state from $?. For --json, the structured output includes gatewayHealth, and the exit code is set after the report is generated. A clean machine with no registered sandboxes keeps the legacy 0 exit because no gateway is expected to be configured yet. If cloudflared is installed but not running, the host-service section reports whether the PID file is missing, invalid, or points at a dead process, then suggests nemohermes tunnel start as the recovery command.

nemohermes inference get

Show the active live inference provider and model from the NemoClaw-managed OpenShell gateway. Use this command when you want the direct runtime route without the rest of the sandbox status output. It is also available in sandbox-first form as nemohermes <name> inference get.

$nemohermes inference get
$nemohermes inference get --json

The sandbox-first grammar nemohermes <name> inference get is also accepted and reads the same gateway-wide route, so it stays symmetric with nemohermes <name> inference set.

$nemohermes my-assistant inference get

nemohermes inference set

Switch the active inference provider or model for a NemoClaw-managed Hermes sandbox. The command updates the OpenShell gateway route, patches the selected running agent config so it matches the route, recomputes the config hash, and updates the NemoClaw registry. It is also available in sandbox-first form as nemohermes <name> inference set --provider <provider> --model <model>. For Hermes, the patch updates /sandbox/.hermes/config.yaml (model.default, model.base_url, model.provider: custom, API-family mode when needed, and the OpenShell proxy API-key placeholder) and does not rebuild or restart the gateway. When the Hermes dashboard profile exists, the command also mirrors the model route into /sandbox/.hermes/profiles/dashboard-home/config.yaml for Dashboard Chat. Keeping the placeholder preserves dashboard and API authentication after provider switches. If NemoClaw cannot confirm that the dashboard config was updated, the route, registry, and main Hermes config remain committed, but the command exits nonzero without printing Inference route synced. Restart the sandbox with nemohermes <name> stop followed by nemohermes <name> start, then verify Dashboard Chat before relying on it. A missing dashboard profile is treated as disabled and does not fail the switch. Under the nemohermes alias, it uses the registered Hermes sandbox when exactly one exists; otherwise pass --sandbox <name> to target one explicitly.

By default, the command syncs the default registered sandbox. The command refuses before changing the OpenShell route when the selected sandbox has shields up. Run nemohermes <name> shields down, apply the inference change, then run nemohermes <name> shields up again.

Each OpenShell gateway exposes one inference route to every sandbox registered on that gateway. Before changing the route, NemoClaw compares the requested provider and model with every same-gateway registry entry, including stopped sandboxes. Custom compatible routes must also have matching normalized endpoint URLs and API families. Provider-global credential environment-variable names must also match for the same provider name. If a route conflicts or a legacy custom route lacks enough endpoint or API-family metadata to prove compatibility, the command exits non-zero before changing the OpenShell route, agent config, or host registry and names the conflicting sandboxes. Align those sandboxes to the same route or remove a conflicting sandbox that you no longer need.

Onboarding and connect can time-share compatible provider and model routes without replacing provider-global configuration. Refer to Use Shared Gateway Routes for the onboarding warnings, compatibility fields, and status drift report.

$nemohermes inference set --provider <provider> --model <model> [--sandbox <name>] [--no-verify] [--endpoint-url <url>] [--credential-env <ENV>] [--inference-api <api>]

You can also name the sandbox in sandbox-first position instead of passing --sandbox. nemohermes <name> inference set --provider <provider> --model <model> targets <name> directly and is equivalent to nemohermes inference set --provider <provider> --model <model> --sandbox <name>.

$nemohermes my-assistant inference set --provider nvidia-prod --model nvidia/nemotron-3-super-120b-a12b

Pass both --provider and --model when you want NemoClaw to update the OpenShell inference route and sync the selected sandbox’s agent config. NemoClaw resolves the OpenShell gateway from the target sandbox’s recorded gateway binding, including non-default NEMOCLAW_GATEWAY_PORT deployments. Do not run openshell inference set directly on a shared NemoClaw gateway because that bypasses registry compatibility checks and can break other sandboxes. When either flag is missing, nemohermes inference set reports both required flags without suggesting a raw OpenShell command. The command updates the host registry immediately after the gateway route changes.

If the in-sandbox config write or integrity hash update fails, the OpenShell route and NemoClaw registry remain committed, but the command exits with status 1 and points you to nemohermes <name> rebuild.

Supported provider names are nvidia-prod, nvidia-nim, nvidia-router, openai-api, anthropic-prod, compatible-anthropic-endpoint, gemini-api, compatible-endpoint, hermes-provider, ollama-local, and vllm-local. Use --no-verify only when OpenShell cannot verify the provider at switch time but you have already confirmed the provider and credential. When you explicitly supply a direct compatible endpoint at http://host.openshell.internal:<port>, NemoClaw skips OpenShell’s host-side provider probe because that hostname resolves only inside the sandbox network. Before it persists the route in the NemoClaw registry or agent config, the command sends a validation request from the target sandbox with a 16-token output limit. When the switch changes the API family and that request returns HTTP 400 or 404, NemoClaw retries up to two times after delays of one and two seconds. Each retry has the same 16-token output limit. Other failures are not retried. If that request fails, the command attempts to restore the previous OpenShell selection and remove a provider that this switch created. If the error reports that rollback could not complete, rerun onboarding before using the route or retrying the switch. Endpoint-shape and shared-gateway compatibility checks still apply. When switching to compatible-endpoint or compatible-anthropic-endpoint from a different provider family, pass --endpoint-url with the trusted custom provider URL and, except for the Hermes case below, --inference-api with its API family so NemoClaw can persist a complete route identity for rebuild and shared-gateway checks. For a Hermes compatible-anthropic-endpoint target, --inference-api may be omitted because NemoClaw deterministically selects openai-completions; an explicit different API family is rejected. NemoClaw rejects loopback, link-local, private, and internal endpoint addresses, including public hostnames that resolve to a private address. For a same-provider model change, pass --endpoint-url with the endpoint URL recorded during onboarding for the target sandbox. Missing or inference set provenance and every different URL remain subject to the full address validation above. For public HTTP URLs, NemoClaw stores the validated IP address to prevent DNS rebinding. For a DNS-backed HTTPS URL, NemoClaw routes the endpoint through a local HTTPS Pin Runtime adapter that terminates a pinned, SNI-correct outbound connection to the real upstream hostname; the sandbox and the persisted registry only ever see a local host.openshell.internal route, never the real hostname. HTTPS IP-literal URLs remain supported and do not need the adapter. NemoClaw accepts http://host.openshell.internal:<port> only with an explicit port from 1024 through 65535; this narrow exception supports NemoClaw’s sandbox-to-host inference routes and is not a general private-endpoint bypass. --credential-env may also be supplied for compatible provider metadata; supported --inference-api values are openai-completions, anthropic-messages, and openai-responses.

nemohermes setup

The nemohermes setup command is deprecated. Use nemohermes onboard instead.

This command remains as a compatibility alias to nemohermes onboard and accepts the same flags: --profile <name>, --non-interactive, --resume, --fresh, --recreate-sandbox, --apf-interceptor, --gpu / --no-gpu, --from, --name, --host-mount, --sandbox-gpu / --no-sandbox-gpu, --sandbox-gpu-device, --vllm-gpu-device, --agent, --agents <agents.yaml>, --tool-disclosure <progressive|direct>, --observability / --no-observability, --control-ui-port, --yes / -y, --no-ollama-autostart, --yes-i-accept-third-party-software.

$nemohermes setup

nemohermes setup-spark

The nemohermes setup-spark command is deprecated. Use the standard installer and run nemohermes onboard instead, because current OpenShell releases handle the older DGX Spark cgroup behavior.

This command remains as a compatibility alias to nemohermes onboard and accepts the same flags: --profile <name>, --non-interactive, --resume, --fresh, --recreate-sandbox, --apf-interceptor, --gpu / --no-gpu, --from, --name, --host-mount, --sandbox-gpu / --no-sandbox-gpu, --sandbox-gpu-device, --vllm-gpu-device, --agent, --agents <agents.yaml>, --tool-disclosure <progressive|direct>, --observability / --no-observability, --control-ui-port, --yes / -y, --no-ollama-autostart, --yes-i-accept-third-party-software.

$nemohermes setup-spark

nemohermes debug

Collect diagnostics for bug reports. Gathers system info, Docker state, gateway logs, and sandbox status into a summary or tarball. Use --sandbox <name> to target a specific sandbox, --quick for a smaller snapshot, or --output <path> to save a tarball that you can attach to an issue.

$nemohermes debug [--quick|-q] [--sandbox NAME] [--output PATH|-o PATH]
FlagDescription
--quick, -qCollect minimal diagnostics only
--sandbox NAMETarget a specific sandbox (default: auto-detect)
--output PATH, -o PATHWrite diagnostics tarball to the given path

If --output is set and the tarball cannot be written (for example, the destination directory is missing or read-only), the command exits non-zero so scripts can detect the failure. The tarball is written to a temporary sibling and renamed on success, so a pre-existing file at --output is preserved when tar fails.

When --sandbox is supplied explicitly through the flag or one of NEMOCLAW_SANDBOX_NAME, NEMOCLAW_SANDBOX, or SANDBOX_NAME, the name must match a registered sandbox. The flag wins, then the env vars in that order. If openshell sandbox list succeeds, the sandbox must also appear in the live gateway. An unknown or stale name exits non-zero with an actionable error that names the sandbox and reports the source env var when applicable, and no tarball is written. Without an explicit name, nemohermes debug falls back to the registry’s default sandbox and warns if that default is stale.

nemohermes credentials list

List the provider credentials registered with the OpenShell gateway. Values are not printed.

$nemohermes credentials list

nemohermes credentials add <PROVIDER>

Register a provider credential with the OpenShell gateway by name and type. Each --credential takes the env variable name whose value the gateway should read; export the value first so it is not placed in argv. Pass either repeatable --credential <ENV_NAME> or --from-existing, but do not combine them. --from-existing is available only when no managed MCP server reserves credential keys. The command fails before gateway work when a reservation exists because --from-existing does not expose credential keys before provider creation. Rerun with explicit --credential <ENV_NAME> input, or remove every managed MCP server that reserves credential keys before retrying. After the gateway accepts the provider, rebuild the target sandbox so the new provider is attached.

Registered providers attach to every sandbox you build or rebuild after the call (the gateway is one process serving all sandboxes). If you want a provider available to only some sandboxes, scope it with nemohermes credentials reset <PROVIDER> once those sandboxes finish using it.

$nemohermes credentials add tavily-search --type tavily --credential TAVILY_API_KEY
FlagDescription
--type <TYPE>Provider type (e.g. tavily, nvidia, openai, anthropic, generic)
--credential <ENV_NAME>Env variable name whose value holds the credential. Repeatable
--config <K=V>Provider configuration pair. Repeatable
--from-existingLoad credentials and config from existing local state when no managed MCP server reserves credential keys

nemohermes credentials reset <PROVIDER>

Remove a provider credential from the OpenShell gateway by provider name. After removal, re-running nemohermes onboard re-prompts for that provider’s credential. Run nemohermes credentials list first if you are not sure of the provider name.

$nemohermes credentials reset nvidia-prod
FlagDescription
--yes, -ySkip the confirmation prompt

nemohermes gc

Remove orphaned sandbox Docker images from the host. Sandbox creation can build images in the gateway-managed openshell/sandbox-from repository or the locally prebuilt nemoclaw-sandbox-local repository. The destroy and rebuild commands clean up the image automatically, but images from older NemoClaw versions or interrupted operations may remain. This command lists images from both repositories, cross-references the sandbox registry, and removes any that are no longer associated with a registered sandbox.

$nemohermes gc [--dry-run] [--yes|-y|--force]
FlagDescription
--dry-runList orphaned images without removing them
--yes, -y, --forceSkip the confirmation prompt

nemohermes uninstall

Run uninstall.sh to uninstall NemoClaw. Unless this section explicitly describes portable cleanup, its resource-removal statements apply outside portable cleanup. The CLI runs the local uninstall.sh shipped with the installed npm package. If that local script is missing, the CLI does not auto-fetch a remote copy. It prints the versioned URL of the matching uninstall.sh so you can download, review, and run it manually.

When the gateway is externally supervised, uninstall preserves its process, Docker resources, and OpenShell binaries. It still deletes the selected sandboxes and attempts to remove the modern local gateway registration. When uninstall confirms that no sibling gateways remain, it also deletes NemoClaw provider registrations. For a managed dual-Station vLLM runtime, full uninstall revalidates the exact recorded pair and removes both managed containers before starting the remaining uninstall steps. If that cleanup fails, uninstall exits nonzero, preserves its owner-only cleanup receipt, and tells you to resolve the reported peer error before retrying. Pair cleanup can partially complete before an error; verify both Stations before the retry. For an authenticated host-local vLLM runtime, full uninstall verifies the exact named container, NemoClaw ownership label, persisted API key, and authentication fingerprint before removing the container by its inspected ID. When that ownership state is missing, full uninstall removes the reserved nemoclaw-vllm container only when Docker reports its NemoClaw managed label and a valid container ID. An unlabeled container or malformed inspection remains in place and stops the remaining uninstall steps. For managed llama.cpp, full uninstall verifies the exact named container and network ownership before removing both resources by their inspected IDs. These host-local checks run before NemoClaw deletes their state. If Docker is unavailable or a resource does not match its persisted ownership state, uninstall exits nonzero before the remaining uninstall steps and preserves that state for recovery. Host-local cleanup can partially complete before an error. Restore Docker access or resolve the named ownership conflict, inspect the remaining container and network, and retry uninstall. Managed llama.cpp and vLLM model files remain in the shared Hugging Face cache by default. Outside portable cleanup, --delete-models deletes every model in the local Ollama inventory and all non-credential data in the current user’s shared ~/.cache/huggingface/ cache. This opt-in can delete cached files that other applications installed or use. It preserves the Hugging Face token and stored_tokens authentication files. NemoClaw stops and verifies its managed local and distributed model runtimes before it deletes non-credential data from the local Hugging Face cache. It does not scan arbitrary directories or delete model caches on remote peers. When sibling gateway environments remain, uninstall preserves both model stores even if you pass --delete-models. An Ollama inventory error, model deletion error, unsafe cache path, or cache-data deletion error makes uninstall exit nonzero. Cleanup can partially complete before an error, so resolve the reported error and rerun uninstall. It does not use the legacy gateway destroy command for that gateway.

Outside portable cleanup, uninstall also stops any orphaned openshell host processes left behind by previous onboard or destroy cycles, including openshell sandbox create, openshell ssh-proxy, and SSH sessions spawned by OpenShell. Earlier releases only stopped openshell forward processes, so those orphans accumulated across runs.

Outside portable cleanup, uninstall also stops matching Ollama auth proxy processes before deleting ~/.nemoclaw state so stale proxy listeners do not block a later reinstall. When sibling gateways remain, uninstall leaves the shared proxy running for them.

For Hermes setups, uninstall inspects the selected gateway’s managed port-forward watcher state, stops each verified watcher process and its sandbox-scoped forward, and leaves sibling gateway state untouched. If any watcher or forward cleanup cannot be confirmed, uninstall exits nonzero and preserves the selected gateway’s watcher state so you can retry cleanup.

Outside portable cleanup, Linux uninstall removes ~/.local/state/nemoclaw unless you pass --keep-openshell, the gateway is externally supervised, or another gateway-port environment remains on the host. That directory contains NemoClaw-owned Docker-driver gateway configuration and SQLite data, audit logs, VM-driver state, and standalone-fallback gateway PID files. Uninstall preserves it when the managed or externally supervised gateway process remains because that process depends on the state. When another gateway-port environment remains, uninstall removes only the selected gateway port’s subdirectory of that directory and keeps the other ports’ subdirectories. Run nemohermes uninstall --all-gateway-ports to remove every gateway port on the host. Keep an externally supervised lifecycle authority’s declared stateDir outside that NemoClaw-owned path. Uninstall preserves that externally supervised directory. This differs from a managed NEMOCLAW_OPENSHELL_GATEWAY_STATE_DIR override, which successful managed cleanup removes unless --keep-openshell or portable cleanup applies.

FlagEffect
--yesSkip the confirmation prompt
--keep-openshellLeave OpenShell binaries, NemoClaw-managed gateway service files, and local gateway state in place, and do not stop the host gateway process
--delete-modelsOutside portable cleanup, delete every model reported by the host’s local Ollama inventory and all non-credential data in the current user’s shared ~/.cache/huggingface/ cache after managed model runtimes stop. Hugging Face authentication files remain. Portable cleanup preserves both model stores and every Podman image.
--destroy-user-dataSkip eligible fresh sandbox backups and remove preserved user data (rebuild-backups/, backups/, sandboxes.json). Removes installer-managed user-local CLI shims under ~/.local/bin/ only when sibling evidence is unidentified. When a confirmed sibling gateway port remains, those shared shims stay with the shared npm CLI package. Portable cleanup still retains its recovery record until later completed onboarding durably supersedes it.
--all-gateway-portsUninstall every gateway port on the host, not only the port NEMOCLAW_GATEWAY_PORT selects
--gateway <name>Optional consistency check; must match the name derived from NEMOCLAW_GATEWAY_PORT

For a non-portable Docker Hermes sandbox that uses the NemoClaw-managed image, uninstall removes its managed state volume even without --destroy-user-data. Back up required Hermes state first. NemoClaw removes only a volume with exact ownership labels; inspection or removal failure exits nonzero and preserves registry state for retry.

$nemohermes uninstall [--yes] [--keep-openshell] [--delete-models] [--destroy-user-data] [--all-gateway-ports] [--gateway <name>]

NEMOCLAW_GATEWAY_PORT selects the gateway instance and state root to uninstall. Port 8080 selects nemohermes and the shared ~/.nemoclaw/ root; a non-default port selects nemoclaw-<port> and ~/.nemoclaw/gateways/<port>/. For example, NEMOCLAW_GATEWAY_PORT=9123 nemohermes uninstall selects nemoclaw-9123. If onboarding also set NEMOCLAW_OPENSHELL_GATEWAY_STATE_DIR, pass its original resolved absolute directory to uninstall so configuration, namespace, process, and state cleanup target that exact directory. Use the dedicated gateway state directory created for that port, not a shared or parent directory. Onboarding rejects relative overrides, the shared NemoClaw state root or its parents, and existing nonempty directories without valid NemoClaw-managed gateway configuration. Let onboarding create the directory when possible. Every existing ancestor, from its containing directory to the filesystem root, must be a real directory owned by the current user or root and must not be group- or world-writable. If the state directory already exists, it must be an owner-controlled, non-symbolic-link directory with mode 0700. If onboarding stops immediately after reserving that directory, uninstall removes the marker-only reservation only while the selected gateway port is free. Gateway configuration, a runtime marker, or a PID file moves cleanup to the managed-gateway checks instead. A port-bound marked gateway with valid generated configuration can be retired after the port is free and a complete process scan proves that no live process claims its state; a listener or unproven process preserves the directory. Inspect and stop the listener or matching gateway process, then rerun uninstall after the port is free. Onboarding holds an exclusive lifecycle lock from reservation through gateway initialization. If uninstall reports that onboarding owns the state directory, wait for onboarding to finish and rerun uninstall; the reservation is preserved. Successful managed cleanup recursively removes that directory and all contents; portable cleanup and --keep-openshell preserve it. Before cleanup, uninstall validates port-bound state-root ownership and exact live process identity. A marked, stopped gateway can instead use a free port plus a complete process-absence scan; pre-marker gateways can use their owner-private generated configuration as the legacy ownership proof only with live process identity.

$NEMOCLAW_GATEWAY_PORT=<port> \
>NEMOCLAW_OPENSHELL_GATEWAY_STATE_DIR="<original-absolute-path>" \
> nemohermes uninstall

The compatibility --gateway flag cannot select another instance: when present, it must match the name derived from NEMOCLAW_GATEWAY_PORT, or uninstall exits before cleanup. Default-port uninstall removes NemoClaw-managed entries in openshell/gateway.env. For a NemoClaw-managed authority, it also removes only NemoClaw’s marked Linux gateway unit. It preserves upstream Linux package units, the macOS Homebrew service, and unrelated environment entries. Gateway-scoped cleanup removes that gateway’s OpenShell resources first, then the marked Linux unit. The OpenShell gateway service therefore keeps running while uninstall deletes the selected gateway’s sandboxes. If OpenShell resource cleanup fails, uninstall exits nonzero and preserves the marked Linux unit and gateway process. If marked Linux unit cleanup fails, uninstall exits nonzero before it scans for or stops a remaining gateway process or continues with later Docker and gateway-state cleanup. OpenShell resource and Linux unit cleanup can partially complete before either failure. After selected sandbox cleanup succeeds, uninstall removes those entries from sandboxes.json before gateway registration and Linux unit cleanup. If a later step fails, the retry skips the completed sandbox deletions and resumes the remaining cleanup. Resolve the reported error. Inspect the remaining gateways with openshell gateway list. Rerun NEMOCLAW_GATEWAY_PORT=<port> nemohermes uninstall with the gateway port from the failed uninstall. For an externally supervised authority, uninstall preserves the selected local gateway state in both full and gateway-scoped cleanup. It also preserves the gateway process, supervisor resources, marked Linux unit, Docker resources, OpenShell binaries, and the declared external state directory. A custom-port uninstall does not stop or remove the default gateway service or its environment file. Uninstall does not stop an openshell-gateway process that another non-root user owns and that this installation did not record. It names the owner and process ID, leaves that process running, and continues with the remaining cleanup. If no other cleanup fails, uninstall exits with status 0 even though that process can keep its port in use. Uninstall still tries to stop a root-owned process and the gateway process that this installation recorded. If either stop fails, uninstall reports the process without printing a reusable privileged kill command. Do not signal a PID from saved output. Immediately before a privileged stop, verify that the live process owner and openshell-gateway command line match the gateway name and port. Also prove that the PID file, runtime marker, and loaded sandbox namespace still match the selected state directory. Rerun uninstall after the process stops. A gateway-scoped uninstall and every --all-gateway-ports pass exit nonzero after that failure. A single full uninstall reports the process and continues. Before each sandbox deletion during scoped Docker cleanup, NemoClaw proves the selected configuration and running gateway identity again and passes the selected gateway name to OpenShell. The configuration and running process must use the state-root-specific OpenShell sandbox namespace that NemoClaw generated. For a standalone NemoClaw-managed gateway, the live proof also binds the process owner, PID file, runtime marker, and command line to the gateway name and port. For a package-managed gateway, NemoClaw instead binds the trusted active service’s current main process, executable, owner, and loaded sandbox namespace to the default gateway. For an externally supervised gateway, NemoClaw proves the configured state. It binds the supervisor’s current main process to its owner, loaded sandbox namespace, declared executable, selected gateway name, and selected port. When NemoClaw can prove an owner-private, generated configuration and complete JWT bundle that predate state-root scoping, restart keeps the legacy gateway ID, JWT bundle, and Docker driver’s default namespace. That compatibility keeps the gateway able to find existing containers and keeps their non-expiring sandbox JWT issuer valid. NemoClaw regenerates the other gateway settings from the current runtime configuration. For a proven legacy Podman gateway, NemoClaw preserves the gateway ID that existing sandbox JWTs use; the supported Podman schema has no sandbox_namespace setting to preserve. If the existing identity is ambiguous or unsafe, or durable gateway state remains without its configuration, restart fails closed without rewriting the configuration or JWT bundle. Fresh state roots and already scoped configurations continue to use the state-root-specific identity. The legacy default namespace is not isolated across gateways, so it cannot satisfy the scoped-uninstall proof while sibling gateways remain. Scoped uninstall stops before it deletes a sandbox, registry row, or gateway registration and preserves the selected gateway’s runtime evidence and local state. Because the supported OpenShell Podman schema does not expose sandbox_namespace, scoped Podman uninstall fails closed before signaling and preserves the gateway runtime evidence and local state. Full single-gateway Podman uninstall for the portable experimental profile uses receipt-owned durable retirement and preserves shared OpenShell providers, the gateway service and process, binaries, configuration, model stores, and Podman images under the portable authority, retry, and preservation contract. For Docker, if any proof is absent, uninstall exits nonzero before it signals the host gateway. NemoClaw preserves the gateway runtime evidence and local state. Keep that state intact. For an already scoped gateway with stale runtime evidence, restore it through the supported install or onboarding recovery flow, verify the generated identity, and retry. A proven legacy gateway is not silently converted by onboarding. To retire one, first remove sibling gateways through their own proven scoped cleanup, verify that only the legacy gateway remains, and then use the full single-gateway uninstall path. For an ambiguous or incomplete identity, stop the gateway and restore the generated openshell-gateway.toml and complete jwt/ directory from a dedicated host-level backup path, represented here as <gateway-identity-backup>. The backup must have been captured from that gateway’s state directory before the failure and kept under the owning user’s exclusive access. Keep the <gateway-identity-backup> directory and its nested jwt/ directory at mode 0700, and keep the configuration and JWT files at mode 0600. The default gateway stores them under ~/.local/state/nemoclaw/openshell-docker-gateway/; a non-default gateway uses ~/.local/state/nemoclaw/openshell-docker-gateway-<port>/. Restore them as the owning user. Keep the gateway state root and its jwt/ directory at mode 0700, and do not grant group or other access to the configuration or JWT files. NemoClaw does not reconstruct gateway identity from sandbox snapshots or backup-all; if no matching gateway-state backup exists, keep the state intact rather than attempting a scoped cleanup. Verify every gateway with openshell gateway list. Retain <gateway-identity-backup> only until that command reports the restored gateway and the affected existing sandboxes authenticate successfully. Then remove that dedicated backup directory as the owning user and verify its absence by replacing the placeholder in test ! -e '<gateway-identity-backup>' with the full backup path. If verification fails, keep the backup under the same access restrictions and stop. Do not add sandbox_namespace manually to a live gateway configuration because the running process can still be using its previous namespace.

Uninstalling Every Gateway Port

A single uninstall is scoped to one gateway port, so the other ports on the host keep running and keep their ports bound. When uninstall detects other gateway-port environments, it names each one, gives the NEMOCLAW_GATEWAY_PORT=<port> command that removes one of them, and points at the whole-host sweep. A gateway environment whose port cannot be read is reported as an unidentified environment rather than omitted.

--all-gateway-ports, or NEMOCLAW_UNINSTALL_ALL_GATEWAY_PORTS=1, uninstalls all of them in one run. The sweep enumerates the default state root and the non-default roots under ~/.nemoclaw/gateways/. When the sweep finds more than one port, it confirms once against the resulting port list, then uninstalls each other port before the port NEMOCLAW_GATEWAY_PORT selects. When it finds only the selected port, it uses the standard uninstall confirmation without a port list and runs that port once. Each port runs as its own uninstall so that every port-scoped value, including the state root, registry file, gateway name, and Docker resource names, resolves from that port rather than from the calling environment. An ambient NEMOCLAW_OPENSHELL_GATEWAY_STATE_DIR applies only to the currently selected port, which runs last. Child passes for other ports use their default per-port gateway state directories. If another port with a custom directory fails, rerun NEMOCLAW_GATEWAY_PORT=<failed-port> NEMOCLAW_OPENSHELL_GATEWAY_STATE_DIR="<original-absolute-path>" nemohermes uninstall. Outside portable cleanup, the selected port runs last so its pass can remove the shared host resources once no other environment remains. --delete-models, --destroy-user-data, and --keep-openshell apply to every port, subject to the portable preservation contract; --gateway remains a check against the selected port only. A failure to enumerate the gateway state roots safely stops the sweep before any port uninstall begins. The sweep cannot select an unidentified environment until its gateway port can be determined. A port that fails to uninstall is reported, the sweep continues, and the exit code is nonzero. That port still counts as a live sibling, so the final pass falls back to gateway-scoped cleanup and preserves the shared host resources. Cleanup that completed before a port failure is not rolled back. Resolve the reported error, inspect the remaining gateways with openshell gateway list, and rerun the sweep or the named per-port command.

--all-gateway-ports, or NEMOCLAW_UNINSTALL_ALL_GATEWAY_PORTS=1, uninstalls all of them in one run. The sweep enumerates the default state root and the non-default roots under ~/.nemoclaw/gateways/. When the sweep finds more than one port, it confirms once against the resulting port list, then uninstalls each other port before the port NEMOCLAW_GATEWAY_PORT selects. When it finds only the selected port, it uses the standard uninstall confirmation without a port list and runs that port once. Each port runs as its own uninstall so that every port-scoped value, including the state root, registry file, gateway name, and Docker resource names, resolves from that port rather than from the calling environment. Outside portable cleanup, the selected port runs last so its pass can remove the shared host resources once no other environment remains. --delete-models, --destroy-user-data, and --keep-openshell apply to every port, subject to the portable preservation contract; --gateway remains a check against the selected port only. A failure to enumerate the gateway state roots safely stops the sweep before any port uninstall begins. The sweep cannot select an unidentified environment until its gateway port can be determined. A port that fails to uninstall is reported, the sweep continues, and the exit code is nonzero. That port still counts as a live sibling, so the final pass falls back to gateway-scoped cleanup and preserves the shared host resources. Cleanup that completed before a port failure is not rolled back. Resolve the reported error, inspect the remaining gateways with openshell gateway list, and rerun the sweep or the named per-port command.

User-data preservation under ~/.nemoclaw/

To avoid uninstall destroying host-side user data, uninstall preserves the following entries in the selected gateway’s state root by default. The default gateway uses ~/.nemoclaw/; a non-default gateway uses ~/.nemoclaw/gateways/<port>/.

EntryWhat it holds
rebuild-backups/Host-side snapshots that nemohermes <name> snapshot create and nemohermes backup-all write. nemohermes <name> snapshot restore reads them back after you reinstall.
backups/Host-side workspace backups that scripts/backup-workspace.sh writes. Refer to Transfer State Manually.
sandboxes.jsonHost-side sandbox registry. NemoClaw uses it to map sandbox names back to their persistence directories when you reinstall.

Outside portable cleanup, when uninstall confirms that no sibling gateways remain, it also removes shared host resources such as the gateway source clone, runtime state, and the Ollama auth proxy PID file. When sibling gateways remain, it removes only the selected gateway’s resources and port-scoped state while preserving those shared host resources. With --destroy-user-data, that scoped path removes installer-managed user-local CLI shims under ~/.local/bin/ only when sibling evidence is unidentified (for example odd ~/.nemoclaw/gateways/ entries or an unreadable gateway list). When a confirmed sibling gateway port remains, those shared shims stay with the shared npm CLI package and the other shared host resources. If the OpenShell command is unavailable or its gateway list cannot be read, uninstall cannot confirm that the selected gateway is the last one, so it uses the same scoped path and preserves the shared resources. When the command itself is unavailable, uninstall exits nonzero before OpenShell cleanup so you can restore the command and retry.

When used alone, --yes only acknowledges the global Proceed? confirmation prompt and preserves the listed host-side entries. Removing the preserved entries requires the explicit opt-in flag (--destroy-user-data) or the matching env var (NEMOCLAW_UNINSTALL_DESTROY_USER_DATA=1). Existing automation that uses --yes without either data-removal option retains those entries.

Decision matrix:

ContextBehaviour
Interactive TTY, preserved entries present, no env overridePrompts Also remove them? [y/N]. Default N keeps the entries.
Interactive TTY, user answers yRemoves the preserved entries in the selected gateway’s state root; outside portable cleanup, a single-gateway uninstall also removes the remaining shared state. Portable cleanup preserves shared OpenShell resources and its retirement record.
Non-interactive (--yes, NEMOCLAW_NON_INTERACTIVE=1, or non-TTY shell)Preserves the entries and prints a one-line notice.
--destroy-user-dataSkips the secondary user-data prompt and removes the preserved entries in the selected gateway’s state root. Removes installer-managed user-local CLI shims under ~/.local/bin/ only when sibling evidence is unidentified. When a confirmed sibling gateway port remains, those shared shims stay with the shared npm CLI package. The global Proceed? confirmation still applies unless --yes is also passed.
NEMOCLAW_UNINSTALL_DESTROY_USER_DATA=1Skips the secondary user-data prompt and removes the preserved entries. Removes installer-managed user-local CLI shims under ~/.local/bin/ only when sibling evidence is unidentified. When a confirmed sibling gateway port remains, those shared shims stay with the shared npm CLI package. The global Proceed? confirmation still applies unless --yes is also passed.

The preserved entries survive uninstall as inert files on disk. Reinstall NemoClaw and re-onboard the sandbox before nemohermes <name> snapshot restore can use them.

The preserved sandboxes.json file does not make the recorded sandboxes recoverable on its own. Uninstall deletes the selected sandboxes and attempts to remove the local gateway registration. Outside portable cleanup, after uninstall confirms that no sibling gateways remain, it also deletes provider registrations. Outside portable cleanup, a NemoClaw-managed gateway also removes the Docker image. For an externally supervised gateway, it preserves Docker resources, but the registry still cannot recover deleted sandbox and provider resources. Uninstall warns about this at preserve time. After reinstalling, the installer reports such records as not found on their recorded gateway instead of claiming they were recovered; run nemohermes <name> destroy to clear a stranded record, then nemohermes onboard to rebuild it. Pass --destroy-user-data at uninstall time if you prefer to purge the registry along with its dependencies.

nemohermes uninstall vs. the hosted uninstall.sh

Both forms execute the same uninstall.sh with the same flags, but differ in where the script comes from and how much they trust the network. Use nemohermes uninstall by default. Use the hosted curl … | bash form only when the CLI is broken or already partially removed.

nemohermes uninstallcurl … | bash (Quickstart)
Source of the scriptLocal uninstall.sh shipped with the installed npm package.Pulled live from refs/heads/main on GitHub.
Version pinningPinned to the version of NemoClaw you installed.Whatever is on main right now; may be newer than your installed CLI.
Network trustNo network fetch at uninstall time; runs a vetted local file via bash.Pipes a remote script straight to bash with no review step.
RobustnessRequires the npm package to be discoverable so the CLI can find the local script.Works even if the nemohermes CLI is missing, broken, or partially uninstalled.
Recommended forRoutine uninstalls.Recovery when the CLI is unavailable.

Internal Commands

NemoClaw registers a hidden internal command namespace. These commands are compatibility entrypoints for repo-owned scripts, such as the installer, the uninstaller, DNS setup, and developer tooling. They are not part of the supported public CLI surface.

Each command class sets hidden = true, so the commands stay out of nemohermes --help. They remain registered and routable, which is why they are listed here for reference. Treat their names, flags, and output as implementation details. They exist to back install.sh, uninstall.sh, and related automation, and they may change or be removed without notice. Most run indirectly through those scripts rather than being typed by hand.

For contributor guidance on how these command files are structured, refer to src/commands/internal/README.md.

CommandOwning script contextPurpose
nemohermes internal installer planinstall.shBuild a deterministic installer plan from environment and probe inputs without applying it.
nemohermes internal installer normalize-envinstall.shNormalize installer ref and provider environment values without applying installation changes.
nemohermes internal installer resolve-release-taginstall.shResolve the installer ref using the same precedence as install.sh.
nemohermes internal uninstall planuninstall.sh / nemohermes uninstallBuild a deterministic uninstall plan without applying it.
nemohermes internal uninstall run-planuninstall.sh / nemohermes uninstallRemove host-side NemoClaw resources from a previously built plan.
nemohermes internal uninstall classify-shimuninstall.sh / nemohermes uninstallClassify whether a shim path is safe for the uninstaller to remove.
nemohermes internal dns setup-proxyonboarding / sandbox setupConfigure the DNS forwarder bridge inside a sandbox pod.
nemohermes internal dns fix-corednsonboarding / sandbox setupPatch CoreDNS to use a non-loopback upstream resolver.
nemohermes internal dev npm-link-or-shimscripts/npm-link-or-shim.sh (development)Run npm link, falling back to a user-local NemoClaw development shim.

These commands do not appear in the command-level parity check, which compares nemohermes --help against the public command headings in this reference; hidden commands are excluded from both. The table above is the canonical reference for the script-backed family. The experimental adapter is documented separately because it has no owning script.

nemohermes internal voice-gateway serve is registered for the OpenClaw-only experimental adapter described below. Hermes and Deep Agents Code do not have an equivalent adapter.

The experimental voice gateway has no Hermes or Deep Agents Code equivalent.

Environment Variables

NemoClaw reads the following environment variables to configure service ports, onboarding behavior, and lifecycle defaults. Set them before running nemohermes onboard or any command that starts services. All ports must be non-privileged integers between 1024 and 65535, unless a variable’s own description gives a narrower range.

CLI Logging

The centralized CLI logger writes its output to stderr and uses info verbosity by default. These controls affect leveled logger output; they do not suppress command results or command-specific output that has not migrated to the centralized logger.

VariableAccepted valuesEffect
NEMOCLAW_LOG_LEVELerror, warn, info, or debug (case-insensitive; surrounding whitespace is ignored)Sets the logging threshold. A valid value takes precedence over NEMOCLAW_DEBUG. An invalid, blank, or unset value falls through to NEMOCLAW_DEBUG.
NEMOCLAW_DEBUG1, true, y, or yes (case-insensitive)Enables debug logging when NEMOCLAW_LOG_LEVEL does not contain a valid value.

The environment precedence is NEMOCLAW_LOG_LEVEL, then NEMOCLAW_DEBUG, followed by the default info level. The error level prints errors only, warn also prints warnings, info also prints informational messages, and debug prints all levels with timestamps. Use these NemoClaw-specific variables instead of the generic DEBUG variable. DEBUG is not a NemoClaw logger control and can enable dependency diagnostics that include raw command arguments.

Commands whose parser owns the base logging options also accept the hidden long-form --debug and --quiet flags, even though these options do not appear in command help. The flags are mutually exclusive. --debug overrides the environment-derived threshold and selects debug, while --quiet caps verbosity at warn without increasing an environment-derived error threshold. There is no global -q logging shorthand. Passthrough commands do not consume flags intended for the downstream command as host logging options, so use the environment variables when you need unambiguous host logging around a passthrough invocation.

VariableDefaultService
NEMOCLAW_GATEWAY_PORT8080OpenShell gateway port
NEMOCLAW_GATEWAY_BIND_ADDRESS127.0.0.1The OpenShell gateway uses this bind address. NemoClaw keeps Docker-driver gateways on loopback while gateway JWT auth is active.

| NEMOCLAW_DASHBOARD_PORT | 18789 (auto-derived from CHAT_UI_URL port if set) | Dashboard or API forward | | NEMOCLAW_VLLM_PORT | 8000 | vLLM / NIM inference | | NEMOCLAW_OLLAMA_PORT | 11434 | Ollama inference | | NEMOCLAW_OLLAMA_PROXY_PORT | 11435 | Ollama auth proxy | | NEMOCLAW_BEDROCK_RUNTIME_ADAPTER_PORT | 11436 | Host-side Bedrock Runtime adapter | | NEMOCLAW_OPENROUTER_RUNTIME_ADAPTER_PORT | 11437 | Host-side OpenRouter runtime adapter | | NEMOCLAW_HTTPS_PIN_RUNTIME_ADAPTER_PORT | 11438 | Host-side HTTPS Pin Runtime adapter | | NEMOCLAW_DASHBOARD_BIND | unset (loopback outside WSL) | Dashboard or API forward bind address. WSL uses an all-interface forward for Windows-host reachability. Set to 0.0.0.0 to opt in to remote bind on other SSH-deployed hosts. |

If a port value is not a valid integer or falls outside the allowed range, the CLI exits with an error. NEMOCLAW_GATEWAY_PORT also cannot overlap configured service, vLLM, Ollama, Ollama proxy, Bedrock Runtime adapter, OpenRouter runtime adapter, or HTTPS Pin Runtime adapter ports, and cannot use reserved auto-allocation ranges or the default inference/proxy ports 8000, 8081, 11434, 11435, 11436, 11437, and 11438. Port 8081 is reserved for authenticated existing-server attachment and the managed llama.cpp runtime. It cannot be assigned to another configurable NemoClaw service port. Each runtime adapter port must be distinct from the gateway, vLLM, Ollama, Ollama proxy, dashboard allocation range, and other runtime adapter ports. When you run multiple NemoClaw gateways with different NEMOCLAW_GATEWAY_PORT values, NemoClaw derives a separate gateway name, state directory, and compatibility container name from the port so one gateway does not tear down another. Only port 8080 uses a NemoClaw-managed Linux systemd user service or macOS Homebrew service. NemoClaw-managed gateways on custom ports run as detached processes and do not change the default gateway service. An externally supervised gateway can use any matching configured port and must be recovered through its declared supervisor. On non-WSL hosts, NEMOCLAW_OLLAMA_PORT and NEMOCLAW_OLLAMA_PROXY_PORT must be different. If you run Ollama on port 11435, set NEMOCLAW_OLLAMA_PROXY_PORT to another free port before onboarding.

NEMOCLAW_GATEWAY_BIND_ADDRESS accepts only 127.0.0.1 and 0.0.0.0, but NemoClaw rejects 0.0.0.0 for Docker-driver gateways while gateway JWT auth is active.

Keep the OpenShell gateway on loopback and use NEMOCLAW_DASHBOARD_BIND when you need remote browser/API access.

NEMOCLAW_DASHBOARD_BIND controls the dashboard or API port forward bind address. Outside WSL, the forward stays on 127.0.0.1 (loopback only) by default. On WSL, NemoClaw binds the host-side forward on all interfaces so the Windows host can reach it, while the ready summary continues to print a loopback dashboard URL. On non-WSL SSH-deployed hosts, set NEMOCLAW_DASHBOARD_BIND=0.0.0.0 before nemohermes onboard to prepare the sandbox for remote exposure and bind the forward on all interfaces. Use the same setting for later nemohermes <sandbox> connect calls. A sandbox created without this opt-in must be recreated with NEMOCLAW_DASHBOARD_BIND=0.0.0.0 nemohermes onboard --recreate-sandbox before a remote-bind connect is allowed. Only 0.0.0.0 enables the remote bind; onboarding rejects any other non-empty value.

$export NEMOCLAW_DASHBOARD_PORT=19000
$nemohermes onboard

These overrides apply to onboarding, status checks, health probes, and the uninstaller. Defaults are unchanged when no variable is set.

If NEMOCLAW_DASHBOARD_PORT or the port from CHAT_UI_URL is already occupied by another sandbox, onboarding scans 18789 through 18799 and uses the next free dashboard port. Pass --control-ui-port <N> to require a specific port.

For Hermes, NEMOCLAW_DASHBOARD_PORT controls the built-in dashboard forward, which defaults to 18789. The OpenAI-compatible API is separate and serves /v1 on a per-sandbox port that defaults to 8642. If 8642 is already held by another sandbox or by a non-OpenShell host listener, onboarding scans 8642 through 8652 and uses the next free API port. Set NEMOCLAW_HERMES_API_PORT=<N> before you onboard a new sandbox to pin a port from 8642 through 8652. If another sandbox or host listener holds the pinned port, onboarding exits instead of selecting a different port. The sandbox relay binds the port when the sandbox starts, so set this variable for an existing sandbox only together with --recreate-sandbox. For an existing sandbox, a different value without --recreate-sandbox exits before the host forward changes. Set NEMOCLAW_HERMES_DASHBOARD_TUI=1 only when you want Hermes’ optional in-browser TUI tab.

VariableDefaultService
NEMOCLAW_DASHBOARD_PORT18789Hermes built-in dashboard forward port
NEMOCLAW_HERMES_API_PORT8642Hermes OpenAI-compatible API forward port
NEMOCLAW_HERMES_DASHBOARD_TUI0Optional Hermes in-browser TUI tab

Onboarding Configuration

The following variables let you tune onboarding without editing the Dockerfile or passing repeated flags. Set them before running nemohermes onboard.

VariableFormatEffect
NEMOCLAW_PROVIDERprovider key (e.g. build, openrouter, openai, anthropic, anthropicCompatible, gemini, ollama, custom, vllm, nim-local, routed, hermes-provider, llama-cpp, install-llama-cpp, install-vllm, install-ollama, install-windows-ollama, start-windows-ollama)Selects the inference provider during onboarding. The wizard skips the provider menu in both interactive and non-interactive runs when this is set. On a qualified N1x host, only install-vllm supplies the explicit Deferred preview intent; another provider stops installation before onboarding. llama-cpp selects attachment of an authenticated, operator-managed llama.cpp server on loopback port 8081. Set NEMOCLAW_LLAMACPP_LOCAL_TOKEN; set NEMOCLAW_MODEL to the served alias when the server exposes multiple models. install-llama-cpp selects the experimental DGX Spark managed path and rejects NEMOCLAW_MODEL; use NEMOCLAW_LLAMACPP_RECIPE for its declarative selection. If an operator-managed server does not provide consistent native llama.cpp evidence, select custom. Aliases: cloudbuild, open-router / openrouteraiopenrouter, nimnim-local, hermes / nous / nous-portalhermes-provider, anthropiccompatibleanthropicCompatible. Invalid values fail fast with the list of accepted keys.
NEMOCLAW_LLAMACPP_RECIPErepository-owned managed-inference recipe IDSelects the managed llama.cpp recipe when NEMOCLAW_PROVIDER=install-llama-cpp, including a compatible lower-priority profile. When unset, NemoClaw selects the unique highest-priority compatible automatic profile. An unknown recipe, an ambiguous selection, or a stale or incompatible readiness report fails before image, model, or runtime effects.
NEMOCLAW_MODELmodel IDSelects an explicit model for a non-interactive onboarding run. NemoClaw preserves it across a detected provider switch, even when it matches the recorded provider’s default. When this variable is unset during such a switch, NemoClaw ignores the NEMOCLAW_PROVIDER_MODEL compatibility fallback and uses normal provider model selection.
NEMOCLAW_TOOL_DISCLOSUREprogressive or directSelects progressive tool discovery or the prior direct-exposure behavior outside the Portable experimental profile. Defaults to progressive; --tool-disclosure takes precedence when both are set. Fresh Portable onboarding ignores this variable and defaults to direct unless the flag explicitly selects a mode.
NEMOCLAW_ENDPOINT_URLURLCustom endpoint URL. Used together with NEMOCLAW_PROVIDER=custom for OpenAI-compatible endpoints or NEMOCLAW_PROVIDER=anthropicCompatible for Anthropic-compatible endpoints. Onboarding rejects a URL that contains userinfo, query, or fragment components. It also rejects a URL that contains control characters, percent-encoded control characters, spaces within the URL, shell metacharacters, or other characters outside the URL-safe ASCII set, and a value that is not an absolute HTTP or HTTPS URL. NemoClaw trims ASCII spaces at the start and end of the URL before validation.
NEMOCLAW_COMPATIBLE_AUTH_MODEnone or unsetExplicitly selects no authentication during non-interactive onboarding for an OpenAI-compatible HTTP endpoint on localhost, 127.0.0.1, or [::1] and the port selected by NEMOCLAW_VLLM_PORT (8000 by default) or port 11434. Port 11435 requires NEMOCLAW_OLLAMA_PROXY_PORT to use a different free port.
NEMOCLAW_TRUSTED_PRIVATE_HOSTScomma-separated exact hostnames or IP literalsAllows operator-owned RFC1918, CGNAT, or IPv6 unique local destinations through supported inference, managed MCP, and custom-policy registration paths. Link-local metadata and other reserved ranges remain blocked; DNS resolution and address pinning remain active; wildcards are not supported.
NEMOCLAW_TRUSTED_PRIVATE_INFERENCE_HOSTScomma-separated hostnames or IP literalsInference-only compatibility alias. Inference onboarding combines entries from this variable and NEMOCLAW_TRUSTED_PRIVATE_HOSTS.
NEMOCLAW_PREFERRED_APIcompletions (currently the only honored value)Forces the validation probe to use the /v1/chat/completions API path instead of the newer /v1/responses API.
NEMOCLAW_OLLAMA_REQUIRE_TOOLS0 to disable, anything else to keep the defaultWhen set to 0, skips the Ollama tool-calling capability check during local-inference onboarding.
NEMOCLAW_OLLAMA_INSTALL_MODEsystem, user, or empty/unsetPins the Linux Ollama install location. Refer to the Linux Ollama install mode details below.
NEMOCLAW_PROXY_HOSThostname or IPOverrides the sandbox-side outbound HTTP proxy host. Defaults to 10.200.0.1.
NEMOCLAW_PROXY_PORTinteger portOverrides the sandbox-side outbound HTTP proxy port. Defaults to 3128.

| NEMOCLAW_OPENSHELL_BIN | path | Overrides the openshell binary the CLI invokes. Defaults to openshell (resolved via PATH). | | NEMOCLAW_SANDBOX_NAME | sandbox name | Preferred environment override for the default sandbox. Used by onboarding defaults and host-level commands such as list, status, tunnel, services, and debug. | | NEMOCLAW_SANDBOX | sandbox name | Alternate spelling of NEMOCLAW_SANDBOX_NAME; used when neither a flag nor NEMOCLAW_SANDBOX_NAME is set. | | SANDBOX_NAME | sandbox name | Compatibility spelling used after NEMOCLAW_SANDBOX_NAME and NEMOCLAW_SANDBOX. | | NEMOCLAW_INSTALL_REF | git ref | For internal installer commands: the git ref to install from. A nonempty value takes precedence over NEMOCLAW_INSTALL_TAG. Overridden by the --install-ref flag. | | NEMOCLAW_INSTALL_TAG | release tag | For internal installer commands: the release tag to install when NEMOCLAW_INSTALL_REF is unset or empty. Defaults to the admin-promoted lkg tag when unset. Overridden by the --install-tag flag. | | NEMOCLAW_ENABLE_LOCAL_MODEL_PROFILE | 1 to enable | Enables the fixed vLLM local model profile. Requires NEMOCLAW_LOCAL_MODEL_RUNTIME=vllm. Direct nemohermes onboard use also requires NEMOCLAW_NON_INTERACTIVE=1. The hosted installer makes onboarding non-interactive, disables Express selection, and sets this value automatically when it receives --local-model-runtime=vllm. | | NEMOCLAW_LOCAL_MODEL_RUNTIME | vllm | Selects the fixed vLLM local model profile. Requires NEMOCLAW_ENABLE_LOCAL_MODEL_PROFILE=1; direct onboarding also requires NEMOCLAW_NON_INTERACTIVE=1. The hosted installer sets this value from --local-model-runtime=vllm. | | NEMOCLAW_VLLM_MODEL | registry slug or Hugging Face model ID | Selects the model the managed-vLLM install path serves and remains authoritative during DGX Station installer setup. Slugs and full model IDs are case-insensitive. Recognized slugs: qwen3.6-27b, qwen3.6-35b-a3b-nvfp4, muse-glimmer-30b, nemotron-3.5-lightning-30b, nemotron-3-nano-4b, deepseek-v4-flash, nemotron-3-ultra-550b-a55b, deepseek-r1-distill-70b. The muse-glimmer-30b and nemotron-3.5-lightning-30b profiles are Experimental on DGX Spark and Linux x86_64 with a qualifying NVIDIA GPU. NemoClaw does not enable vision or DFlash speculative decoding for Muse Glimmer. Station Express selects nemotron-3-ultra-550b-a55b; a qualified reciprocal pair uses the distributed topology, while no qualifying pair retains the single-Station Ultra topology. Outside Station Express, unset uses the per-platform profile default. Gated models (for example, deepseek-r1-distill-70b) require HF_TOKEN or HUGGING_FACE_HUB_TOKEN. | | NEMOCLAW_DGX_STATION_PEER | SSH host or user@host | Selects one exact, already-trusted DGX Station peer for Nemotron 3 Ultra pair qualification. The peer must match the reciprocal private /30 rail and hardware checks; an explicit peer failure stops setup instead of falling back. NemoClaw does not enroll SSH trust or accept a port or SSH option in this value. When unset, DGX Station installer discovery checks only the two deterministic /30 counterpart addresses. A peer cannot be combined with an explicit non-Ultra model; conflicting explicit selections fail before pair preparation. | | NEMOCLAW_DGX_STATION_SSH_BINDING | opaque installer-managed token | Carries the qualified peer endpoint and host-key binding from DGX Station pair preparation into the current managed-vLLM install. The installer creates and clears this token; operators should not set or persist it. Missing, changed, or mismatched binding state fails before peer SSH or Docker work. | | NEMOCLAW_VLLM_EXTRA_ARGS_JSON | JSON array of non-blank strings | Appends advanced operator-owned tokens to the managed vllm serve command after NemoClaw’s registry defaults. Example: ["--max-num-seqs","2"]. Malformed JSON, non-string tokens, blank tokens, or an invalid --gpu-memory-utilization override fail before Docker work starts. The last memory-utilization override also controls the early and immediate pre-launch GPU-memory checks. | | NEMOCLAW_MODEL_ROUTER_PYTHON | absolute path | Pins the host Python interpreter used to create the Model Router virtual environment. Strict. NemoClaw probes only that interpreter and aborts with the failure reason if it does not qualify, rather than silently falling back to another python. Relative command names such as python3.12 are rejected. When unset, NemoClaw probes python3.13, python3.12, python3.11, python3.10, and bare python3, retains every interpreter whose version is in [3.10, 3.14) and whose ensurepip, pyexpat, ssl, and venv stdlib modules import cleanly, and tries python -m venv on each in priority order until one succeeds. Set the pin when the auto-discovered interpreter is broken (for example, Homebrew python@3.14 with a pyexpat dlopen mismatch on macOS). |

Hermes-specific onboarding configuration:

VariableFormatEffect
NEMOCLAW_WEB_SEARCH_PROVIDERtavily or noneSelects Tavily Search in non-interactive onboarding or disables web search explicitly. When unset, TAVILY_API_KEY implicitly selects Tavily.
TAVILY_API_KEYTavily Search API keySupplies and implicitly selects Tavily Search when no web search provider is set. NemoClaw validates the key and stores it in OpenShell rather than the sandbox.
NEMOCLAW_HERMES_AUTH_METHODoauthSelects Hermes Provider authentication in non-interactive onboarding. Valid values: oauth, nous-portal-oauth, api-key, nous-api-key.
NEMOCLAW_HERMES_AUTHsame as NEMOCLAW_HERMES_AUTH_METHODBack-compatible alias for Hermes Provider authentication selection.
NEMOCLAW_NOUS_AUTH_METHODsame as NEMOCLAW_HERMES_AUTH_METHODNous-specific alias for Hermes Provider authentication selection.
NEMOCLAW_HERMES_TOOL_GATEWAYScomma-separated listSelects managed Hermes tool gateways in non-interactive onboarding. Valid values are nous-web, nous-image, nous-audio, nous-browser, and nous-code; the nous- prefix is optional. Unknown values fail before sandbox creation.
NEMOCLAW_HERMES_TOOL_GATEWAY_PRESETScomma-separated listBack-compatible alias for NEMOCLAW_HERMES_TOOL_GATEWAYS.
NEMOCLAW_CONTEXT_WINDOWpositive integer, at least 64000 tokensOverrides model.context_length in the generated Hermes config. Fresh and resumed Local Ollama onboarding, including sandbox rebuilds, must verify a loaded runtime context at least as large as this value.
NEMOCLAW_EXTRA_PLACEHOLDER_KEYSwhitespace- or comma-separated list of upper-snake env keysAdds operator-supplied OpenShell provider rows so per-profile credentials such as TELEGRAM_BOT_TOKEN_AGENT_A flow through the same out-of-process placeholder injection that the canonical channel tokens use, instead of being baked into each Hermes profile .env as raw text. Refer to Extra placeholder keys for the entry shape and validation rules.

Extra placeholder keys

Set NEMOCLAW_EXTRA_PLACEHOLDER_KEYS before running nemohermes onboard when one container hosts multiple Hermes profiles and each profile needs its own messaging-bridge credential.

$export NEMOCLAW_EXTRA_PLACEHOLDER_KEYS="TELEGRAM_BOT_TOKEN_AGENT_A TELEGRAM_BOT_TOKEN_AGENT_B"
$export TELEGRAM_BOT_TOKEN_AGENT_A=<bot-A-token>
$export TELEGRAM_BOT_TOKEN_AGENT_B=<bot-B-token>
$nemohermes onboard --agent hermes

For each entry, NemoClaw registers an OpenShell provider with the endpointless nemoclaw-mcp-v1 profile. OpenShell resolves the named credential placeholder to the operator-supplied value at egress. The Hermes profile .env files are operator-owned: write ${TELEGRAM_BOT_TOKEN_AGENT_A} (or the matching placeholder for each entry) into the per-profile .env so the in-sandbox Hermes process inherits the OpenShell placeholder instead of a raw token. NemoClaw never reads, writes, or rewrites these .env files; verify after onboarding that each profile’s .env references the placeholder and that no raw bot token value sits on disk.

Entries are split on whitespace and commas and must match ^[A-Z][A-Z0-9_]{0,127}$. Each entry must extend a canonical channel envKey with a non-empty _<suffix> (for example TELEGRAM_BOT_TOKEN_AGENT_A); the canonical envKeys are TELEGRAM_BOT_TOKEN, DISCORD_BOT_TOKEN, SLACK_BOT_TOKEN, SLACK_APP_TOKEN, WECHAT_BOT_TOKEN, BRAVE_API_KEY, and TAVILY_API_KEY. Bare canonical envKeys, the control env itself, and arbitrary host secret names (GITHUB_TOKEN, AWS_SECRET_ACCESS_KEY, KUBECONFIG, and similar) are refused so they cannot leak into the sandbox provider gateway. Duplicates are dropped silently. The list is capped at 32 entries per sandbox. Offending tokens emit one warning each and are skipped.

If a referenced env is unset at onboard time, the matching provider row is registered with a null token; the upsertMessagingProviders helper then skips the row, so no placeholder is attached to the OpenShell gateway and no Hermes profile can resolve it. Export the credential before running nemohermes onboard for that profile.

Linux Ollama install mode details

Set NEMOCLAW_OLLAMA_INSTALL_MODE=system to run the official https://ollama.com/install.sh installer, which uses sudo, writes to /usr/local, and configures systemd. Set NEMOCLAW_OLLAMA_INSTALL_MODE=user to extract the release tarball to ${HOME}/.local without sudo and launch the daemon manually without systemd persistence. Leave NEMOCLAW_OLLAMA_INSTALL_MODE empty or unset to let NemoClaw auto-detect the mode. Auto-detection selects system when the current user is root or passwordless sudo works. Auto-detection selects user in non-interactive runs without passwordless sudo. An interactive shell falls back to system so the official installer can prompt for the password. NemoClaw rejects any other value. On upgrades, NemoClaw rejects user because a user-local install cannot replace the system daemon on :11434. On upgrades, NemoClaw also rejects system under NEMOCLAW_NON_INTERACTIVE=1 when passwordless sudo is unavailable because the installer would hang on a hidden sudo prompt. The run exits with an actionable diagnostic instead.

Experimental NemoCUA

Keep NEMOCLAW_CUA_ENABLED=1 set whenever NemoClaw uses the experimental nemocua agent, including discovery, launch, agent commands, sandbox creation, and rebuild.

VariableFormatEffect
NEMOCLAW_CUA_ENABLEDexactly 1 to enableExposes the experimental nemocua agent. Other values keep it absent from agent discovery and prevent its manifest from loading.
NEMOCLAW_CUA_SANDBOX_IMAGE_REFimage referenceSelects the caller-prepared NemoCUA sandbox image when NEMOCLAW_CUA_ENABLED=1. NemoClaw uses this reference directly and does not resolve a private package source. The value is required whenever NemoClaw creates or rebuilds the NemoCUA sandbox; whitespace and shell syntax are rejected.

Onboarding Behavior Flags

The following flags toggle optional behaviors during onboarding. Set them before running nemohermes onboard.

VariableFormatEffect
NEMOCLAW_YES1 to enableAuto-accepts confirmation prompts (--yes equivalent) including in helpers like the Ollama proxy auth setup, but does not change managed-vLLM storage-warning handling. Express and other non-interactive setup stop after a verified insufficient-capacity warning, interactive setup still requires an explicit y or yes, and an inconclusive model-cache check stops non-interactive setup with guidance to rerun interactively.
NEMOCLAW_OLLAMA_NO_AUTOSTART1 to enableSkips the wizard’s eager Ollama auto-start during inference-provider selection (equivalent to passing --no-ollama-autostart). When set and Ollama is not running on localhost:11434, an agent that uses the legacy 16384-token context floor, currently OpenClaw, prints a warning and selects the default fallback model instead of spawning ollama serve. An agent that requires a larger verified runtime context, currently Hermes at 64000 tokens, returns to interactive provider selection or exits when the Ollama provider is pinned or onboarding is non-interactive. The flag covers only the provider-selection step; later setup steps (auth proxy, validation, model warm) still expect a reachable Ollama. On Linux hosts with a systemd Ollama unit, the loopback-override path may still restart the daemon before this gate runs.
NEMOCLAW_NON_INTERACTIVE_SUDO_MODEprompt or empty/unsetWhen set to prompt, allows non-interactive onboarding to use prompt-capable sudo for host setup steps that require elevation, which can ask for a password. Empty/unset is the default and uses sudo -n, which fails instead of asking for a password. Any other value is rejected.
NEMOCLAW_NO_EXPRESS1 to enableInstaller-only. Skips the DGX Spark, DGX Station, and Windows WSL express prompt, then continues with the normal interactive onboarding flow. On N1x, setting this variable alone stops installation before onboarding. Combine it with NEMOCLAW_PROVIDER=install-vllm only when you intend to bypass the preview prompt with explicit Deferred managed-vLLM intent.
NEMOCLAW_EXPERIMENTAL1 to enableSurfaces experimental providers and flows in onboarding.
NEMOCLAW_IGNORE_RUNTIME_RESOURCES1 to enableSuppresses the under-provisioned runtime warning during preflight. Use only when you know the sandbox host meets the minimums.
NEMOCLAW_DISABLE_OVERLAY_FIX1 to enableSkips the Docker overlay-fix step during sandbox build. For environments where the fix is incompatible.
NEMOCLAW_OVERLAY_SNAPSHOTTERsnapshotter nameSelects the containerd overlay snapshotter for sandbox builds. Empty (default) preserves containerd’s choice.

| NEMOCLAW_SKIP_TELEGRAM_REACHABILITY | 1 to enable | Skips the Telegram bot reachability probe during onboard (useful in restricted networks). | | NEMOCLAW_SKIP_SLACK_AUTH_VALIDATION | 1, true, yes, or on to enable | Skips the live Slack auth.test and apps.connections.open credential probes during onboard and channels add slack. Use only in restricted networks or hermetic test environments; Slack token format checks still apply. | | NEMOCLAW_RESOURCE_PROFILE | profile name or default | Selects a sandbox CPU/RAM resource profile from the blueprint during onboarding. default means no resource preference, so NemoClaw passes no OpenShell CPU or memory flags. Unknown names fail fast. | | NEMOCLAW_CPU | percentage or Kubernetes CPU quantity | Overrides the selected profile’s CPU size passed to OpenShell --cpu. Percentages resolve against detected capacity. | | NEMOCLAW_RAM | percentage or Kubernetes memory quantity | Overrides the selected profile’s memory size passed to OpenShell --memory. Percentages resolve against detected capacity. | | NEMOCLAW_SANDBOX_GPU | auto, 1, or 0 | Controls sandbox GPU passthrough during onboarding. auto enables GPU passthrough when an NVIDIA GPU is detected, 1 requires GPU passthrough, and 0 forces CPU-only sandbox creation. | | NEMOCLAW_SANDBOX_GPU_DEVICE | NVIDIA GPU index, UUID, or CDI device name | Selects the GPU through OpenShell driver config on native Docker and Podman routes, or through the equivalent container-runtime selector on a compatibility route. Requires explicit sandbox GPU enablement with NEMOCLAW_SANDBOX_GPU=1 (or --sandbox-gpu for CLI-driven onboarding); otherwise onboarding rejects the selector instead of treating it as an implicit opt-in. | | NEMOCLAW_SANDBOX_BASE_IMAGE_REFRESH | 1, true, yes, or on to enable | Bypasses recorded sandbox base-image resolution metadata during onboarding, recreation, and rebuild. NemoClaw reruns candidate resolution but can still use a compatible image from Docker’s local image store. Versioned release candidates that exist locally but fail validation are refreshed from the registry once during normal resolution. This setting does not discard onboarding session state. | | NEMOCLAW_SANDBOX_BASE_LOCAL_BUILD | unset or auto (default); 1, true, yes, or on to enable; 0, false, no, or off to disable | Controls whether base-image resolution may build a compatible image locally. The default allows builds during normal CLI runs and disables them when NODE_ENV=test or VITEST=true. When source inputs or a missing/incompatible release-version base require a fresh build, disabling local builds makes resolution fail instead of using an unproven image. | | NEMOCLAW_DOCKER_GPU_PATCH | unset, auto, fallback, 1, or 0; other legacy nonzero values remain accepted through v0.0.x and will be removed in v0.1.0 | Selects Linux Docker-driver GPU routing. Unset, auto, or 0 uses native OpenShell GPU injection on ordinary native Linux. fallback explicitly opts into one native attempt followed by one bounded compatibility retry when trusted host evidence identifies a GPU-routing failure. 1 and legacy nonzero values select the compatibility patch from the outset. Docker Desktop WSL and Jetson/Tegra use the compatibility path by default; Docker Desktop WSL ignores 0, while Jetson/Tegra accepts 0 only as a troubleshooting override that bypasses device-group propagation. Portable onboarding requires native OpenShell GPU injection for every agent and does not use this setting. | | NEMOCLAW_OPENSHELL_GATEWAY_CONTAINER_PATCH | 1 to enable; disabled by default | This setting explicitly opts into the Linux gateway compatibility container for an older host ABI or a diagnostic run; use it only on a trusted local host because it uses host networking and mounts the Docker socket read-only even though the socket still exposes the privileged Docker API; prefer OpenShell 0.0.106’s directly supported glibc 2.39+ path; see Gateway Compatibility Container for the container boundary and removal conditions. | | NEMOCLAW_OPENSHELL_GATEWAY_BIN | path | Advanced override for the openshell-gateway binary used by Linux Docker-driver startup. For the default port, the installer accepts the binary under an absolute XDG_BIN_HOME when set, otherwise ~/.local/bin/openshell-gateway; it also accepts /usr/local/bin/openshell-gateway or /usr/bin/openshell-gateway. Another path fails service staging. The macOS Homebrew service uses the formula’s binary. Defaults to the binary next to openshell, then common install paths. | | NEMOCLAW_OPENSHELL_SANDBOX_BIN | path | Advanced override for the openshell-sandbox binary used by Linux Docker-driver startup. The macOS Homebrew service uses the formula’s driver layout. Defaults to the binary next to openshell, then common install paths. | | NEMOCLAW_OPENSHELL_GATEWAY_STATE_DIR | path | Advanced override for the Linux Docker-driver gateway SQLite state directory and standalone-fallback PID file. Use a dedicated absolute directory; onboarding rejects relative paths, the shared NemoClaw state root or its parents, and existing nonempty directories without valid managed gateway configuration. Let onboarding create it when possible; its containing directory must be owned by the current user or root without group or world write access, and a pre-created state directory must be owner-controlled, non-symbolic, and mode 0700. Pass the original resolved absolute value with NEMOCLAW_GATEWAY_PORT when uninstalling that gateway. Port 8080 defaults to ~/.local/state/nemoclaw/openshell-docker-gateway; non-default ports default to ~/.local/state/nemoclaw/openshell-docker-gateway-<port>. | | NEMOCLAW_AUTO_FIX_FIREWALL | 1 to enable | Opts in to automatic UFW remediation when Linux Docker-driver sandbox containers cannot reach the host gateway after a proven TCP failure. NemoClaw runs sudo -n only, validates the narrow Docker bridge subnet → gateway IP:port rule before invoking UFW, re-probes after applying it, and otherwise falls back to the printed manual command. | | NEMOCLAW_WECHAT_QUIET | 1 to enable | Silences [wechat] poll diagnostics, including status updates and recoverable errors, during the host-side WeChat QR login. Host-side IDC redirect notices remain visible. |

Set NEMOCLAW_HERMES_SANDBOX_BASE_IMAGE_REF to a Hermes sandbox-base tag or digest to override base-image resolution during onboarding. NemoClaw requires environment overrides to use the official remote repository and resolve to a repository digest, validates the requested image for the required MCP runtime, and keeps the final image bound to that trusted base. NemoClaw accepts local bases only when it builds and pins them during onboarding.

Onboard Profiling Traces

Set NEMOCLAW_TRACE=1 before nemohermes onboard to write an OpenTelemetry-style JSON trace for the run. If you do not set a trace path, NemoClaw writes a timestamped file under .e2e/traces/ in the current working directory. Use NEMOCLAW_TRACE_DIR to choose the output directory, or NEMOCLAW_TRACE_FILE to choose the output file.

$NEMOCLAW_TRACE=1 nemohermes onboard
$NEMOCLAW_TRACE_DIR=/tmp/nemoclaw-traces nemohermes onboard
$NEMOCLAW_TRACE_FILE=/tmp/nemoclaw-onboard-trace.json nemohermes onboard

Trace artifacts include onboard phase timing, sandbox and service readiness waits, policy application, inference validation probes, curl probe results, and sandbox build progress events. Secret-like metadata such as API keys, bearer tokens, cookies, and credentials is redacted before the file is written.

Probe Timeouts

The following variables tune how long internal probes wait before giving up. Defaults are sized for typical hardware; override only if you see false-positive timeouts.

VariableDefaultEffect
NEMOCLAW_MCP_PROVIDER_SYNC_TIMEOUT_SECONDS30Maximum time to wait for an OpenShell MCP provider credential revision to become active or fully revoked inside the sandbox. Integer seconds; raise only when provider synchronization is unusually slow.
NEMOCLAW_PORTABLE_PODMAN_STARTUP_TIMEOUT_MS60000Maximum cold-start time for portable rootless Podman socket activation and the first real API response. Set an integer from 15000 through 300000 milliseconds. This setting does not change the fixed 10,000 ms steady-state API deadline.
NEMOCLAW_SANDBOX_EXEC_TIMEOUT_MSper call site (typically 15000)Overrides the default timeout for openshell sandbox exec calls issued by recovery and lifecycle helpers. Integer milliseconds; non-positive or non-numeric values fall back to the per-call-site default.
NEMOCLAW_STATUS_PROBE_TIMEOUT_MSbuilt-in defaultOverrides the timeout for the OpenShell status probe used by nemohermes <name> status. Integer milliseconds; non-positive or non-numeric values fall back to the default.
NEMOCLAW_WSL_GPU_PROOF_TIMEOUT_MS180000Maximum time for the bounded Docker CUDA workload on an eligible ARM64 Linux host. A positive finite number of milliseconds overrides the default. Invalid, infinite, zero, and negative values use the default.

Onboard and Sandbox Readiness Timeouts

The following environment variables tune onboard-time and recovery wall-clock limits. Set the onboarding variables before running nemohermes onboard if a slow connection or large model pull risks tripping the default.

VariableDefaultPurpose
NEMOCLAW_OLLAMA_PULL_TIMEOUT1800 (30 minutes)Wall-clock timeout for ollama pull during onboard, in seconds. Accepts integer or float values. Already-downloaded layers are kept; re-running the pull resumes them.
NEMOCLAW_LOCAL_INFERENCE_TIMEOUT180Wall-clock timeout for the inference-server validation probe during onboard, in seconds. Raise on slow networks or for very large prompts.
NEMOCLAW_SANDBOX_READY_TIMEOUT180Wall-clock timeout for post-create readiness, in seconds. Raise the timeout when the managed-image pull, explicit custom image build, gateway upload, or in-sandbox boot exceeds the default (typical on 70B+ models, first-time gateway uploads over slow links, or DGX Station / remote-VM first runs). Ordinary onboarding deletes the partially created sandbox when the deadline expires and prints the retry hint. Portable OpenClaw onboarding instead preserves the sandbox when NemoClaw cannot verify its runtime identity.
NEMOCLAW_SANDBOX_READY_ERROR_DEBOUNCE30Consecutive Error-phase polls the post-create readiness wait tolerates before treating Error as terminal. Polling starts at 250ms and backs off to a 2-second cap, while NEMOCLAW_SANDBOX_READY_TIMEOUT remains the overall deadline. The gateway can briefly report a just-created sandbox in Error while it re-registers the sandbox (seen on DGX Spark); the debounce lets that transient recover to Ready. Failed and CrashLoopBackOff always fail immediately. Set to 1 to restore fast-fail on the first Error poll.
NEMOCLAW_GATEWAY_RECOVERY_WAIT_SECONDS30, 90, or 120, depending on the recovery phaseWall-clock timeout for OpenShell command re-registration after policy application, plus gateway health and re-registration during managed OpenClaw or Hermes recovery. A valid finite, nonnegative value overrides the internal budget for the current recovery phase.

For newly created OpenClaw and Hermes sandboxes, NEMOCLAW_SANDBOX_READY_TIMEOUT also covers the durable sandbox ID and no-op command checks that follow the OpenShell Ready state.

An unset, blank, invalid, or negative NEMOCLAW_GATEWAY_RECOVERY_WAIT_SECONDS value uses 30 seconds for OpenClaw gateway health and 90 seconds for Hermes gateway health. Recreated-sandbox OpenShell registration uses 120 seconds when the recovery path does not supply another budget.

For managed recovery, NEMOCLAW_GATEWAY_RECOVERY_WAIT_SECONDS covers OpenShell re-registration before state restoration and replacement commit. When the deadline expires, NemoClaw attempts to roll back the replacement and leaves the primary dashboard or API host forward stopped.

$export NEMOCLAW_OLLAMA_PULL_TIMEOUT=3600
$export NEMOCLAW_SANDBOX_READY_TIMEOUT=600
$nemohermes onboard

Set the recovery override before a start or recover command that can recreate the sandbox.

$export NEMOCLAW_GATEWAY_RECOVERY_WAIT_SECONDS=300
$nemohermes <sandbox-name> recover

If the Ollama pull or post-create readiness timeout fires, onboarding emits the elapsed budget plus a hint to raise the relevant variable. The Ollama pull preserves its partial download for the next attempt. The ordinary post-create readiness wait deletes the orphaned sandbox first so the next nemohermes onboard starts without that partially created sandbox.

A post-policy re-registration failure leaves the sandbox in place and reports that OpenShell did not re-register it.

Lifecycle Behavior Flags

The following flags change defaults for commands that manage existing sandboxes.

VariableFormatEffect
NEMOCLAW_CLEANUP_GATEWAY1, true, or yes to enable; 0, false, or no to disableOverrides the platform default (macOS unattended: cleanup; Linux/Windows: preserve) for whether nemohermes <name> destroy removes the shared gateway when destroying the last sandbox. Command-line --cleanup-gateway and --no-cleanup-gateway still take precedence.

| NEMOCLAW_CONFIG_ACCEPT_NEW_PATH | Exactly "1" to opt in (true, yes, on are not accepted) | Allows nemohermes <name> config set to write a dotpath that does not already exist in the sandbox config, without the interactive confirmation. Equivalent to passing --config-accept-new-path, and it takes precedence over NEMOCLAW_NON_INTERACTIVE=1. Without it, a run without a TTY refuses the write instead. | | NEMOCLAW_CONFIRM_LEGACY_MANAGED_RECREATE | JSON array of sandbox names | Confirms to the installer that the listed set of pre-fingerprint OpenClaw or Hermes sandboxes used NemoClaw-managed images, allowing recovery onto the current managed image. The normalized names must exactly match the installer’s printed array. Set it only after verifying every named sandbox. Recorded custom-image evidence remains blocked. | | NEMOCLAW_DISABLE_INFERENCE_ROUTE_REPAIR | 1 to enable | Skips automatic DNS-proxy mutation for stale inference.local routes during nemohermes <name> connect and nemohermes <name> connect --probe-only. The command still probes the route and exits non-zero when the provider-specific requirement fails. An ollama-local route still requires a healthy authenticated proxy and HTTP 2xx from inference.local/v1/models. Use only as a troubleshooting escape hatch. | | NEMOCLAW_DISABLE_SUPERVISOR_RELAUNCH | 1 to enable | Skips the automatic trusted container recreation during nemohermes <name> recover when two managed scans find no supervisor while PID 1 remains stable. Use only as a troubleshooting escape hatch; recovery then falls back to the rebuild or re-onboard guidance. | | NEMOCLAW_SHIELDS_ACCEPT_LEGACY_BASELINE | 1 to opt in | Allows advanced immutable-config verification to trust the current on-disk bytes for older or partial content baselines. Use only after you have rebuilt or manually inspected the sandbox state and accepted that the baseline is operator-approved. | | NEMOCLAW_SHIELDS_SETTLE_MS | positive whole-number milliseconds (default 750, maximum 10000) | NemoClaw waits this long after re-applying a config lockdown before checking that the lock still holds. It applies during ordinary nemohermes <name> shields up transitions, shields auto-restore, and shields up drift remediation. Values above 10000 use 10000. Fractional, zero, negative, blank, and invalid values use the default. If NemoClaw cannot re-confirm the lock within the retry budget, shields stay down. This check narrows the window in which an in-sandbox reconciler can revert permissions; it does not eliminate that window. When the best-effort chattr +i operation succeeds, its immutable bit provides the durable lock. If that operation is unavailable or fails, no durable lock is available. Raise the value on hosts where the gateway settles slowly. | | NEMOCLAW_SKIP_UNREACHABLE_SANDBOX_BACKUP | Exactly 1 to opt in (true, yes, 0 are not accepted) | Applies to standalone nemohermes backup-all runs. Skips running sandboxes whose in-sandbox SSH endpoint does not answer. It does not relax the installer’s strict pre-upgrade backup, which still aborts if any registered sandbox is skipped or fails. Any uncommitted state since the last successful backup is not included in the skipped backup. | | NEMOCLAW_UNINSTALL_ALL_GATEWAY_PORTS | 1 to opt in | Makes nemohermes uninstall remove every gateway port on the host instead of only the port NEMOCLAW_GATEWAY_PORT selects. Equivalent to passing the --all-gateway-ports flag; the whole-host Proceed? confirmation still applies unless --yes is also passed. Each port runs as its own uninstall, and the variable is dropped from those runs so the sweep cannot re-enter itself. | | NEMOCLAW_UNINSTALL_DESTROY_USER_DATA | 1 to opt in | Acknowledges data loss during nemohermes uninstall, skips eligible fresh sandbox backups, and removes the otherwise-preserved entries (rebuild-backups/, backups/, sandboxes.json) in the selected gateway’s state root. It does not select the explicit --destroy-user-data CLI-shim removal path; shim handling follows the ordinary selected-gateway scope. The global Proceed? confirmation still applies unless --yes is also passed. |

Legacy nemohermes setup

Deprecated. Use nemohermes onboard instead. Running nemohermes setup now delegates directly to nemohermes onboard.

$nemohermes setup