[NemoClaw][onboard][All Platforms] nemoclaw uninstall + reinstall flow leaves an orphaned sandbox that the reinstalled CLI can't recover or clean up

[zNeill]

Description

Description

Running nemoclaw uninstall --yes (default flags, no --destroy-user-data) followed immediately by a fresh install of the same tag leaves the environment in an inconsistent state:

1. Uninstall preserves sandboxes.json under ~/.nemoclaw by design, but also removes the OpenShell CLI, the Docker container/gateway, the gateway metadata, and all provider registrations — everything that would be needed to interact with the sandbox recorded in that preserved sandboxes.json.
2. On reinstall, the installer reads the preserved sandboxes.json, tries to "recover and upgrade pre-existing sandboxes," and immediately hits Error: × No gateway metadata found for 'nemoclaw' because uninstall deleted the gateway registration that the recorded sandbox referenced.
3. The installer then bootstraps a new gateway (also named nemoclaw), notices the recorded sandbox my-assistant isn't observable on it, and prints Skipping 1 sandbox(es) not observed on the selected gateway — verify their recorded gateway or start them first.
4. The installer reports === Installation complete === and Existing sandboxes were recovered and upgraded — but nothing was actually recovered. my-assistant is stranded: its metadata is in sandboxes.json, its Docker image was removed during uninstall (Removed Docker image 80ed9cda5bf6), and the new gateway has no record of it.

There's also a version-drift oddity worth flagging: the stale-sandbox line reads NemoClaw image v0.0.77 → v0.0.76, i.e. the installer is proposing a downgrade from v0.0.77 to the requested v0.0.76. This is a consequence of NEMOCLAW_INSTALL_TAG=v0.0.76 being older than whatever built my-assistant originally, but the installer surfaces it as a routine "upgrade" step without warning.

Net effect: the "preserve sandboxes on uninstall" contract is broken — the preserved data is unrecoverable by design after uninstall removes its dependencies, and the reinstall path reports success while silently orphaning the user's sandbox.

Environment:

• Host: macOS (Mac Studio), user hellonemoclaw
• Container runtime: colima
• Node.js: v22.23.1, npm 10.9.8
• Uninstall command: nemoclaw uninstall --yes
• Reinstall command: curl -fsSL https://www.nvidia.com/nemoclaw.sh | NEMOCLAW_INSTALL_TAG=v0.0.76 bash
• Preserved sandbox: my-assistant (stopped, v2026.6.10, image v0.0.77)

Steps to reproduce

1. Have a working NemoClaw install with at least one registered sandbox (my-assistant, stopped is fine), built on a newer image than the tag you'll reinstall to.
2. Run:

   nemoclaw uninstall --yes

Observe that it preserves rebuild-backups and sandboxes.json under ~/.nemoclaw, but removes the OpenShell CLI, the gateway, all providers, and the Docker image. 3. Confirm the CLI is gone:

   openshell gateway select
   # zsh: command not found: openshell

Reinstall:

   curl -fsSL https://www.nvidia.com/nemoclaw.sh | NEMOCLAW_INSTALL_TAG=v0.0.76 bash

Accept the third-party notice. Let the installer run through phases 1–3.

Observe the "Recovering and upgrading pre-existing sandboxes" step.

Expected output

One of the following, consistent behavior:

• Preferred: uninstall and reinstall are symmetric. Either uninstall preserves everything needed to recover the sandboxes it preserves (gateway metadata, provider registrations, and the Docker image referenced by sandboxes.json), or it clearly warns that preserving sandboxes.json without those dependencies makes the preserved data unrecoverable and offers to purge it too. On reinstall, my-assistant is either brought back to a usable state on the new gateway or the user is given a concrete remediation path.
• Acceptable: the reinstall path detects that the recorded sandboxes reference a gateway/image that no longer exist, prints an actionable diagnostic (e.g. "sandbox my-assistant cannot be recovered because its Docker image was removed during uninstall; run nemoclaw sandbox forget my-assistant to clear it, or nemoclaw onboard my-assistant to rebuild"), and does not report Installation complete / Existing sandboxes were recovered and upgraded when nothing was recovered.

In addition, a proposed downgrade (v0.0.77 → v0.0.76) should be surfaced explicitly rather than framed as a routine upgrade step.

Actual output

Uninstall (relevant excerpt):

Preserving rebuild-backups, sandboxes.json under /Users/hellonemoclaw/.nemoclaw.
...
[2/6] OpenShell resources
Deleted all OpenShell sandboxes skipped
Deleted provider 'nvidia-nim' skipped
Deleted provider 'vllm-local' skipped
Deleted provider 'ollama-local' skipped
Deleted provider 'nvidia-ncp' skipped
Deleted provider 'nim-local' skipped
Gateway 'nemoclaw' already removed or unreachable
...
[4/6] Docker resources
Removed Docker image 80ed9cda5bf6
...
Removed contents of /Users/hellonemoclaw/.nemoclaw (preserved: rebuild-backups, sandboxes.json)

