Gérer le Cycle de Vie du Sandbox

Utilisez ce guide après avoir terminé le démarrage rapide OpenClaw (utiliser la skill nemoclaw-user-get-started). Il couvre les opérations de jour deux du sandbox telles que l'énumération des sandboxes, la vérification de la santé, la gestion des ports, la reconstruction sécurisée, la mise à niveau et la désinstallation. Quand un workflow utilise la CLI OpenShell de niveau inférieur, consultez le Guide de Sélection CLI (utiliser la skill nemoclaw-user-reference) pour la limite entre nemoclaw et openshell.

Étape 1 : Énumérer les Sandboxes

Énumérez tous les sandboxes enregistrés sur cet hôte :

$ nemoclaw list

La liste affiche le modèle, le fournisseur, les présets de politique, l'indicateur de session SSH active et l'URL du tableau de bord de chaque sandbox quand un port de tableau de bord est enregistré. Utilisez la sortie JSON pour les scripts :

$ nemoclaw list --json

Étape 2 : Vérifier la Santé du Sandbox

Vérifiez la santé d'un sandbox spécifique, sa route d'inférence, les connexions actives, la politique active, le statut de mise à jour et les avertissements de chevauchement de canaux de messagerie :

$ nemoclaw my-assistant status

Utilisez la commande de statut au niveau de l'hôte quand vous voulez l'inventaire des sandboxes plus l'état du service auxiliaire hôte, comme cloudflared :

$ nemoclaw status

Étape 3 : Inspecter les Journaux

Affichez les journaux récents du sandbox :

$ nemoclaw my-assistant logs

Diffusez les journaux en continu pendant que vous reproduisez un problème :

$ nemoclaw my-assistant logs --follow

La commande log lit à la fois la sortie de la passerelle OpenClaw et les événements d'audit OpenShell, ainsi les refus de politique apparaissent à côté des journaux de la passerelle.

Étape 4 : Collecter les Diagnostics

Collectez les diagnostics pour les rapports de bugs ou le transfert au support :

$ nemoclaw debug --sandbox my-assistant --output nemoclaw-debug.tar.gz

Utilisez --quick pour un résumé local plus petit :

$ nemoclaw debug --quick --sandbox my-assistant

La commande debug rassemble les informations système, l'état de Docker, les journaux de la passerelle et le statut du sandbox.

Étape 5 : Gérer les Ports du Tableau de Bord

Si la redirection s'est arrêtée ou si l'installateur a signalé qu'aucune redirection active n'a été trouvée et que l'URL ne se charge pas, redémarrez-la manuellement avec le port du résumé d'installation.

$ openshell forward start --background <dashboard-port> my-gpt-claw

Pour énumérer les redirections actives sur tous les sandboxes, exécutez la commande suivante.

$ openshell forward list

Étape 6 : Exécuter Plusieurs Sandboxes

Chaque sandbox a besoin de son propre port de tableau de bord, puisque openshell forward refuse de lier un port qu'un autre sandbox utilise déjà. Quand le port par défaut est déjà utilisé par un autre sandbox, nemoclaw onboard analyse les ports 18789 à 18799 et utilise le prochain port libre.

$ nemoclaw onboard                                      # premier sandbox utilise 18789
$ nemoclaw onboard                                      # deuxième sandbox utilise le prochain port libre, comme 18790

Pour choisir un port spécifique, passez --control-ui-port :

$ nemoclaw onboard --control-ui-port 19000

Vous pouvez aussi définir CHAT_UI_URL ou NEMOCLAW_DASHBOARD_PORT avant l'onboarding :

$ CHAT_UI_URL=http://127.0.0.1:19000 nemoclaw onboard
$ NEMOCLAW_DASHBOARD_PORT=19000 nemoclaw onboard

Pour tous les détails sur les conflits de ports et les remplacements, consultez Port already in use (utiliser la skill nemoclaw-user-reference).

Étape 7 : Reconfigurer ou Récupérer

Récupérez d'un sandbox mal configuré sans relancer l'assistant d'onboarding complet ou détruire l'état de l'espace de travail.

Changer le Modèle ou l'API d'Inférence

Changez le modèle actif ou le fournisseur au moment de l'exécution sans reconstruire le sandbox :

$ openshell inference set -g nemoclaw --model <model> --provider <provider>

Consultez Switch Inference Providers (utiliser la skill nemoclaw-user-configure-inference) pour les identifiants de modèle spécifiques au fournisseur et les notes de compatibilité API.

Redémarrer la Passerelle et la Redirection de Port

Si nemoclaw <name> status signale que le sandbox est actif mais que la passerelle ne s'exécute pas, exécutez la commande recover au lieu d'ouvrir un shell.

$ nemoclaw <sandbox-name> recover

La commande redémarre la passerelle dans le sandbox et rétablit la redirection de port du tableau de bord en une seule étape. Elle est idempotente et sûre pour les scripts. Consultez nemoclaw <name> recover (utiliser la skill nemoclaw-user-reference) pour les détails.

