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.
Shields up keeps /sandbox/.hermes/profiles/dashboard-home/ sandbox-owned at mode 0700 so the dashboard can update its isolated profile.
Other Hermes profiles remain read-only during lockdown.
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 gateway recovery, 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.
Restore Lockdown After Expiration
If the timeout expires while a mutation is changing sandbox state, auto-restore closes the per-sandbox lifecycle deadline gate. The gate blocks new mutations and waits for the recorded live owner to release its exact lock generation. NemoClaw does not signal that process because portable process inspection cannot prove that all descendants stopped. After the owner releases the lock, auto-restore restores the restrictive policy and configuration posture. The ownership check includes both the process ID and process start identity so PID reuse does not grant control over an unrelated process.
Complete Exact-Generation Recovery
An interactive command can take over an expired timer. Interactive recovery has separate transition-takeover and restoration phases. Each phase makes up to 7 attempts and waits 5 seconds between failures, for up to 30 seconds of retry delay per phase. Detached recovery uses one 7-attempt budget across deadline setup, main-generation publication, and restoration. The deadline gate remains closed during those attempts.
If restoration cannot commit, NemoClaw attempts to record durable containment.
If that containment commit also fails, NemoClaw retains any exact lifecycle and deadline gates it already owns.
A state-directory failure that prevented gate publication also prevents normal mutation-lock acquisition.
Correct the reported state-directory write failure, then run nemohermes <name> shields status to resume recovery or receive exact-generation recovery guidance.
When recovery cannot complete, an interactive command returns an error, or the detached timer exits with a failure status.
NemoClaw also records durable containment when an owner exits before it can prove that the owner’s descendants stopped, or when ownership becomes ambiguous. Durable containment, retained exact gates, or the fail-closed state-directory error keeps new mutations blocked until you complete exact-generation operator recovery.
Stop all NemoClaw processes for the sandbox, then follow the paths, identities, tokens, and removal order in the reported error. Verify each recorded generation is unchanged, remove only the exact stale generations first, and remove the exact containment generation last.
Preserve Managed MCP Policy
Before a manual Shields transition replaces a policy, NemoClaw requires exact Model Context Protocol (MCP) agreement among the sandbox registry, generated-policy record, and live gateway policy.
shields down carries the proven managed MCP policy entries into the relaxed policy.
Restoration removes snapshot-time managed MCP entries before it overlays current exact entries.
If exact agreement is absent, a manual Shields transition refuses the replacement policy.
At an expired deadline, auto-restore omits unproven managed MCP policy entries, restores lockdown, and records the omission count in its audit entry. An MCP server removed during the shields-down window stays removed. A surviving server keeps its recorded endpoint and address pins while its policy ownership remains exact.
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.