Understand Runtime Changes
Use this matrix to choose the operation that makes a sandbox change take effect. NemoClaw applies its security posture in three layers: what onboarding writes into the sandbox image, what the running sandbox can hot-reload, and what requires a rebuild or re-onboard.
Hermes Runtime Changes
The runtime source of truth is /sandbox/.hermes/config.yaml plus /sandbox/.hermes/.env.
The host registry caches metadata, but the image and Hermes runtime read from the in-sandbox files.
Do not edit those files or their hash files directly and then expect gateway restart to establish the bytes as trusted.
Use supported host config and inference commands so NemoClaw updates the managed config metadata together.
Hermes host-side config writes run as a sealed transaction. NemoClaw binds the write to the SHA-256 digest of the matching read, temporarily seals the mutable config paths, atomically installs fresh config inodes, refreshes the strict and compatibility hashes, and then restores the prior shields posture.
shields up also publishes fresh config, environment, and compatibility-hash inodes so a descriptor opened before lockdown cannot retain write authority.
The same root-only mutation lock stays held through Hermes config writes, the full shields up or shields down filesystem transition and verification, and lifecycle recovery that needs to seal those paths.
If another host mutation is active, the command reports Hermes config mutation is already in progress.
If another lifecycle request owns the supervisor, it reports SUPERVISOR_BUSY.
Both errors are retryable.
Let the active command finish, then retry instead of editing lock or seal files manually.
Hermes config and inference changes are refused while shields are up.
Run nemohermes <name> shields down before the change, then restore lockdown with nemohermes <name> shields up.
Timed Shields Windows
NemoClaw serializes host-side config and inference writes, snapshot mutation, sandbox destruction, and shields transitions for each sandbox.
When shields down --timeout is active, each mutation binds to that exact timer generation so a replaced or expired timer cannot race a later command or a new sandbox that reuses the same name.
If the timeout expires while a mutation is still changing sandbox state, auto-restore can stop that exact process tree, reclaim the transition, and restore the restrictive policy and config posture. The ownership check includes both the process ID and process start identity so PID reuse does not grant control over an unrelated process.
Retry a command that the auto-restore deadline interrupts after you open a new shields-down window.
Related Topics
- Understand Gateway Lifecycle Control for
recoverandgateway restarttrust boundaries. - Recover and Rebuild Sandboxes for the operational recovery workflow.
- Switch Inference Providers for model and provider changes.
- Customize Network Policy for runtime policy editing.
- Security Best Practices for the broader security posture.
- CLI Commands Reference for command flags and environment variables.