> For clean Markdown of any page, append .md to the page URL. > For a complete documentation index, see https://docs.nvidia.com/nemoclaw/llms.txt. > For full documentation content, see https://docs.nvidia.com/nemoclaw/llms-full.txt. > For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs.nvidia.com/nemoclaw/_mcp/server. # Customize the Sandbox Network Policy > Add, remove, or modify allowed endpoints in the sandbox policy. 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](https://github.com/NVIDIA/OpenShell). NemoClaw supports both static policy changes that persist across restarts and dynamic updates applied to a running sandbox through the OpenShell CLI. 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 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](/reference/troubleshooting#agent-cannot-reach-a-host-side-http-service). ## Prerequisites * A running NemoClaw sandbox for dynamic changes, or the NemoClaw source repository for static changes. * The OpenShell CLI on your `PATH`. > \[!IMPORTANT] > Make static policy edits on the host, not inside the sandbox. > The sandbox image includes a small set of operational tools such as `vi`, `jq`, and `dos2unix`, but host-side policy files remain the durable source of truth. > Changes made only inside the sandbox are also ephemeral and are lost when the sandbox is recreated. ## 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 policy-add` under [Dynamic Changes](#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 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`: ```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: ```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](/network-policy/integration-policy-examples). During onboarding, the [policy tier](/reference/network-policies#policy-tiers) 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 | | `wechat` | WeChat messaging | | `whatsapp` | WhatsApp Web messaging | To apply a preset to a running sandbox: ```console $ nemoclaw policy-add ``` 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 policy-list ``` To include a preset in the baseline, merge its entries into `openclaw-sandbox.yaml` and re-run `nemoclaw onboard`. The `openshell policy set --policy ` command operates on raw policy files and does not accept the `preset:` metadata block used in preset YAML files. Use `nemoclaw 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](/reference/commands#nemoclaw-name-policy-add) for the full flag reference. `nemoclaw 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` or `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. 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` or `--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 policy-list` to see every preset currently applied to the sandbox. ## Related Topics * [Approve or Deny Agent Network Requests](/network-policy/approve-network-requests) for real-time operator approval. * [Common Integration Policy Examples](/network-policy/integration-policy-examples) for maintained preset examples such as Outlook, messaging, GitHub, Jira, Brave Search, package managers, Hugging Face, and local inference. * [Network Policies](/reference/network-policies) for the full baseline policy reference. * OpenShell [Policy Schema](https://docs.nvidia.com/openshell/latest/reference/policy-schema.html) for the full YAML policy schema reference. * OpenShell [Sandbox Policies](https://docs.nvidia.com/openshell/latest/sandboxes/policies.html) for applying, iterating, and debugging policies at the OpenShell layer.