Description

Description

On NemoClaw v0.0.36, `nemohermes  shields down` (and equivalently

`nemoclaw  shields down --policy permissive` on any Hermes-agent

sandbox) always fails with:



  × status: InvalidArgument, message: "filesystem read_only path '/opt/hermes'

    cannot be removed on a live sandbox"



The shields-down workflow — used for diagnostics, plugin install, and

permissive-mode workflows — is completely broken for every Hermes user.

`shields up` and `shields status` still work; only the temporary-unlock

path is unavailable. There is no user-side workaround because the

hardcoded path lives in compiled dist code.



Root cause is in `dist/lib/shields.js:586`, which uses the hardcoded

constant `PERMISSIVE_POLICY_PATH` (the OpenClaw permissive YAML)

instead of calling the agent-aware helper `resolvePermissivePolicyPath

(sandboxName)` that already exists at `dist/lib/policies.js:838`.

OpenClaw's permissive YAML omits `/opt/hermes` from `read_only`, while

Hermes' default policy includes it; OpenShell rejects `read_only`

removals on a live sandbox and the operation aborts.

Environment

Device:        Linux test box (10.176.181.181)

OS:            Linux x86_64

Docker:        29.1.3

OpenShell CLI: 0.0.36

NemoClaw:      v0.0.36

NemoHermes:    v0.0.36

Hermes Agent:  v0.11.0 (2026.4.23)

Date verified: 2026-05-07

Steps to Reproduce

1. Onboard a Hermes sandbox:

     nemohermes onboard --agent hermes

   (or use any pre-existing Hermes sandbox; this bug reproduces on any

    Hermes sandbox in Phase=Ready, Shields=UP)

2. Confirm baseline state:

     nemohermes hermes shields status

   → "Shields: UP (lockdown active) / Policy: restrictive"

3. Attempt to lower shields:

     nemohermes hermes shields down --reason "repro" --timeout 5m

4. (Equivalent path, also fails) Try with explicit policy flag:

     nemohermes hermes shields down --policy permissive --reason "repro" --timeout 5m

Expected Result

Step 3:

  Capturing current policy snapshot...

  Saved: ~/.nemoclaw/state/policy-snapshot-.yaml

  Applying permissive policy...

  ✓ Policy version N submitted (hash: ...)

  ✓ Policy version N loaded (active version: N)

  Unlocking hermes config (/sandbox/.hermes/config.yaml)...

  Config unlocked for hermes (auto-lockdown in: 5m)



  Sandbox is in default (mutable) state.

  Run `nemohermes hermes shields up` to opt into lockdown.



Followed by:

  nemohermes hermes shields status

  → "Shields: DOWN (temporarily unlocked) / Policy: permissive"



Step 4 should produce the same successful output.

Actual Result

Step 3 (and step 4 identical):

  Capturing current policy snapshot...

  Saved: ~/.nemoclaw/state/policy-snapshot-1778139795307.yaml

  Applying permissive policy...

Error:   × status: InvalidArgument, message: "filesystem read_only path '/opt/hermes'

  │ cannot be removed on a live sandbox", details: [], metadata: MetadataMap

  │ { headers: {"content-type": "application/grpc", "date": "Thu, 07 May 2026

  │ 07:43:15 GMT"} }



  Command failed (exit 1): openshell policy set --policy

  /localhome/local-glennz/.nemoclaw/source/nemoclaw-blueprint/policies/openclaw-sandbox-permissive.yaml

  This error originated from the OpenShell runtime layer.

  Docs: https://github.com/NVIDIA/OpenShell



After the failed call, shields state remains "UP / restrictive".



Note the exact path in the failed openshell call:

  nemoclaw-blueprint/policies/openclaw-sandbox-permissive.yaml

This is OpenClaw's permissive policy. The file

  agents/hermes/policy-permissive.yaml

exists, has the correct read_only set (including /opt/hermes), but is

never selected.

Impact

P1 — All NemoHermes users on v0.0.36 cannot use `shields down` at all;

the entire temporary-unlock / permissive-mode workflow (documented for

diagnostics and plugin installation on Hermes) is unavailable. There is

no user-side workaround because the hardcoded path is in compiled dist

code. Recommend release-blocker for v0.0.37.

Bug Details

[NVB#6154495]