Reinstall (relevant excerpt):

[3/3] Onboarding
[INFO]  Recovering and upgrading pre-existing sandboxes before onboarding…
Error:   × No gateway metadata found for 'nemoclaw'.
  │ Register it first with: openshell gateway add  --name nemoclaw
  │ Or list available gateways: openshell gateway select

  [2/8] Starting OpenShell gateway
  Starting OpenShell Docker-driver gateway...
  ✓ Docker-driver gateway is healthy
✓ Active gateway set to 'nemoclaw'

  Stale sandboxes:
    my-assistant  v2026.6.10 unchanged; NemoClaw image v0.0.77 → v0.0.76  (stopped)

  Skipping 1 sandbox(es) not observed on the selected gateway — verify their recorded gateway or start them first.
  No running stale sandboxes to rebuild.
[INFO]  Existing sandboxes recovered; skipping generic onboarding.
[INFO]  === Installation complete ===

  Existing sandboxes were recovered and upgraded.
  No new sandbox onboarding was needed.

Notable specifics:

• Every step under [2/6] OpenShell resources reports skipped alongside "Deleted …" — the wording is contradictory. It reads as "Deleted X skipped," which is ambiguous about whether deletion happened. If the intent is "already gone, nothing to delete," the phrasing needs to be Skipped 'nvidia-nim' (already removed), not Deleted provider 'nvidia-nim' skipped.
• The Error: × No gateway metadata found for 'nemoclaw' line is printed mid-flow, then the installer proceeds and prints Installation complete — the error was swallowed, not addressed.
• Final lines claim Existing sandboxes were recovered and upgraded and No new sandbox onboarding was needed, both false in this run. One sandbox was silently skipped and the user is left with no path to recover or forget it.
• The stale-sandbox line shows a downgrade (v0.0.77 → v0.0.76) but doesn't call it out as such.

Bug Details

Field	Value
Priority	Unprioritized
Action	Dev - Open - To fix
Disposition	Open issue
Module	Machine Learning - NemoClaw
Keyword	NemoClaw, NEMOCLAW_GH_SYNC_APPROVAL, NemoClaw_Onboard

---

[NVB#6432188]

[hulynn]

Still reproduces on v0.0.88 — the symptom changed but the strand-on-reinstall core remains. Requesting reopen.

Re-verified on DGX Spark (GB10, aarch64), Ubuntu 24.04, NemoClaw v0.0.88, OpenShell 0.0.85, OpenClaw 2026.6.10.

Repro: onboard an OpenClaw sandbox b3test (ollama-local) → nemoclaw uninstall --yes (preserves ~/.nemoclaw/sandboxes.json, removes the nemoclaw gateway + container) → reinstall via curl … | NEMOCLAW_ACCEPT_THIRD_PARTY_SOFTWARE=1 bash.

What changed since this issue was filed: the reinstall no longer falsely reports "Installation complete / Existing sandboxes were recovered and upgraded." It now hard-aborts at the strict pre-upgrade backup:

[2/3] NemoClaw CLI
  Backing up 1 sandbox(es) before upgrading OpenShell…
Error: × No gateway metadata found for 'nemoclaw'.
  [2/8] Starting OpenShell gateway … ✓ healthy … Active gateway set to 'nemoclaw'
  Skipping 'b3test' (not running; start the sandbox/container and rerun 'nemoclaw backup-all' …)
  Pre-upgrade backup: 0 backed up, 0 failed, 1 skipped
  Strict pre-upgrade backup requires every registered sandbox to be backed up; 1 sandbox(es) were skipped.
[ERROR] Pre-upgrade backup stopped the installer. Resolve every reported sandbox backup failure or skipped sandbox …, then rerun the installer.
  → exit 1

So the false-success part appears fixed, but the underlying issue is still present: uninstall --yes strands the recorded sandbox (its gateway + container are removed) and the next install cannot proceed — it just fails loudly now. The stranded sandbox cannot be backed up (gateway/container gone), yet strict pre-upgrade backup refuses to skip it, so the installer aborts and leaves the user with the CLI + a stale sandboxes.json record + no working sandbox.

Recovery that works: nemoclaw b3test destroy --yes (clears the stale record) then re-onboard; or nemoclaw uninstall --destroy-user-data. v0.0.88's uninstall --yes does now warn at uninstall time ("its recorded sandboxes cannot be recovered automatically on reinstall … run 'nemoclaw destroy' … or rerun uninstall with --destroy-user-data").

Suggested direction: on reinstall, a stranded sandbox (recorded gateway removed, container absent) that cannot be backed up should be skipped-with-warning or offered for destroy, rather than hard-aborting the whole installer.

(Reproduced on a host that also runs sibling gateways, so uninstall --yes kept the shared CLI; the strand-on-reinstall behavior is independent of that.)