Apply Policy Presets

Use policy presets to add reviewed network access to one running sandbox without replacing its current policy. NemoClaw provides the convenient merge and removal commands; OpenShell remains the only durable policy state.

Choose a Maintained Preset

During onboarding, the selected policy tier determines which maintained presets are enabled by default. The interactive preset screen lets you add or remove individual presets. Messaging channel choices are scoped to the active agent, so unsupported channel presets do not appear.

List the presets available to the sandbox:

$
nemoclaw <name> policy list

For the maintained preset catalog and guided service workflows, refer to Common Integration Policy Examples.

Preview and Apply a Preset

Use --dry-run to review the endpoints, rules, and binaries before applying the preset:

$
nemoclaw my-assistant policy add pypi --dry-run
$
nemoclaw my-assistant policy add pypi --yes

Omit the preset name to use the interactive picker:

$
nemoclaw my-assistant policy add

The picker requires a terminal on stdin. A run without a terminal, such as an SSH command without -t, a service unit, or a CI job, exits non-zero and reports that no input is available on stdin.

Pass a preset name with --yes for scripted workflows. Set NEMOCLAW_NON_INTERACTIVE=1 instead of --yes to use the same non-interactive flow through an environment variable. With that variable set, a missing preset name instead reports that non-interactive mode requires a preset name.

Reapply an Edited Preset

Run the same policy add command after you edit a maintained preset or a custom source file. NemoClaw compares the preset with the live policy. If the content differs, it applies the changed content. You do not need to remove the preset first.

The merge starts from the round-trippable base policy returned by openshell policy get --base. It excludes provider-composed _provider_* entries because OpenShell reserves that namespace and rejects it in policy set. Existing presets and baseline entries remain in place.

List and Remove Presets

List available presets and identify which ones match the current OpenShell policy:

$
nemoclaw <name> policy list

Remove a preset when the sandbox no longer needs its access:

$
nemoclaw my-assistant policy remove pypi --yes

policy remove accepts maintained and custom preset names.

OpenShell Is the Source of Truth

policy list derives applied state by comparing preset content with the current OpenShell policy:

$
nemoclaw my-assistant policy list

policy remove reads the live policy, removes the keys defined by the selected preset, writes the complete result, and verifies it:

$
nemoclaw my-assistant policy remove github --yes

When NemoClaw cannot read the OpenShell policy, it refuses the mutation rather than falling back to local policy state.

Understand Persistence

Dynamic changes exist only in the current live OpenShell policy. Maintained preset names are inferred by comparing their current content. Custom presets applied through --from-file or --from-dir use namespaced keys in that same live document so policy list and policy remove can discover them without a second registry.

nemoclaw <name> rebuild and snapshot clone hand the complete current OpenShell policy to sandbox creation. They do not reconstruct it from preset records, so trusted changes made through the OpenShell TUI or another host process are preserved too. For baseline changes that apply to every future sandbox, follow Change the Baseline Network Policy.

Approve One Request

For one-off access, approve a blocked request in the OpenShell TUI:

$
openshell term

Use the TUI to test a destination before deciding whether it belongs in a maintained or custom preset. For the complete approval workflow, refer to Approve or Deny Network Requests.

Related Topics

• Create Custom Policy Presets adds an endpoint that no maintained preset covers.
• Explain Network Policy to Agents summarizes active and missing presets.
• Commands lists every policy command flag.