Host Files and State | NVIDIA NemoClaw

NemoClaw stores most host-side configuration, registry metadata, operational state, transient install state, and local backups under ~/.nemoclaw/. Some lifecycle journals live under ~/.local/state/ so they remain available when an operation removes a selected state root. Managed local inference profiles also use the cache paths listed on this page. Use this page when you need to identify what a file does before deleting, backing up, or sharing diagnostics.

The default gateway stores managed llama.cpp state under ~/.nemoclaw/managed-llama-cpp/. A non-default gateway port stores the same files under ~/.nemoclaw/gateways/<port>/managed-llama-cpp/. For the rows below, <selected-state-root> is ~/.nemoclaw/ for port 8080 or ~/.nemoclaw/gateways/<port>/ for another port.

Do not paste a legacy credentials.json, provider tokens, bot tokens, proxy tokens, local inference API keys, or debug archives containing them into chat or issue comments. Share redacted diagnostics only.

Files

Path	Purpose	Safe to delete
`~/.nemoclaw/config.json`	Host-level CLI configuration and defaults created by onboarding or config commands.	Only if you want NemoClaw to forget host defaults and rebuild them on the next setup.
`~/.nemoclaw/credentials.json`	Legacy plaintext credential file from earlier releases. Onboarding stages allowlisted values and registers them with the OpenShell gateway. After verified migration, it removes only unchanged migrated entries and preserves all others. It securely deletes the file when no entries remain. See Credential Storage for retained-file and empty-file cleanup behavior.	No; run `nemoclaw onboard` to complete migration and cleanup so you do not lose a credential that is not yet registered with the gateway.
`~/.nemoclaw/sandboxes.json`	Current sandbox registry used by `nemoclaw list`, default sandbox selection, rebuild, and recovery commands. See Malformed Registry File when a command reports that this file is not valid JSON.	No. Deleting it makes the host forget existing sandboxes and can block state-preserving recovery.
`<selected-state-root>/onboard-session.json`	Active onboarding session or rebuild recovery journal. Other sandboxes’ interrupted rebuilds can be retained separately. It can contain secret-free external component activation evidence bound to the sandbox identity fingerprint and lifecycle generation.	Do not delete it to resolve an interrupted rebuild. For an ordinary failed onboarding attempt, prefer `nemoclaw onboard --fresh` when `externalComponentActivation` is absent. If that field is present, preserve the file, sandbox registry, and sandbox for an identity-verified recovery decision. Version 1 does not support resume or recovery for that activation state.
`<selected-state-root>/.onboard-rebuild-<sandbox>.json`	Retained rebuild session for one sandbox. NemoClaw restores it to the active session when that sandbox rebuilds.	No. Rerun `nemoclaw <sandbox> rebuild` with the same settings and preserve the recovery files.
`~/.nemoclaw/gateways/<port>/automatic-gateway-port.pending`	Owner-only identity for an installer-selected alternate port whose onboarding is deferred or incomplete. When `NEMOCLAW_GATEWAY_PORT` is unset, the installer and CLI use this port so later or resumed onboarding and cleanup stay in the same state root. Successful installer-driven or direct CLI onboarding promotes it to `automatic-gateway-port`.	Preserve a valid marker; ordinary cleanup must use the reported gateway-scoped uninstall guidance. Fresh onboarding retains this automatic port and promotes it on success. If the resolver specifically reports an invalid automatic marker, inspect and remove only that invalid marker, or set `NEMOCLAW_GATEWAY_PORT` explicitly to target another environment.
`~/.nemoclaw/gateways/<port>/automatic-gateway-port`	Owner-only completed identity for an installer-selected alternate port. When `NEMOCLAW_GATEWAY_PORT` is unset, later installer and CLI processes restore this port instead of using `8080`.	Preserve a valid marker; uninstalling this gateway removes it with the port-scoped state. If the resolver specifically reports an invalid automatic marker, inspect and remove only that invalid marker, or set `NEMOCLAW_GATEWAY_PORT` explicitly to target another environment.
`~/.nemoclaw/usage-notice.json`	Records the third-party software notice version in `acceptedVersion` and the acceptance time in `acceptedAt`. Install, onboarding, and rebuild flows consult this file and prompt again when its recorded version differs from the current notice or the file is absent.	Yes; deleting it makes the next applicable install, onboarding, or rebuild flow prompt for acceptance again.
`<selected-state-root>/bedrock-runtime-adapter.pid`	Mode-`0600` canonical PID for the selected gateway’s host-local Amazon Bedrock Runtime adapter. Uninstall correlates it with the lifecycle state and journal before it signals a process.	No while the adapter or an unfinished uninstall journal exists. Uninstall retires it only after it proves the recorded process is absent.
`<selected-state-root>/bedrock-runtime-adapter-token`	Mode-`0600` local bearer token that authenticates requests to the selected gateway’s Amazon Bedrock Runtime adapter. This token is separate from the upstream AWS credential held by the adapter process.	No while the adapter or an unfinished uninstall journal exists. Uninstall removes it only after process absence and lifecycle generation match the journal.
`<selected-state-root>/bedrock-runtime-adapter.json`	Mode-`0600` lifecycle state that binds the adapter generation, canonical PID, process start identity, current user, executable and launcher paths, adapter port, and token hash. It does not contain the bearer token.	No while the adapter or an unfinished uninstall journal exists. Keep it for fail-closed uninstall recovery.
`~/.local/state/nemoclaw-bedrock-runtime-adapter/<gateway-port>/uninstall.json`	Mode-`0600` per-gateway phase journal for Amazon Bedrock adapter cleanup. It remains outside the selected state root so an interrupted uninstall can resume the generation. Onboarding refuses to start another generation while this journal remains unfinished.	No. Rerun uninstall with the same gateway port and let successful cleanup retire the journal.
`~/.nemoclaw/ollama-proxy-token`	Host-global auth token used by the host-side Ollama auth proxy. Every gateway port on the host uses this one file.	Yes, but rerun onboarding for every gateway port that uses Local Ollama afterward, because a new token invalidates the shared proxy for all of them.
`~/.nemoclaw/ollama-backend`	Host-global legacy route URL used to restart the Ollama auth proxy and retained for compatibility with earlier releases.	No while any gateway uses the shared proxy. Rerun onboarding if this file is missing or damaged.
`~/.nemoclaw/ollama-backend.json`	Mode-`0600`, versioned descriptor that identifies whether the matching legacy route fronts Ollama or a compatible endpoint. Recovery trusts its kind only when both files contain the same URL.	Yes, but recovery uses neutral remediation until onboarding recreates the descriptor.
`~/.nemoclaw/ollama-proxy-port`	Host-global port used by the Ollama auth proxy and every Local Ollama sandbox route on the host. A command with a different `NEMOCLAW_OLLAMA_PROXY_PORT` stops before changing the shared proxy.	No while any gateway uses Local Ollama. Full uninstall uses this file to find the proxy and removes it with the other shared proxy state.
`~/.nemoclaw/dual-station-vllm-api-key`	Owner-only host-global bearer API key shared by authenticated NemoClaw-managed vLLM profiles.	No while a managed vLLM runtime uses it. An eligible `destroy` removes it only after the authenticated single-host container is removed or confirmed absent and no registered `vllm-local` consumer remains. Preservation options and distributed ownership keep it. Full uninstall removes it only after matching runtime cleanup succeeds and no sibling gateway remains.
`~/.nemoclaw/host-local-vllm-runtime.json`	Owner-only, credential-free receipt for a catalog-selected single-host vLLM runtime. It binds the immutable catalog, preset, and recipe digests to the container ID and API-key fingerprint.	No while that runtime exists. Recovery, destroy, and full uninstall fail closed if its profile labels do not match this receipt, and destroy or uninstall removes it only after container cleanup succeeds.
`~/.nemoclaw/host-local-vllm-pending-retirement.json`	Owner-only, credential-free record of one eligible `vllm-local` sandbox name whose managed `nemoclaw-vllm` retirement is pending. Written before registry removal; a later eligible `destroy` replaces it.	No while retirement is pending. After registry removal, preserve it for a `destroy` retry with the same sandbox name. A settled retry clears the record, including when another `vllm-local` consumer remains, a distributed receipt owns the runtime, or `--keep-vllm` is requested. Full uninstall removes it with the other host-global state.
`~/.nemoclaw/managed-llama-cpp/api-key`	Owner-only bearer API key mounted read-only into the managed llama.cpp container. It is absent from process arguments, logs, receipts, sandbox registry state, and status output.	No while the managed llama.cpp runtime exists. A retry reuses the same key. Destroy or full uninstall removes it only after runtime cleanup succeeds.
`~/.nemoclaw/managed-llama-cpp/owner.json`	Owner-only, credential-free binding from one gateway to the sandbox, recipe, catalog digest, preset digest, and recipe digest that owns the managed llama.cpp runtime.	No while the managed llama.cpp runtime exists. Destroy or full uninstall removes it only after cleanup succeeds.
`~/.nemoclaw/managed-llama-cpp/receipt.json`	Owner-only runtime receipt that binds the Docker authority, container ID, network, image digest, model identity, and lifecycle generation. It contains no API key.	No while the managed llama.cpp runtime exists. Recovery and cleanup use it and preserve it when ownership cannot be proved.
`~/.nemoclaw/managed-llama-cpp/runtime-provider-authority/host-local-inference.json`	Owner-only, credential-free, write-once Docker endpoint and binding authority used to prove that resume and cleanup address the same container engine.	No while managed llama.cpp ownership exists. Recovery fails closed without this authority record.
`~/.nemoclaw/managed-llama-cpp/host-local-create-journal/`	Owner-only crash-recovery records for the managed llama.cpp create transaction. A retry reconciles an unfinished record before it starts another runtime.	No while managed llama.cpp ownership exists. Destroy or full uninstall removes it only after cleanup succeeds.
`~/.nemoclaw/managed-cluster-vllm-runtime.json`	Owner-only host-global managed-cluster cleanup receipt. It contains no serving API key and binds the plan, ranked nodes, containers, and temporary discovery-claim identities.	No while the managed cluster exists. Full uninstall removes it after every container is removed.
`~/.nemoclaw/managed-cluster-vllm-runtime.json.rank-<rank>.ssh-binding/`	Owner-only copied SSH host-key and Docker-command binding needed to reach one recorded worker rank during full uninstall.	No while the managed cluster exists. Full uninstall removes every rank binding with the cleanup receipt after cluster cleanup succeeds.
`~/.nemoclaw/managed-cluster-managed-serving.json.<node-id>.ssh-binding/`	Owner-only host-global temporary SSH host-key and Docker-command claim written for one peer after setup confirmation and repeated topology qualification. Each claim is distinct from its durable runtime binding and applies to every gateway on the host.	Only after confirming that no setup transaction is active. Without a durable runtime receipt, an orphaned claim makes a new managed-vLLM install and full uninstall fail closed without mutation. With the matching host-global managed-cluster receipt, full uninstall retires every recorded claim after it removes every container. If claim retirement fails, it preserves the receipt for a retry. Gateway-scoped uninstall preserves each claim.
`~/.nemoclaw/dual-station-vllm-runtime.json`	Owner-only host-global managed dual-Station cleanup receipt. It contains no serving API key and binds the peer, cluster, and GPU identities used to revalidate and remove both managed vLLM containers during full uninstall.	No while the managed pair exists. A full `nemoclaw uninstall` removes the receipt after both containers are removed; gateway-scoped uninstall preserves it.
`~/.nemoclaw/dual-station-vllm-runtime.json.ssh-binding/`	Owner-only host-global copied SSH host-key and Docker-command binding needed to reach the recorded worker during full uninstall.	No while the managed pair exists. Full uninstall removes it with the cleanup receipt after pair cleanup succeeds; gateway-scoped uninstall preserves it.

