Manage Sandbox Lifecycle
Use this guide after you finish the OpenClaw quickstart.
It covers day-two sandbox operations such as listing sandboxes, checking health, managing ports, rebuilding safely, upgrading, and uninstalling.
When a workflow uses the lower-level OpenShell CLI, see CLI Selection Guide for the boundary between nemoclaw and openshell.
List Sandboxes
List every sandbox registered on this host:
The list shows each sandbox’s model, provider, policy presets, active SSH session indicator, and dashboard URL when NemoClaw records a dashboard port. Use JSON output for scripts:
Check Sandbox Health
Check a specific sandbox’s health, inference route, active connections, live policy, update status, and messaging-channel overlap warnings:
Use the host-level status command when you want the sandbox inventory plus host auxiliary service state, such as cloudflared:
Inspect Logs
View recent sandbox logs:
Stream logs while you reproduce a problem:
The log command reads both OpenClaw gateway output and OpenShell audit events, so policy denials appear beside gateway logs.
Collect Diagnostics
Collect diagnostics for bug reports or support handoff:
Use --quick for a smaller local summary:
The debug command gathers system information, Docker state, gateway logs, and sandbox status.
Manage Dashboard Ports
If the forward stopped, or the installer reported that no active forward was found and the URL does not load, restart it manually with the port from the install summary.
To list active forwards across all sandboxes, run the following command.
Run Multiple Sandboxes
Each sandbox needs its own dashboard port, since openshell forward refuses to bind a port that another sandbox is already using.
When the default port is already held by another sandbox, nemoclaw onboard scans ports 18789 through 18799 and uses the next free port.
If you intentionally run separate OpenShell gateways on the same host, set a different NEMOCLAW_GATEWAY_PORT before each onboarding run.
NemoClaw isolates the gateway name and local state by port so one port-specific gateway does not replace another.
Gateway and dashboard cleanup is scoped by sandbox name and port.
A later onboarding run that uses a different NEMOCLAW_GATEWAY_PORT or --control-ui-port does not tear down the first sandbox’s gateway or dashboard forward.
To choose a specific port, pass --control-ui-port:
You can also set CHAT_UI_URL or NEMOCLAW_DASHBOARD_PORT before onboarding:
For full details on port conflicts and overrides, refer to Port already in use.
Reconfigure or Recover
Recover from a misconfigured sandbox without re-running the full onboard wizard or destroying workspace state.
Change Inference Model or API
Change the active model or provider at runtime without rebuilding the sandbox:
Refer to Switch Inference Providers for provider-specific model IDs and API compatibility notes.
Restart the Gateway and Port Forward
If nemoclaw <name> status reports the sandbox is alive but the gateway is not running, run the recover command instead of opening a shell.
The command restarts the in-sandbox gateway and re-establishes the dashboard port-forward in one step.
It is idempotent and safe to script.
Refer to nemoclaw <name> recover for details.
Reset a Stored Credential
If you entered a provider credential incorrectly during onboarding, clear the gateway-registered value and re-enter it on the next onboard run:
The command reference documents nemoclaw credentials reset <PROVIDER> in full.
Rebuild a Sandbox While Preserving Workspace State
If you changed the underlying Dockerfile, upgraded OpenClaw, or want to pick up a new base image without losing your sandbox’s workspace files, use rebuild instead of destroying and recreating:
Rebuild preserves the mounted workspace and registered policies while recreating the container.
If NemoClaw cannot archive any requested state path, it reports the backup failure and stops before deleting the original sandbox.
Refer to nemoclaw <name> rebuild for flag details.
Add a Network Preset After Onboarding
Apply an additional preset, such as Telegram or GitHub, to a running sandbox without re-onboarding:
Refer to nemoclaw <name> policy-add for usage details and flags.
Non-interactive re-onboards in the default suggested policy mode preserve presets added this way.
To make a re-onboard authoritative, set NEMOCLAW_POLICY_MODE=custom and provide NEMOCLAW_POLICY_PRESETS with the exact list to apply; onboarding removes anything else.
See NEMOCLAW_POLICY_MODE for the full table.
Update to the Maintained Version
When a maintained NemoClaw release becomes available, update the host CLI and then check whether existing sandboxes need rebuilds.
The standard installer follows the admin-promoted lkg release tag by default.
If you need a specific release, set NEMOCLAW_INSTALL_TAG on the bash side of the install pipeline.
Before upgrade work, the installer runs nemoclaw backup-all when the installed CLI supports it.
For manual upgrade flows, create a snapshot first and then run the update or rebuild command you need:
Each rebuild destroys the old container and creates a new one, while preserving the manifest-defined workspace or agent state that NemoClaw knows how to snapshot.
upgrade-sandboxes --check can report a sandbox as stale because the running agent version is behind, because the managed NemoClaw image fingerprint differs from the current CLI, or both.
Custom-image sandboxes created with --from <Dockerfile> are not marked stale solely by image fingerprint, so an upgrade check does not accidentally replace them with the default image.
Runtime changes outside those state paths, such as packages installed manually in the running container, are not preserved.
For the full state-preservation contract, snapshot restore behavior, and manual backup workflow, refer to Backup and Restore.
For command flags, refer to nemoclaw update, nemoclaw upgrade-sandboxes, and nemoclaw <name> rebuild.
Uninstall
To remove NemoClaw and all resources created during setup, run the CLI’s built-in uninstall command:
The uninstall command preserves ~/.nemoclaw/rebuild-backups/ (host-side snapshots that snapshot and backup-all commands write), ~/.nemoclaw/backups/ (workspace backups that scripts/backup-workspace.sh writes), and ~/.nemoclaw/sandboxes.json (the sandbox registry) by default.
Uninstall removes every other entry under ~/.nemoclaw/.
Interactive runs prompt before they remove the preserved entries; the default answer keeps them.
For non-interactive runs (--yes, NEMOCLAW_NON_INTERACTIVE=1, or a non-TTY shell), set NEMOCLAW_UNINSTALL_DESTROY_USER_DATA=1 to acknowledge data loss and remove the preserved entries as well.
See the Commands reference for the full preservation contract.
The CLI uninstall command runs the version-pinned uninstall.sh that shipped with your installed CLI, so it does not fetch anything over the network at uninstall time.
If the CLI is missing or broken, fall back to the hosted script:
The same --yes, --keep-openshell, and --delete-models flags listed above also apply to the hosted script. Pass them after bash -s --.
For a full comparison of the two forms, including what they fetch, what they trust, and when to prefer each, refer to nemoclaw uninstall vs. the hosted uninstall.sh.
Related Topics
- Set Up Messaging Channels to connect Telegram, Discord, or Slack.
- Workspace Files for persistent OpenClaw files inside the sandbox.
- Backup and Restore for snapshot and restore workflows.
- Monitor Sandbox Activity for observability tools.