Problem Statement

NemoClaw can manage multiple sandboxes today, but the host-level NemoClaw/OpenShell integration appears to be a singleton. The managed OpenShell gateway name defaults to the fixed identity nemoclaw, and related local state such as registry, credentials, snapshots, onboarding metadata, and recovery/cleanup flows are tied to that single NemoClaw instance.

This prevents a useful local development and testing pattern (potentially production also): running two fully segregated NemoClaw-managed OpenClaw environments on the same host, each with its own gateway, inference provider/API key/model, policies, messaging configuration, registry, snapshots, and lifecycle.

Concrete user impact:

• Two fully segregated NemoClaw-managed agents cannot currently coexist on one Docker daemon. This blocks common dev/test workflows such as billing isolation, A/B model testing, multi-tenant POCs, and parallel CI.
• NemoClaw cannot cleanly adopt or target a user-managed OpenShell gateway with a different name. Even if a user creates separate named OpenShell gateways, NemoClaw orchestration still assumes its configured singleton gateway identity.
• Existing workarounds are heavier than the use case warrants: use bare OpenShell and lose NemoClaw lifecycle conveniences, use separate Docker daemons, or run separate VMs.
• This appears to be a NemoClaw orchestration constraint. OpenShell already has a first-class concept of named gateways; the missing piece is allowing NemoClaw to carry an instance identity through its own onboarding, registry, provider, recovery, cleanup, and command flows.

Proposed Design

Make the NemoClaw instance identity configurable, while preserving the current default behavior for existing users.

A NemoClaw instance should have a configurable gateway name and state root, with defaults equivalent to today’s behavior:

• gateway name: nemoclaw
• state root: current NemoClaw state location, e.g. ~/.nemoclaw/

That instance identity should be carried consistently through:

• nemoclaw onboard
• gateway start/select/destroy/recovery
• provider and inference configuration
• registry and credential storage
• snapshots and rebuilds
• status/list/debug/doctor/uninstall flows
• messaging/channel configuration
• documentation and troubleshooting output

Example commands

NEMOCLAW_INSTANCE=agent-a nemoclaw onboard
NEMOCLAW_INSTANCE=agent-b nemoclaw onboard

Each instance would own its own OpenShell gateway, local state, credentials, registry, snapshots, providers, and messaging configuration.

Alternatives Considered

• Use one gateway with per-sandbox inference routing. This would help with provider/model separation, but it does not by itself isolate NemoClaw registry, credentials, snapshots, messaging configuration, or lifecycle state.
• Use bare OpenShell directly. This works today for advanced users and gives full gateway segregation, but it bypasses NemoClaw’s onboarding, policy presets, rebuild, snapshot, doctor, share mount, channel registry, and other lifecycle conveniences.
• Use separate VMs or separate Docker daemons. This is the cleanest supported workaround today, but it is heavy for the common case of two development sandboxes on one workstation.
• Add only a gateway-name flag. This is likely insufficient unless the local state root is also configurable, because instances would still collide in NemoClaw-managed state.

Category

enhancement: feature

Checklist

• I searched existing issues and this is not a duplicate
• This is a design proposal, not a "please build this" request