Earlier releases can store the dual-Station runtime receipt and its SSH-binding directory under ~/.nemoclaw/gateways/<port>/ when the managed pair was created from a non-default gateway port. The API key remains host-global at ~/.nemoclaw/dual-station-vllm-api-key. Current releases discover and validate the legacy receipt location without moving or duplicating its ownership state. Do not move these files or directories manually.

sandboxes.json is the current registry file name. If you see registry.json in older tests, notes, or discussions, treat it as legacy wording for the sandbox registry unless a specific release note says otherwise.

Malformed Registry File

A sandboxes.json file that is present but does not contain valid JSON stops registry operations that require complete sandbox records, such as nemoclaw list and nemoclaw onboard. NemoClaw reports the file path and the recovery commands instead of reading the file as an empty registry. These operations cannot replace your sandbox records with empty state. Optional messaging health checks omit registry-derived information when they cannot read the registry. NemoClaw does not rename, move, or rewrite the file.

Removing sandboxes.json makes the host forget its registered sandboxes. Keep the copy until those sandboxes are registered again.

Copy the file, then remove it:

cp ~/.nemoclaw/sandboxes.json ~/.nemoclaw/sandboxes.json.bad
rm ~/.nemoclaw/sandboxes.json

On a non-default gateway port, use the matching ~/.nemoclaw/gateways/<port>/sandboxes.json path. Run the command again. Run nemoclaw onboard to register a sandbox again.

