Description

[Description]
On the “Customize the Sandbox Network Policy” page, the “Static Changes” section mixes instructions for editing the baseline openclaw-sandbox.yaml file with usage of nemoclaw policy-add. The wording implies that policy-add is an alternative way to perform static changes (i.e., edits that persist across sandbox recreation), while in reality policy-add operates on the live policy of a running sandbox. This makes it easy for readers to assume that running policy-add has permanently updated the sandbox’s baseline network policy, when it only affects the current sandbox session unless they also update the YAML or ship a preset file.

[Environment]

• Component: NemoClaw documentation
• Page: “Customize the Sandbox Network Policy”
• Affected sections:
  • “Static Changes → Edit the Policy File”
  • Related references: Network Policy / Presets docs and CLI commands for policy-add, policy-remove, and policy-list.

[Steps to Reproduce]

1. Open the “Customize the Sandbox Network Policy” page in the NemoClaw docs.
2. Scroll to the Static Changes section, under Edit the Policy File.
3. Read the instructions:
   • First, the doc tells you to open and edit nemoclaw-blueprint/policies/openclaw-sandbox.yaml.
   • Immediately after that, it says:

     “If you only need one of the built-in presets, use nemoclaw policy-add instead of editing YAML by hand:
     

     nemoclaw my-assistant policy-add”

     
     

     
     
   • 
     Compare this wording to the CLI/Network Policy documentation, which describes policy-add as:
     
     
     
     • 
       Applying a preset to a running sandbox, by fetching the live policy via openshell policy get --full, merging in the preset’s network_policies, and writing the merged result back with openshell policy set.
     • 
       Not described as an operation that directly edits the baseline openclaw-sandbox.yaml file on disk.
     
     

[Expected Result]

• The Static Changes section should describe only baseline (static) policy modifications, for example:
  • Editing openclaw-sandbox.yaml directly, and/or
  • Merging preset entries into the baseline file, then applying them by re-running nemoclaw onboard or using nemoclaw rebuild so the updated baseline is picked up on sandbox recreation.
• If nemoclaw policy-add is mentioned in this context, the docs should make it explicit that:
  • policy-add modifies the live policy of a running sandbox, not the baseline YAML file.
  • To make a preset-based change static / persistent across sandbox recreation, the corresponding entries must be:
    • Included in openclaw-sandbox.yaml, or
    • Shipped as a preset under policies/presets/ and reapplied on rebuild/onboard.

[Actual Result]

• In Static Changes → Edit the Policy File, the doc:
  1. First instructs the user to edit openclaw-sandbox.yaml.
  2. Then immediately says:

     “If you only need one of the built-in presets, use nemoclaw policy-add instead of editing YAML by hand:
     

     nemoclaw my-assistant policy-add”

     
     

     
     
  3. 
     This presentation suggests that policy-add is simply an alternative to editing YAML by hand to achieve a static change, implying that the preset becomes part of the baseline.
  4. 
     Elsewhere, however, policy-add is described as operating on the running sandbox’s policy via “get live policy → merge preset → set live policy,” with no indication that it writes back to openclaw-sandbox.yaml.
  5. 
     There is no explicit warning in this section that:
     
     
     
     • 
       policy-add alone does not modify openclaw-sandbox.yaml, and
     • 
       Its effects may be lost when the sandbox is stopped or recreated, unless the preset or YAML file is also updated.
     
     

[Impact / Notes]

• This wording can cause operators and QA to believe that running:bash nemoclaw my-assistant policy-add

  has permanently updated the sandbox’s static network policy, when it has only changed the live policy for the current sandbox session.

• 
  The confusion is reinforced by the section title “Static Changes” and the immediate juxtaposition of “edit YAML” and “or use policy-add instead,” without clarifying their different persistence semantics.
• 
  The same page later describes dynamic changes and openshell policy set as session-scoped, but it doesn’t clearly tie policy-add in the Static section back to those dynamic semantics, which can lead to incorrect assumptions about durability.

Suggested Fix:

• In the Static Changes section, either:
  • Remove policy-add from that section entirely and discuss it only under Dynamic Changes, or
  • Explicitly annotate its behavior. For example:

    “To apply a built-in preset to a running sandbox without editing YAML, use nemoclaw policy-add. This updates the sandbox’s live policy only. To make that change static (so it survives sandbox recreation), also include the preset’s entries in openclaw-sandbox.yaml or ship the preset file in policies/presets/ and re-run nemoclaw onboard or nemoclaw rebuild.”

    
    

• Add a short cross-link or callout to the Dynamic Changes and Policy Presets sections so the live-versus-baseline distinction is explicit.

Bug Details

[NVB#6188952]