Réinitialiser une Credential Stockée

Si une credential de fournisseur a été saisie incorrectement lors de l'onboarding, effacez la valeur enregistrée par la passerelle et re-saisissez-la à la prochaine exécution d'onboard :

$ nemoclaw credentials list                # voir quels fournisseurs sont enregistrés
$ nemoclaw credentials reset <PROVIDER>    # effacer un fournisseur unique, par exemple nvidia-prod
$ nemoclaw onboard                         # relancer pour re-saisir le fournisseur effacé

La commande credentials est documentée en entier à nemoclaw credentials reset <PROVIDER> (utiliser la skill nemoclaw-user-reference).

Reconstruire un Sandbox en Préservant l'État de l'Espace de Travail

Si vous avez changé le Dockerfile sous-jacent, mis à niveau OpenClaw, ou voulez utiliser une nouvelle image de base sans perdre les fichiers d'espace de travail de votre sandbox, utilisez rebuild au lieu de détruire et recréer :

$ nemoclaw <sandbox-name> rebuild

Rebuild préserve l'espace de travail monté et les politiques enregistrées tout en recréant le conteneur. Si NemoClaw ne peut pas archiver un chemin d'état demandé, il signale l'échec de la sauvegarde et s'arrête avant de supprimer le sandbox original. Consultez nemoclaw <name> rebuild (utiliser la skill nemoclaw-user-reference) pour les détails des flags.

Ajouter un Preset Réseau Après l'Onboarding

Appliquez un preset supplémentaire, comme Telegram ou GitHub, à un sandbox en cours d'exécution sans re-onboarder :

$ nemoclaw <sandbox-name> policy-add

Consultez nemoclaw <name> policy-add (utiliser la skill nemoclaw-user-reference) pour les détails d'utilisation et les flags.

Les re-onboards non-interactifs en mode de politique suggested par défaut préservent les presets ajoutés de cette manière. Pour rendre un re-onboard autoritaire, définissez NEMOCLAW_POLICY_MODE=custom et fournissez NEMOCLAW_POLICY_PRESETS avec la liste exacte à appliquer ; l'onboarding supprime tout le reste. Consultez NEMOCLAW_POLICY_MODE (utiliser la skill nemoclaw-user-reference) pour la table complète.

Étape 8 : Mettre à Jour vers la Dernière Version

Quand une nouvelle version de NemoClaw devient disponible, mettez à jour la CLI nemoclaw sur votre hôte et vérifiez les sandboxes existants pour les versions d'agent/runtime obsolètes.

Mettre à Jour la CLI NemoClaw

Relancez l'installateur. Avant qu'il ne onboard quoi que ce soit, l'installateur appelle automatiquement nemoclaw backup-all (utiliser la skill nemoclaw-user-reference), stockant un snapshot de chaque sandbox en cours d'exécution dans ~/.nemoclaw/rebuild-backups/ comme filet de sécurité.

$ curl -fsSL https://www.nvidia.com/nemoclaw.sh | bash

Mettre à Niveau les Sandboxes avec des Versions d'Agent et Runtime Obsolètes

L'installateur vérifie les sandboxes enregistrés après la réussite de l'onboarding et exécute nemoclaw upgrade-sandboxes --auto pour les sandboxes en cours d'exécution avec des versions obsolètes. Utilisez upgrade-sandboxes directement pour vérifier le résultat, reconstruisez quand vous avez ignoré l'étape d'installation ou d'onboarding, ou gérez les sandboxes qui ont été arrêtés ou dont la version n'a pas pu être vérifiée. Le flux de mise à niveau est non-destructif par défaut car NemoClaw préserve l'état de l'espace de travail défini dans le manifest, mais un snapshot manuel avant toute mise à niveau majeure vous donne un point de restauration d'état.

$ nemoclaw <sandbox-name> snapshot create --name pre-upgrade   # optionnel, recommandé
$ curl -fsSL https://www.nvidia.com/nemoclaw.sh | bash          # met à jour CLI ; met à niveau automatiquement les sandboxes en cours d'exécution avec versions obsolètes
$ nemoclaw upgrade-sandboxes --check                            # vérifier ou énumérer les sandboxes restants obsolètes/inconnus
$ nemoclaw upgrade-sandboxes                                    # reconstruire manuellement les sandboxes restants en cours d'exécution avec versions obsolètes

Pour les reconstructions manuelles scriptées, utilisez nemoclaw upgrade-sandboxes --auto pour ignorer l'invite de confirmation.

Si le sandbox mis à niveau a besoin que son état d'espace de travail soit rétabli, restaurez le snapshot de pré-mise à niveau dans le sandbox en cours d'exécution. Cela restaure uniquement les répertoires d'état sauvegardés ; il ne rétrograde pas l'image du sandbox ou l'agent/runtime :

$ nemoclaw <sandbox-name> snapshot restore pre-upgrade

Ce qui Change Pendant une Reconstruction