Directories

Path	Purpose	Safe to delete
`~/.nemoclaw/state/`	Operational coordination for lifecycle locks, local routing, and port-forward helpers.	No. Deleting it can disrupt an active operation and discard recovery context.
`~/.nemoclaw/snapshots/`	Legacy copies of host `~/.openclaw` state and configured external roots. Current releases do not create or restore these snapshots.	Only after you no longer need the legacy copy. The host CLI does not expose the direct runner’s retention actions.
`~/.nemoclaw/rebuild-backups/`	Host-side snapshots written by `backup-all`, `snapshot create`, and rebuild flows.	Only after you no longer need rollback or restore points.
`~/.nemoclaw/backups/`	Workspace backups written by legacy backup helpers and some recovery flows.	Only after confirming you no longer need those workspace archives.
`~/.nemoclaw/mounts/`	Default local mount points created by share or mount commands.	Unmount first, then remove unused directories.
`~/.nemoclaw/blueprints/`	Cached blueprint inputs used by onboarding and sandbox recreation.	Avoid manual deletion unless you plan to rerun onboarding from fresh inputs.
`~/.cache/huggingface/`	Shared Hugging Face cache used by managed vLLM and managed llama.cpp model acquisition. The llama.cpp path resolves the YAML-declared revision and GGUF file, then verifies its size, SHA-256 digest, and filesystem identity before launch. Other applications can use the same cache.	Only after stopping every process that uses the cache. Sandbox destroy and full uninstall without `--delete-models` preserve it. Full uninstall with `--delete-models` deletes its non-credential data after managed model runtimes stop and only when no sibling gateway remains. The `token` and `stored_tokens` authentication files remain. Affected applications must download and verify their cached files again.

