Nemoclaw User Manage Policy

Customize the Sandbox Network Policy

Gotchas

• Custom preset hosts bypass NemoClaw's review process and can widen sandbox egress to arbitrary destinations.

Prerequisites

• A running NemoClaw sandbox for dynamic changes, or the NemoClaw source repository for static changes.
• The OpenShell CLI on your PATH.

Add, remove, or modify the endpoints that the sandbox is allowed to reach.

The sandbox policy is defined in a declarative YAML file in the NemoClaw repository and enforced at runtime by NVIDIA OpenShell. NemoClaw supports both static policy changes that persist across restarts and dynamic updates applied to a running sandbox through the OpenShell CLI.

Note:

If the sandbox needs to reach an HTTP service running on the host, expose the service on a host IP that the OpenShell gateway can reach. Apply a custom NemoClaw preset with nemoclaw <sandbox> policy-add --from-file. Do not rely on host.docker.internal as a general host-service path because it bypasses the OpenShell policy path and may not be reachable in every sandbox runtime. See Agent cannot reach a host-side HTTP service (use the nemoclaw-user-reference skill).

Static Changes

Static changes modify the baseline policy file and take effect after the next sandbox creation.

Edit the Policy File

Open nemoclaw-blueprint/policies/openclaw-sandbox.yaml and add or modify endpoint entries.

If you want a built-in preset to be part of the baseline policy, merge its network_policies entries into this file and re-run nemoclaw onboard.

If you only need to apply a preset to a running sandbox, use nemoclaw <name> policy-add under Dynamic Changes. That updates the live policy and does not edit openclaw-sandbox.yaml.

Use a manual YAML edit when you need to allow custom hosts that are not covered by a preset, such as an internal API or a weather service.

Each entry in the network section defines an endpoint group with the following fields:

endpoints : Host and port pairs that the sandbox can reach.

binaries : Executables allowed to use this endpoint.

rules : HTTP methods and paths that are permitted.

Re-Run Onboard

Apply the updated policy by re-running the onboard wizard:

$ nemoclaw onboard

The wizard picks up the modified policy file and applies it to the sandbox.

Verify the Policy

Check that the sandbox is running with the updated policy:

$ nemoclaw <name> status

Add Blueprint Policy Additions

If you maintain a custom blueprint, you can add extra policy entries under components.policy.additions in nemoclaw-blueprint/blueprint.yaml. NemoClaw validates those entries with the same policy schema used by preset files, fetches the live policy during sandbox creation, merges the additions into network_policies, and applies the merged policy through OpenShell. The applied additions are recorded in the run metadata so you can audit which blueprint-level policy entries were active for that sandbox run.

Dynamic Changes

Dynamic changes apply a policy update to a running sandbox without restarting it.

[!WARNING] openshell policy set replaces the sandbox's live policy with the contents of the file you provide; it does not merge. A running sandbox's live policy is the baseline from openclaw-sandbox.yaml plus every preset that was layered on during onboarding. Applying a file that contains only the baseline (or only a single preset) silently drops every other preset that was in effect.

Option 1: Drop a Preset File and Use policy-add (Recommended)

This is the non-destructive path and the only flow NemoClaw supports out of the box for merging new entries into a running policy.

1. Create a preset-format YAML file under nemoclaw-blueprint/policies/presets/, for example nemoclaw-blueprint/policies/presets/influxdb.yaml:

   preset:
     name: influxdb
     description: "InfluxDB time-series database"
   network_policies:
     influxdb:
       name: influxdb
       endpoints:
         - host: influxdb.internal.example.com
           port: 8086
           protocol: rest
           enforcement: enforce
           rules:
             - allow: { method: GET, path: "/**" }
             - allow: { method: POST, path: "/api/v2/write" }
       binaries:
         - { path: /usr/bin/curl }
   

2. Apply it to the running sandbox:

   $ nemoclaw my-assistant policy-add
   

   NemoClaw reads the live policy via openshell policy get --full, structurally merges your preset's network_policies into it, and writes the merged result back. Existing presets and the baseline remain in place. The preset file under presets/ also persists across sandbox recreations.

Option 2: Snapshot, Edit, and Set via OpenShell

Use this path only when you cannot add a file under the NemoClaw source tree. You must start from the live policy, not from openclaw-sandbox.yaml, so the presets layered on at onboarding are preserved in the file you apply.

$ openshell policy get --full my-assistant > live-policy.yaml

Edit live-policy.yaml to add your entries under network_policies:, keeping the existing version field intact, then apply:

$ openshell policy set --policy live-policy.yaml my-assistant

Scope of Dynamic Changes

Dynamic changes apply only to the current session. When the sandbox stops, the running policy resets to the baseline composed from openclaw-sandbox.yaml plus the presets recorded for the sandbox. To make a custom policy survive a sandbox recreation, ship the preset file in the repository (Option 1 above — the file under presets/ persists) or edit openclaw-sandbox.yaml and re-run nemoclaw onboard.

Approve Requests Interactively

