Description

nemoclaw debug --sandbox <unknown-name> --output <path> silently collects host diagnostics for a non-existent sandbox name and writes a non-empty tarball, returning exit code 0 with no error message. The spec contract (T6029556) requires non-zero exit + actionable error naming the unknown sandbox + no partial tarball (or auto-delete on error).

Reproduces on Ubuntu 24.04 + GPU sandbox and Ubuntu 22.04 + CPU sandbox with identical behaviour and similar tarball sizes (~8 KB).

Environment

Devices tested:
  (A) KVM VM (x86_64 guest, A100 SXM4 40GB GPU passthrough)
  (B) Brev VM (GCP n2d-standard-4, 4 vCPU / 16 GiB, no GPU)
OS:
  (A) Ubuntu 24.04.4 LTS
  (B) Ubuntu 22.04 LTS (kernel 6.8.0-1058-gcp)
Architecture:  x86_64 (both)
Node.js:       v22.22.3 (both)
npm:           10.9.8 (both)
Docker:        29.5.2 (both)
OpenShell CLI: 0.0.44 (both)
NemoClaw:      v0.0.53 (both)
OpenClaw:      2026.5.22 (a374c3a) (both)

Steps to Reproduce

1. Standard NemoClaw onboard (any provider) — produces a real sandbox like my-assistant.
2. Confirm the sandbox name does-not-exist is not registered:

   nemoclaw list   # must not show 'does-not-exist'

3. Run debug on the unknown sandbox name:

   nemoclaw debug --sandbox does-not-exist --output /tmp/nemoclaw-debug-bad.tar.gz
   echo "exit=$?"

4. Verify whether a tarball was written:

   ls -la /tmp/nemoclaw-debug-bad.tar.gz
   tar -tzf /tmp/nemoclaw-debug-bad.tar.gz | head -10

Expected Result

Per T6029556 expected step 5:

• Command exits non-zero.
• Output contains an actionable error mentioning the unknown sandbox name (e.g. "Sandbox 'does-not-exist' is not registered").
• No partial tarball is written, or any tarball written is auto-deleted on error.

Actual Result

KVM (Ubuntu 24.04 / A100):

$ nemoclaw debug --sandbox does-not-exist --output /tmp/bad.tar.gz
  [debug] Collecting diagnostics for sandbox 'does-not-exist'...
  [debug] Quick mode: false
  [debug] Tarball output: /tmp/bad.tar.gz
$ echo $?
  0       ← FAIL (spec expects non-zero)
$ ls -la /tmp/bad.tar.gz
  -rw-rw-r-- 1 ubuntu ubuntu 8382 May 28 ...   ← FAIL (non-empty tarball persisted)
$ tar -tzf /tmp/bad.tar.gz | head
  nemoclaw-debug-gCPAFY/
  nemoclaw-debug-gCPAFY/openshell-logs.txt
  nemoclaw-debug-gCPAFY/date.txt
  nemoclaw-debug-gCPAFY/uname.txt
  ...

Brev (Ubuntu 22.04 / CPU): identical pattern — exit 0, tarball 7515 bytes, contains generic host diagnostics for a sandbox that does not exist.

No actionable error mentions the unknown sandbox name. The collected tarball is useless (no sandbox-specific data — the sandbox doesn't exist) but successfully produced, leading users to think their support bundle is valid when it is not.

Logs

$ nemoclaw debug --sandbox does-not-exist --output /tmp/bad.tar.gz 2>&1
[debug] Collecting diagnostics for sandbox 'does-not-exist'...
[debug] Quick mode: false
[debug] Tarball output: /tmp/bad.tar.gz

═══ System ═══

Thu May 28 15:28:57 UTC 2026
Linux brev-p32vgtiaa 6.8.0-1058-gcp #61~22.04.1-Ubuntu SMP ... x86_64

(... rest of generic host info, NOT sandbox-specific data ...)

$ echo $?
0

Suggested Fix

Add a pre-collection sandbox-name validation in the debug handler:

if not nemoclaw_registry_has(sandbox_name):
    fatal(
        f"Sandbox '{sandbox_name}' is not registered. "
        "Run 'nemoclaw list' to see registered sandboxes, "
        "or onboard one with 'nemoclaw onboard'.",
        exit_code=1
    )
    # do not invoke the collection / tarball-write path

If the user explicitly wants a host-only diagnostic without a sandbox, they can use nemoclaw debug --quick (already supported) or a new --no-sandbox flag, but the current default behaviour of silently producing a misleadingly-named tarball is a usability hazard for the support flow.

NVB#6237567