Legacy Migration Snapshot Cleanup

Current releases leave existing migration snapshots under ~/.nemoclaw/snapshots/ unchanged. The direct blueprint runner retains these action arguments to inspect or remove the legacy copies:

snapshots list
snapshots prune --keep 3
snapshots delete --path ~/.nemoclaw/snapshots/20260101T000000Z

These fragments are not standalone shell commands, and the host nemoclaw CLI does not expose them. An integration that invokes the direct runner can use snapshots list first to inspect the available timestamped copies. snapshots prune keeps the requested number of newest snapshots; --keep 0 removes all of them. snapshots delete accepts only one timestamped directory directly under ~/.nemoclaw/snapshots/. Both deletion commands are irreversible. They do not modify a running sandbox, but they remove the selected legacy copies.

Snapshot deletion requires python3 on a POSIX host. Listing works on native Windows, but deletion does not; use WSL to delete legacy snapshots on Windows.

Uninstall Behavior

nemoclaw uninstall --yes removes active NemoClaw runtime resources but preserves the user data needed for recovery by default. Preserved entries include rebuild-backups/, backups/, and sandboxes.json. Preserved sandboxes.json records are not automatically recoverable after reinstall, because uninstall removes the gateway registration, provider registrations, and Docker image they reference; uninstall warns about this at preserve time, and a later reinstall reports such records as not found on their recorded gateway with nemoclaw <name> destroy / nemoclaw onboard remediation. Interactive uninstall prompts before removing preserved state. For non-interactive runs, pass --destroy-user-data only when you accept losing local registry metadata and backups.

Uninstall scopes cleanup to one gateway port: it operates on the selected state root and leaves every other ~/.nemoclaw/gateways/<port>/ root and its gateway in place. It names the environments it left behind and prints the command that removes one of them. Pass --all-gateway-ports, or set NEMOCLAW_UNINSTALL_ALL_GATEWAY_PORTS=1, to remove every gateway port in one run. The shared host state is eligible for removal only when --keep-openshell is absent, no port fails or survives, and the selected gateway is not externally supervised.

Before it removes a selected state root, uninstall must prove that its state-bound Amazon Bedrock adapter process is absent. It revalidates the process identity and lifecycle generation before each signal and revalidates the evidence before deletion. If a stop remains unresolved after journal preparation, uninstall exits nonzero and preserves the PID, token, any lifecycle state that was published, and per-gateway journal. An earlier evidence conflict also exits nonzero and preserves every existing lifecycle file. Only full uninstall performs adapter-port orphan discovery; selected-gateway cleanup does not inspect sibling gateway state.

Before full uninstall deletes shared state, it removes only an authenticated host-local vLLM container and NemoClaw-owned llama.cpp container and network. Catalog-selected host-local vLLM also requires its owner-only runtime receipt; legacy authenticated containers without catalog profile labels retain their existing cleanup behavior. It refuses the remaining uninstall steps when Docker is unavailable or persisted ownership cannot be proved. Resolve the reported Docker or ownership error and rerun uninstall with the state still present. The shared Hugging Face cache used by managed vLLM and managed llama.cpp remains in place by default. --delete-models deletes every model in the local Ollama inventory and all non-credential data in the current user’s shared Hugging Face cache. The flag can delete cached files that other applications installed or use. It preserves the Hugging Face token and stored_tokens authentication files. NemoClaw deletes the non-credential cache data only after managed model runtimes stop and only when no sibling gateway remains. An Ollama inventory error, model deletion error, unsafe cache path, or cache-data deletion error makes uninstall exit nonzero.

For operational uninstall steps, refer to:

Uninstall NemoClaw.