OpenClaw Réinitialiser la mémoire: Prouver la portée avant de supprimer l'état

La mémoire de réinitialisation OpenClaw n'est pas une opération. Un chat /new ou /reset , une reconstruction de l'index de mémoire et le destructeur openclaw reset CLI agissent sur différentes couches. Si le problème est une conversation obsolète, une réinitialisation complète de CLI est la défaillance par défaut: la portée documentée de full supprime le répertoire d'état, la base de données SQLite partagée et les répertoires de l’espace de travail, y compris les fichiers Markdown qui contiennent une mémoire durable. La garantie par défaut est: 1. identifier la première couche défaillante; 2. choisir l'action la plus étroite qui puisse la réparer; 3. inspecter le plan de destruction à sec; 4. créer et vérifier une sauvegarde qui couvre chaque couche que vous avez l'intention de préserver; 5. obtenir une approbation explicite; 6. vérifier la configuration, les fichiers mémoire, la préparation à la recherche et le résultat prévu après la récupération. Une course à sec est une preuve du plan. Ce n'est pas une sauvegarde, et l'achèvement de la commande n'est pas la preuve que la mémoire souhaitée a survécu. Décidez de quelle réinitialisation vous voulez dire Documentation de mémoire OpenClaws dit que la mémoire durable vit dans des fichiers simples Markdown dans l'espace de travail de l'agent. Le USER.md contient des directives de profil stables, le MEMORY.md contient des faits et des décisions durables, et les fichiers memory/YYYY MM DD.md contiennent des notes de travail. Les outils de recherche indexent ces sources, mais l'index n'est pas la source de la vérité. Cela crée au moins quatre symptômes différents que les gens compressent dans la mémoire réinitialisée: Les symptômes Première couche à inspecter Première action raisonnable La conversation actuelle a dérivé Context de la session Épargnez des décisions durables, puis commencez une nouvelle session La recherche manque un fait connu Markdown Indice de mémoire ou fournisseur Vérifiez l'état de la mémoire et reconstruisez l'index MEMORY.md ou les notes quotidiennes sont erronées espace de travail Markdown Correction ou restauration du fichier affecté, puis réindexation La configuration locale, les informations d'identification, les sessions ou l'état sont irrémédiablement incohérentes État de l'installation Planifier la portée de réinitialisation CLI la plus étroite documentée Ces actions ne sont pas interchangeables. Le début d'une nouvelle séance ne doit pas effacer le Markdown durable. La reconstruction d'un indice dérivé ne devrait pas nécessiter la suppression de l'espace de travail. L'édition d'une mauvaise entrée de mémoire ne doit pas supprimer les informations d'identification. Le CLI destructeur appartient à la fin du diagnostic, pas au début. Le référence openclaw reset officiel définit actuellement trois champs d'application: Scope Limite de retrait documentée La passerelle s'est arrêtée en premier. config Seul fichier de configuration Non config+creds+sessions Config, répertoire OAuth/credentials et répertoires de sessions par agent Oui full L'annuaire d'État, la base de données SQLite partagée et les annuaires de l'espace de travail Oui La bonne portée suit la couche diagnostiquée. Un symptôme de séance ne justifie pas full . Une configuration défectueuse ne justifie pas la suppression des informations d'identification et des sessions. Si l'opérateur ne peut pas nommer la couche cassée, l'état est uncertain et le travail destructeur doit attendre. Avant même d'examiner le CLI, recueillez des preuves sans contenu: Ce reçu ne contient pas d'informations, de contenu de mémoire, de secrets ou de chemins absolument privés. Il enregistre les limites de décision. Lisez la piste à sec, pas seulement son code de sortie. Le CLI expose le dry run . Utilisez le avec la portée exacte envisagée: Cette commande est non destructive, mais la sortie a encore besoin d'interprétation. Enregistrez l'arrêt prévu de la passerelle, chaque cible de retrait résolue, tout refus et l'étape d'embarquement attendue par la suite. Un code de sortie zéro seul est trop faible. J'ai effectué une course à sec à plein champ contre OpenClaw 2026.7.1 2 le 2026 07 30. Il a recommandé de créer une sauvegarde, prévu d'arrêter la passerelle, puis rapporté que l'état et les chemins de l'espace de travail étaient dangereux à supprimer sur cette installation. Cette observation est spécifique à l'hôte; cela ne signifie pas que tous les réinitialisations complètes échouent. Il prouve un point plus utile: le succès de à sec et la résolution cible sont des faits distincts . Utilisez un petit dossier de plan: La classification correcte est reset plan blocked et non ready to reset . Ne contournez pas un refus de sécurité en supprimant manuellement de grands annuaires. Diagnostiquer pourquoi l'objectif a été rejeté ou choisir une action plus étroitement soutenue. La même règle s'applique lorsque la course à sec révèle plus que prévu. Si un opérateur veut effacer l'état de session mais que le plan inclut l'espace de travail, arrêtez. Un plan destructeur qui atteint une couche non approuvée est surestimé même s'il est techniquement exécutable. Vérifiez l'état de récupération avant de supprimer La documentation de réinitialisation dit d'exécuter openclaw backup create d'abord. La règle d'exploitation la plus stricte est de créer et de vérifier l'archive: Choisissez une destination privée avec suffisamment d'espace, des autorisations appropriées, des contrôles de cryptage et de conservation. Les archives OpenClaw peuvent contenir des config, des profils d'auteurs, des informations d'identification de canaux ou de fournisseurs, des sessions, l'état du plugin, des bases de données et des espaces de travail. Traitez les avec la même sensibilité que le vivant. Le référence openclaw backup officiel documente plusieurs limites importantes: l'archive contient un manifeste avec des sources résolues et une mise en page; les archives existantes ne sont pas écrasées; les chemins de sortie à l'intérieur des arbres de source sauvegardés sont rejetés; les contrôles de vérification des charges utiles déclarées et de la sécurité du chemin d'archives; les bases de données canoniques SQLite reçoivent des contrôles de forme, d'intégrité et de rôle; les transcripts volatils, les journaux, les prises, PID et les fichiers temporaires peuvent être omis; les systèmes appartenant à des plugins peuvent rester opaques lorsque leurs capacités définies par le propriétaire ne sont pas disponibles. Cette dernière limite est importante. Une archive vérifiée est beaucoup plus solide que un fichier existe, mais ce n'est pas une preuve universelle que chaque plugin peut être restauré sur chaque hôte cible. Couverture d'aperçu avant d'écrire l'archivage: Sur la même installation observée, le JSON a répertorié le répertoire d'État comme actif d'archives et a marqué l'espace de travail niché comme covered plutôt que de le répertorier comme un deuxième actif. Le comptage des actifs aurait conduit à une conclusion erronée. Inspectez sourcePath , archivePath , coveredBy , et sautez les raisons à la place. Pour une réinitialisation pouvant éliminer les espaces de travail, il est nécessaire avant l'approbation de: la commande de sauvegarde est terminée; la vérification des archives est passée; le manifeste couvre l'état et l'espace de travail envisagés; les fichiers volatils omis sont acceptables pour l'objectif de récupération; l'archive est en dehors de la limite de suppression; l'exploitant peut identifier la procédure de restauration; la destination de sauvegarde est protégée. Portez la réinitialisation avec neuf cas inconvenients L'appareil sans contenu qui l'accompagne teste la décision plutôt que de réinitialiser. Son classifiant applique la priorité suivante: 1. rejeter une portée inconnue; 2. rejeter un champ d'application plus large que la couche diagnostiquée; 3. nécessitent une course sèche complète; 4. exiger la résolution de toutes les cibles prévues; 5. nécessiter une sauvegarde vérifiée; 6. nécessiter une couverture de l'espace de travail pour une réinitialisation complète; 7. attendre l'approbation explicite; 8. après l'exécution, vérifier la configuration et la mémoire; 9. vérifier le résultat de la tâche prévue. Les résultats des neuf matchs ont été les suivants: Les neuf ont tous correspondu à leur état attendu, et une affirmation distincte a prouvé qu'un champ destructeur inconnu échoue à fermer. La distinction entre les trois derniers états empêche le faux succès. ready to reset signifie le plan, la sauvegarde, la portée et les portes d'autorité passées. Cela ne veut pas dire que la réinitialisation s'est déjà produite. memory unverified signifie que l'exécution est terminée mais qu'une ou plusieurs vérifications post réinitialisation manquent. Seul le verified reset exige également le résultat prévu. Un reçu pratique après réinitialisation peut rester exempt de contenu: La présence de fichiers à elle seule est insuffisante. Vérifiez les fichiers durables attendus, puis testez la préparation de l'index et récupérez un canary délibérément non sensible. Enfin, effectuez une tâche limitée dont le résultat peut être vérifié à sa destination. Une réponse fluide ne prouve pas que la mémoire restaurée ait influencé correctement le travail prévu. Sachez ce que cette porte ne peut pas prouver L'appareil valide les champs et la priorité. Il n'exécute pas OpenClaw, n'inspecte pas le contenu de la mémoire privée, ne restaure pas une archive sur un deuxième hôte ou ne découvre pas d'effets externes non documentés. Un véritable exercice de récupération devrait périodiquement se restaurer dans une destination isolée et tester le temps d'exécution exact et les plugins qui comptent. Il ne transforme pas non plus chaque plainte de mémoire en un incident. Une nouvelle séance peut légitimement manquer de contexte de conversation non sauvegardé. Un résultat de recherche peut être vide parce que le fait n'a jamais été écrit. Un indice peut être reconstructif. Ils diffèrent de la suppression de mémoire durable et l'incertitude doit rester visible jusqu'à ce que la première couche échouée soit connue. La règle d'exploitation est simple: préserver la mémoire source avant de réparer l'état dérivé, préférer la plus petite limite prise en charge et demander des preuves après l'action. Ne jamais mettre à niveau la commande retournée dans l'agent récupéré. Sidewisp est actuellement en préversion privée. Son adaptateur OpenClaw de production et son exécuteur de récupération ne sont généralement pas expédiés. La méthode ici est un modèle de fonctionnement inspectable, et non une affirmation selon laquelle Sidewisp sauvegarde, réinitialise ou restaure actuellement des installations OpenClaw en direct. La direction du produit Sidewisp maintient le diagnostic, l'autorité humaine et les résultats vérifiés séparés de sorte qu'une action destructrice ne peut pas éliminer un problème simplement parce qu'il a été exécuté.