Chaque reconstruction détruit le conteneur existant et crée un nouveau. NemoClaw protège vos données à travers le même flux de sauvegarde et restauration que nemoclaw <name> rebuild (utiliser la skill nemoclaw-user-reference):

NemoClaw préserve l'état de l'espace de travail défini dans le manifest. Avant de supprimer l'ancien conteneur, NemoClaw snapshots les répertoires d'état et les fichiers d'état durables définis dans le manifest d'agent, généralement /sandbox/.openclaw/workspace/ ; pour Hermes cela inclut aussi SOUL.md et la base de données SQLite derrière .hermes/state.db. Les credentials stockées (~/.nemoclaw/credentials.json) et les presets de politique enregistrés vivent sur l'hôte et sont re-appliqués au nouveau sandbox automatiquement.
NemoClaw ne préserve pas les changements runtime en dehors des répertoires d'état de l'espace de travail. Cela inclut les packages installés dans le conteneur en cours d'exécution avec apt ou pip, les fichiers dans des chemins non-espace de travail, et l'état en mémoire ou de processus. Si vous avez personnalisé le conteneur en cours d'exécution à l'exécution, capturez-le en tant que modifications de Dockerfile pour nemoclaw onboard --from ou un openshell sandbox download manuel avant que la reconstruction ne commence.

Les abandons avant l'étape de destruction sont non-destructifs. Le flux refuse de procéder au-delà du contrôle préalable si une credential est manquante ou au-delà de la sauvegarde si un chemin d'état défini dans le manifest ne peut pas être copié, ainsi une exécution échouée laisse le sandbox original intact et prêt à réessayer.

Consultez Backup and Restore (utiliser la skill nemoclaw-user-manage-sandboxes) pour la liste complète des garanties de préservation d'état, la rétention des snapshots et les instructions pour les sauvegardes manuelles quand le flux automatique n'est pas suffisant.

:::{note} Si la reconstruction s'arrête avec Missing credential: <KEY> Le contrôle préalable de reconstruction lit la credential du fournisseur enregistrée par votre dernière session nemoclaw onboard. Si vous avez changé de fournisseur depuis l'onboarding, par exemple d'une API distante à une configuration Ollama locale, le contrôle préalable peut toujours référencer l'ancienne clé et échouer avant toute étape de destruction s'exécute.

Pour récupérer, relancez nemoclaw onboard et sélectionnez votre fournisseur actuel. Cela rafraîchit les métadonnées de la session. Votre conteneur existant continue à servir le trafic jusqu'à ce que la nouvelle image soit prête. :::

Étape 9 : Désinstaller

Pour supprimer NemoClaw et toutes les ressources créées lors de la configuration, exécutez la commande de désinstallation intégrée de la CLI :

nemoclaw uninstall

Flag	Effet
`--yes`	Ignorer l'invite de confirmation.
`--keep-openshell`	Laisser le binaire `openshell` installé.
`--delete-models`	Supprimer aussi les modèles Ollama tirés par NemoClaw.

nemoclaw uninstall exécute l'uninstall.sh verrouillé en version qui est venu avec votre CLI installée, ainsi il ne récupère rien sur le réseau au moment de la désinstallation.

Si la CLI nemoclaw est manquante ou cassée, revenez au script hébergé :

curl -fsSL https://raw.githubusercontent.com/NVIDIA/NemoClaw/refs/heads/main/uninstall.sh | bash

Pour une comparaison complète des deux formes, incluant ce qu'elles récupèrent, ce qu'elles font confiance, et quand préférer chacune, consultez nemoclaw uninstall vs. l'uninstall.sh hébergé (utiliser la skill nemoclaw-user-reference).

Références

Charger references/backup-restore.md lors du téléchargement de fichiers d'espace de travail à partir d'un sandbox, de l'upload de fichiers restaurés dans un nouveau sandbox, ou de la préservation de l'état du sandbox à travers les reconstructions. Sauvegarde et restaure les fichiers d'espace de travail OpenClaw avant les opérations destructives comme les reconstructions de sandbox.
Charger references/messaging-channels.md lors de la configuration de canaux de messagerie, d'interfaces de chat ou d'intégrations sans dépendre de nemoclaw tunnel start pour les ponts. Explique comment Telegram, Discord et Slack atteignent l'agent OpenClaw en sandbox à travers les processus gérés par OpenShell et les commandes de canal NemoClaw.
Charger references/workspace-files.md quand les utilisateurs posent des questions sur SOUL.md, USER.md, IDENTITY.md, AGENTS.md ou d'autres fichiers d'espace de travail, ou lors de la préparation à la sauvegarde ou la restauration de l'état de l'espace de travail. Explique ce que sont les fichiers de personnalité et configuration d'espace de travail, où ils vivent et comment ils persistent à travers les redémarrages de sandbox.

Skills Connexes

nemoclaw-user-monitor-sandbox — Surveiller l'Activité du Sandbox (utiliser la skill nemoclaw-user-monitor-sandbox) pour les outils d'observabilité