For one-off access, you can approve blocked requests in the OpenShell TUI instead of editing the baseline policy:

$ openshell term

This is useful when you want to test a destination before deciding whether it belongs in a permanent preset or custom policy file.

Policy Presets

NemoClaw ships preset policy files for common integrations in nemoclaw-blueprint/policies/presets/. Apply a preset as-is or use it as a starting template for a custom policy. For guided post-install examples, see Common Integration Policy Examples.

During onboarding, the policy tier (use the nemoclaw-user-reference skill) you select determines which presets are enabled by default. You can add or remove individual presets in the interactive preset screen that follows tier selection.

Available presets:

Preset	Endpoints
brave	Brave Search API
brew	Homebrew (Linuxbrew) package manager
discord	Discord API, gateway, and CDN access
github	GitHub and GitHub REST API
huggingface	Hugging Face Hub (download-only) and inference router
jira	Atlassian Jira API
local-inference	Local Ollama and vLLM through the host gateway
npm	npm and Yarn registries
openclaw-pricing	OpenClaw model-pricing reference fetch (LiteLLM and OpenRouter)
outlook	Microsoft 365 and Outlook
pypi	Python Package Index
slack	Slack API and webhooks
telegram	Telegram Bot API
wechat	WeChat (personal) iLink Bot API (experimental)
whatsapp	WhatsApp Web messaging (experimental)

To apply a preset to a running sandbox:

$ nemoclaw <name> policy-add

Note:

Preset selection is interactive when you omit a preset name. Pass a preset name with --yes for scripted workflows.

For example, to interactively add PyPI access to a running sandbox:

$ nemoclaw my-assistant policy-add

To list which presets are applied to a sandbox:

$ nemoclaw <name> policy-list

To include a preset in the baseline, merge its entries into openclaw-sandbox.yaml and re-run nemoclaw onboard.

Note:

The openshell policy set --policy <file> <sandbox-name> command operates on raw policy files and does not accept the preset: metadata block used in preset YAML files. Use nemoclaw <name> policy-add for presets.

For scripted workflows, policy-add and policy-remove accept the preset name as a positional argument:

$ nemoclaw my-assistant policy-add pypi --yes
$ nemoclaw my-assistant policy-remove pypi --yes

Set NEMOCLAW_NON_INTERACTIVE=1 instead of --yes to drive the same flow from an environment variable. See Commands (use the nemoclaw-user-reference skill) for the full flag reference.

nemoclaw <name> rebuild reapplies every policy preset to the recreated sandbox, so presets survive an agent-version upgrade without manual reapplication.

Custom Preset Files

Apply a user-authored preset YAML to a running sandbox without editing the baseline or dropping to openshell policy set.

Authoring

A custom preset follows the same shape as the built-in ones under nemoclaw-blueprint/policies/presets/:

preset:
  name: my-internal-api
  description: "Internal service"
network_policies:
  my-internal-api:
    name: my-internal-api
    endpoints:
      - host: api.example.internal
        port: 443
        protocol: rest
        enforcement: enforce
        rules:
          - allow: { method: GET, path: "/**" }
    binaries:
      - { path: /usr/local/bin/node }

The top-level preset.name must be a lowercase RFC 1123 label (letters, digits, hyphens) and must not collide with a built-in preset name such as slack or pypi. Rename preset.name if NemoClaw refuses to apply the file because of a collision.

Apply a Single File

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

Preview the endpoints without applying with --dry-run, and skip the confirmation prompt with --yes or by exporting NEMOCLAW_NON_INTERACTIVE=1.

Apply Every File in a Directory

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

Files are processed in lexicographic order. Processing stops at the first failure; presets already applied are not rolled back. Fix the failing file and re-run the command to continue.

Warning:

Custom preset hosts bypass NemoClaw's review process and can widen sandbox egress to arbitrary destinations. Review every host in a custom preset before applying it, especially when the file originates outside your team.

Load references/customize-network-policy-details.md for detailed steps on Remove a Custom Preset.

References

• references/integration-policy-examples.md — Guides users through common post-install integration policy setup for maintained NemoClaw policy presets, including Outlook, messaging channels, GitHub, Jira, Brave Search, package managers, Hugging Face, local inference, and OpenShell approval workflows.
• Load references/approve-network-requests.md when approving or denying sandbox egress requests, managing blocked network calls, or using the approval TUI. Reviews and approves blocked agent network requests in the TUI.
• Load references/customize-network-policy-details.md when you need detailed steps for Remove a Custom Preset.

Related Skills

• Approve or Deny Agent Network Requests for real-time operator approval.
• Common Integration Policy Examples for maintained preset examples such as Outlook, messaging, GitHub, Jira, Brave Search, package managers, Hugging Face, and local inference.
• nemoclaw-user-reference — Network Policies (use the nemoclaw-user-reference skill) for the full baseline policy reference
• OpenShell Policy Schema for the full YAML policy schema reference.
• OpenShell Sandbox Policies for applying, iterating, and debugging policies at the OpenShell layer.