Description

[Description]
When restoring a snapshot into an existing NemoClaw sandbox using --to, the documented Scenario B expects the operation to be rejected if the destination sandbox already exists: the command should fail with a clear error, exit non‑zero, and leave the destination sandbox unchanged. In practice, running nemoclaw new-sb snapshot restore cross-restore --to sbx-dst succeeds even when sbx-dst already exists, and reports ✓ Restored 13 directories, 0 files. This shows that the restore operation proceeds into an existing destination instead of refusing to run, so the Scenario B “existing destination is rejected” behavior cannot be validated as written and there is a risk of silently mutating an existing sandbox’s filesystem.

[Environment]
NemoClaw: v0.0.44 (same CLI version used for snapshot create/restore)
OpenShell CLI: 0.0.39
OpenClaw: 2026.4.24 (cbcfdf6)
Sandbox OS: Linux (default NemoClaw base image, x86_64)
Container runtime: Docker on DGX Spark host
Network: standard outbound access; no networking issues involved in this scenario

[Steps to Reproduce]

Pre‑conditions:

1. NemoClaw CLI and OpenShell gateway are installed and working.
2. Source sandbox new-sb exists and is running.
3. Destination sandbox sbx-dst has already been created and exists (this is intentional for Scenario B).
4. A snapshot named cross-restore exists for new-sb (e.g., nemoclaw new-sb snapshot create cross-restore was run earlier, producing version v1).

Steps:

1. On the host, confirm that both sandboxes exist:
   bash nemoclaw sandbox list

   and verify that new-sb and sbx-dst are both present.

2. 
   Confirm that new-sb has a snapshot named cross-restore:
   bash

   nemoclaw new-sb snapshot list

   and note the version (e.g., v1 name=cross-restore).

3. 
   Attempt a cross-restore into the existing destination sandbox:
   bash

   nemoclaw new-sb snapshot restore cross-restore --to sbx-dst

4. 
   Observe the CLI output and exit code.
5. 
   Optionally, inspect sbx-dst content (e.g., nemoclaw sbx-dst connect and check filesystem) to confirm that some directories were restored.

[Expected]

• For Scenario B (--to with an existing destination sandbox):
  • Step 3 should fail with a clear, user‑visible error, such as:

    “Destination sandbox 'sbx-dst' already exists. Use a different name or delete the destination before restoring with --to.”
    

    
    
    • 
      The command should exit with a non‑zero status code.
    • 
      No directories or files in sbx-dst should be created, modified, or deleted as part of this failed restore attempt.
    • 
      No new sandbox container should be half‑created for sbx-dst, and the source sandbox’s gateway should not be restarted or destroyed.
    • 
      The operation must not silently proceed when the destination already exists; Scenario B is specifically intended to validate rejection behavior and safety for existing destinations.

    
    

    [Actual]
    

    
    
    • 
      Running the restore with an existing destination succeeds instead of failing:
      
      bash
      nvidia@spark-dadc:~$ nemoclaw new-sb snapshot restore cross-restore --to sbx-dst Using snapshot v1 name=cross-restore (2026-05-18T19-21-34-605Z) Restoring snapshot from 'new-sb' into 'sbx-dst'... ✓ Restored 13 directories, 0 files
    • 
      The command reports success (✓ Restored 13 directories, 0 files) and does not emit any warning or error about sbx-dst already existing.
    • 
      Exit code is treated as success (no indication of failure at the CLI).
    • 
      This behavior contradicts the Scenario B expectation that --to should be rejected when the destination sandbox already exists, and implies that the restore logic proceeds to apply the snapshot into sbx-dst instead of protecting the existing sandbox from modification.
    
    

[Impact / Notes]

• QA cannot validate the documented Scenario B behavior (“--to with existing destination is rejected”) because the implementation currently allows the operation to proceed.
• There is a safety concern: users might assume --to will refuse to touch an existing sandbox, but in practice it appears to restore into it, which could overwrite or mutate files in sbx-dst without an explicit confirmation step.
• Suggested fixes:
  • At minimum, introduce an explicit existence check for the --to destination and fail fast with a clear error if the sandbox name already exists.
  • Optionally, add a --force flag that allows restoring into an existing destination explicitly, while keeping the default behavior safe and aligned with the test case.

Bug Details

[NVB#6188374]