Description

NemoClaw is not behaving like a stable, repeatable agent runtime in my VM-based deployment.

I am seeing four related problems:

1. Sandbox non-persistence

• After restart/reboot, sandbox state is lost or becomes unusable
• Recovery appears to require reinitialization instead of normal restart

2. Gateway lifecycle instability

• I do not see a reliable non-destructive start/stop/restart workflow
• Recovery appears to require destructive teardown/reset

3. Unclear or inconsistent CLI behavior

• Commands such as:
  nemoclaw connect
  did not behave as expected
• It is not clear what the supported/reliable command path is for reconnecting to an existing setup

4. LLM interaction appears limited to one request at a time

• In practice, we could only get one request at a time to the LLM by using the -m argument
• That makes the system feel like a one-shot command path rather than a persistent multi-step agent workflow

Together, these issues block progression from an early proof-of-concept to a repeatable system.

Expected Behavior

• Sandbox should persist across restart/reboot, or there should be a clearly documented restore path
• Gateway should support a reliable non-destructive lifecycle:
  • start
  • stop
  • restart
• CLI commands for connect/reconnect should be deterministic and documented
• The system should support persistent multi-step agent workflows, not only one request at a time via -m
• There should be a minimal "hello world" validation path for:
  • gateway health
  • sandbox readiness
  • model connectivity

Actual Behavior

• Sandbox state is lost or becomes unusable after restart/reboot
• Gateway recovery appears to require destructive teardown/reset
• CLI reconnect path is unclear or inconsistent
• Practical LLM interaction appears limited to one request at a time using -m
• There is no obvious minimal validation path to separate gateway issues, sandbox issues, and model connectivity issues

Addtional Context
This effort is currently around NASA Technology Readiness Level (TRL) 2-3:

• concept and early proof-of-concept have been demonstrated

The goal is to progress toward TRL 4-5:

• validated, repeatable system behavior

Right now, sandbox non-persistence, lifecycle fragility, and the apparent one-request-at-a-time -m interaction path are blocking that transition.

Target architecture:

• isolated VM sandbox
• host-served local model over HTTP
• repeatable agent workflow
• no dependence on external API-key-only flow for basic local testing

Happy to test patches, provide logs, or validate fixes in a controlled VM environment.

Reproduction Steps

1. Deploy NemoClaw in Ubuntu 22.04 VM under KVM/QEMU
2. Use Docker-based NemoClaw setup
3. Start gateway and sandbox
4. Attempt agent workflow / connection workflow
5. Restart VM and/or services
6. Observe that sandbox state is lost or unusable, and normal recovery is unclear
7. Attempt reconnect / reuse workflow with commands such as:
   nemoclaw connect
8. Observe unclear or inconsistent behavior
9. Attempt LLM requests
10. Observe that practical operation appears limited to one request at a time using the -m argument

Environment

• Host: Fedora
• Hardware: Minisforum MS-S1
• Memory split target/use case: 128 GB UMA system, targeting 32 GB CPU / 96 GB GPU
• VM: Ubuntu 22.04
• Hypervisor: KVM/QEMU
• Runtime: Docker + NemoClaw
• Architecture: VM sandbox -> host local model over HTTP
• Use case: secure isolated agent workflows using a local model endpoint

Debug Output

Attempted to run the requested debug command:

  nemoclaw debug --quick

Result:

  Unknown command: debug

  Registered sandboxes: nemoclaw-baseline, <redacted-user-sandbox>
  Try: nemoclaw <sandbox-name> connect

  Run 'nemoclaw help' for usage.

This suggests the installed CLI does not include the debug subcommand referenced by the issue template.

Collected diagnostics using available commands:

1. nemoclaw list

  Sandboxes:
    nemoclaw-baseline *
      model: unknown  provider: unknown  CPU  policies: none
    <redacted-user-sandbox>
      model: nvidia/nemotron-3-super-120b-a12b  provider: nvidia-nim  CPU  policies: none

  * = default sandbox

2. nemoclaw nemoclaw-baseline status

  Sandbox: nemoclaw-baseline
    Model:    unknown
    Provider: unknown
    GPU:      no
    Policies: none
    NIM:      not running

3. nemoclaw nemoclaw-baseline logs

  error: unrecognized subcommand 'logs'

  Usage: openshell sandbox [OPTIONS] [COMMAND]

  For more information, try '--help'.
    Command failed (exit 2): openshell sandbox logs nemoclaw-baseline

4. nemoclaw status

  Sandboxes:
    nemoclaw-baseline *
    <redacted-user-sandbox> (nvidia/nemotron-3-super-120b-a12b)

  ● telegram-bridge  (stopped)
  ● cloudflared  (stopped)

Notes:
- The issue template references a debug command that is not present in the installed CLI
- The CLI help advertises a logs command, but it fails due to an underlying openshell subcommand error
- Default sandbox reports unknown model/provider and NIM not running

Logs

Unable to provide logs.

The CLI advertises:
  nemoclaw <name> logs

However, invoking it results in:

  error: unrecognized subcommand 'logs'
  Command failed (exit 2): openshell sandbox logs <sandbox-name>

This appears to be a broken or unimplemented logs pathway in the current CLI.

Checklist

• I confirmed this bug is reproducible
• I searched existing issues and this is not a duplicate