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:

console

$ 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:

console

$ nemoclaw <name> status

Add Blueprint Policy Additions

If you maintain a custom blueprint, you can add extra policy entries under

components.policy.additions

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.

Create a preset-format YAML file under

nemoclaw-blueprint/policies/presets/

, for example

nemoclaw-blueprint/policies/presets/influxdb.yaml

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 }

Apply it to the running sandbox:
console
```
$ 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.

console

$ 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:

console

$ 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:

console

$ 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 (use the

nemoclaw-user-manage-policy

skill).

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
`outlook`	Microsoft 365 and Outlook
`pypi`	Python Package Index
`slack`	Slack API and webhooks
`telegram`	Telegram Bot API
`whatsapp`	WhatsApp Web messaging

To apply a preset to a running sandbox:

console

$ 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:

console

$ nemoclaw my-assistant policy-add

To list which presets are applied to a sandbox:

console

$ 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:

console

$ 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/

yaml

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

pypi

. Rename

preset.name

if NemoClaw refuses to apply the file because of a collision.

Apply a Single File

console

$ 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

console

$ 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.

Remove a Custom Preset

Custom presets applied with

--from-file

--from-dir

are recorded in the NemoClaw sandbox registry alongside their full YAML content, so they can be removed by name — the original file does not need to be kept on disk:

console

$ nemoclaw my-assistant policy-remove my-internal-api --yes

policy-remove

accepts both built-in and custom preset names. Run

nemoclaw <name> policy-list

to see every preset currently applied to the sandbox.

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.

Related Skills

```
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.

nemoclaw-user-manage-policy

NPX Install

Tags

SKILL.md Content

Customize the Sandbox Network Policy

Gotchas

Prerequisites

Static Changes

Edit the Policy File

Re-Run Onboard

Verify the Policy

Add Blueprint Policy Additions

Dynamic Changes

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

Option 2: Snapshot, Edit, and Set via OpenShell

Scope of Dynamic Changes

Approve Requests Interactively

Policy Presets

Custom Preset Files

Authoring

Apply a Single File

Apply Every File in a Directory

Remove a Custom Preset

References

Related Skills