OpenClaw MEMORY.md manquant : diagnostiquer la première couche défaillante

Si OpenClaw dit MEMORY.md est manquant, ne créez ni ne restaurez le fichier tant que vous ne savez pas quel espace de travail et quelle session ont généré le symptôme. Le diagnostic fiable le plus court est : 1. identifier l'espace de travail actif pour l'agent concerné ; 2. prouver que MEMORY.md est un fichier normal dans cet espace de travail ; 3. confirmez que la session est autorisée à charger la mémoire privée à long terme ; 4. distinguer un marqueur d'amorçage manquant d'une copie injectée tronquée ; 5. tester la fraîcheur de la recherche uniquement après la réussite des vérifications d'amorçage. Ces contrôles répondent à différentes questions. La réindexation ne peut pas réparer le mauvais espace de travail. La recréation d'un fichier ne peut pas corriger l'exclusion intentionnelle de session partagée. L'augmentation d'un budget rapide ne peut pas restaurer un fichier absent sur le disque. OpenClawLa documentation actuelle de rend la limite inhabituellement claire : les fichiers Markdown dans l'espace de travail sont la source durable, MEMORY.md est la couche à long terme organisée chargée au début de la session et détaillée memory/YYYY MM DD.md les notes sont récupérées via des outils de mémoire plutôt que injectées à chaque tour. Cette conception crée plus d’une signification légitime au terme « disparu ». Prouvez d’abord quel espace de travail est actif OpenClawL'espace de travail par défaut de est normalement ~/.openclaw/workspace , mais ce n'est qu'un défaut. Un profil peut sélectionner un espace de travail suffixé, OPENCLAW WORKSPACE DIR peut remplacer la valeur par défaut et un agent autre que celui par défaut peut avoir son propre espace de travail configuré. Un fichier dans un répertoire ancien ou frère est réel mais sans rapport avec la session utilisant un autre répertoire. Demandez au runtime ses valeurs résolues au lieu de les déduire du répertoire actuel du shell : Choisissez l'agent concerné à partir de cette sortie. Inspectez ensuite les métadonnées, pas le contenu : Sur macOS, utilisez stat f 'type=%HT bytes=%z modified=%Sm' plutôt. Conservez le chemin privé exact dans la preuve de l'opérateur local ; un reçu de santé exporté n'a besoin que d'un identifiant d'espace de travail opaque, activeWorkspaceMatches , fileExists , regularFile , le nombre d'octets et l'heure de modification. L'ordre compte : L'espace de travail actif ne correspond pas au chemin inspecté : classifier WRONG WORKSPACE . Réparez la configuration de l'agent ou du profil, ou migrez intentionnellement le fichier après avoir examiné les deux copies. N’écrasez pas silencieusement l’un ou l’autre des espaces de travail. Le chemin actif correspond mais le fichier est absent : classifier MISSING ON DISK . Décidez si cet agent a réellement besoin d’une mémoire à long terme organisée. MEMORY.md est facultatif ; openclaw setup workspace <path peut générer des valeurs par défaut manquantes sans écraser les fichiers existants. Le chemin existe mais n'est pas un fichier standard éligible : classifier UNSUPPORTED FILE TYPE . Ceci est particulièrement pertinent pour l’amorçage en bac à sable. La documentation actuelle de l'espace de travail indique que les copies de départ du bac à sable acceptent les fichiers normaux de l'espace de travail et ignorent les alias de liens symboliques ou de liens physiques qui se résolvent en dehors de l'espace de travail source. Le fichier est un fichier normal dans l'espace de travail actif : n'appelez pas la couche de stockage cassée. Passez à la portée de la session et aux preuves d'amorçage. Cette première étape évite une fausse réparation courante : trouver un MEMORY.md quelque part sur le disque et en supposant que l'agent concerné l'utilise. Un fichier peut exister et être toujours absent d'une invite La question suivante n’est pas « le shell peut il lire le fichier ? C'est "qu'est ce qui a fait OpenClaw injecter pour cette séance ? » Dans la session concernée, utilisez : Le rapport contextuel distingue la taille brute du fichier de la taille injectée et expose la troncature. openclaw doctor peut également signaler des problèmes d'amorçage. Enregistrez le résultat sous la forme d'une petite énumération : present , missing marker , truncated , ou not loaded plutôt que de copier le texte de la mémoire dans un ticket d'incident. Actuel OpenClaw le comportement crée trois branches importantes : Un marqueur manquant n'est pas un crash. Lorsqu'un fichier bootstrap est absent, OpenClaw injecte un marqueur de fichier manquant et continue. Ce marqueur est une preuve de l'espace de travail résolu au moment de la construction de la session. C'est plus fort que l'affirmation en langage naturel d'un agent selon laquelle il « ne peut pas se souvenir », mais cela ne vous indique toujours pas pourquoi le fichier est absent. Une copie tronquée n'est pas un fichier manquant. OpenClaw conserve le fichier intact sur le disque tout en tronquant la copie injectée lorsqu'un budget d'amorçage est dépassé. Les valeurs par défaut documentées sont de 20 000 caractères par fichier et de 60 000 caractères dans les fichiers d'amorçage. Si /context detail troncature des rapports, classification BOOTSTRAP TRUNCATED . Déplacer le matériel détaillé dans memory/ .md , raccourcissez la couche organisée ou augmentez délibérément les limites après avoir pris en compte le coût rapide. Restaurer le fichier ne résoudrait rien. La mémoire privée peut être intentionnellement hors de portée. Les instructions relatives à l'espace de travail indiquent qu'il faut charger MEMORY.md uniquement dans la session privée principale, pas dans des contextes partagés ou de groupe. Un fichier présent sur le disque mais non chargé dans une session partagée est SCOPE EXCLUDED , pas malsain. Changer cette limite pour qu'un chèque devienne vert pourrait entraîner une fuite du contexte privé. La règle pratique est la suivante : Cette priorité place délibérément la confidentialité avant la disponibilité. Un opérateur ne doit pas « réparer » une session partagée en injectant de la mémoire privée durable. Gardez le chargement du bootstrap et la recherche de mémoire dans des voies séparées MEMORY.md injection de démarrage et memory search sont liés, mais ce ne sont pas les mêmes mécanismes. Le fichier organisé peut être présent dans une invite de session principale alors que la récupération indexée est obsolète. À l'inverse, la recherche en mémoire peut renvoyer une note quotidienne tandis que la copie bootstrap de MEMORY.md est manquant ou tronqué. Ce n'est qu'après la réussite de l'espace de travail, de l'éligibilité des fichiers, de la portée et de l'injection d'amorçage que vous devez exécuter : Utilisez un canari créé pour le test, et non une phrase privée copiée de la mémoire à long terme. Enregistrez si l'index est récent et si l'ID d'enregistrement opaque du Canary a été renvoyé. N'exportez pas la phrase. Un résumé brut d’un court secret est également dangereux car il peut être deviné hors ligne. Deux classifications en aval sont utiles : SEARCH STALE : le fichier est chargé, mais l'index signale un état en attente ou sale. La réindexation est pertinente ici. RETRIEVAL MISS : l'index prétend être frais, mais le canari connu n'est pas renvoyé. Inspectez la couverture des sources, la configuration du backend et le comportement des requêtes. Aucun des deux États ne justifie le remplacement MEMORY.md . La réparation de la recherche ne commence qu'une fois que l'état du fichier et du bootstrap est prouvé. L'historique OpenClaw problème 9307 est un avertissement utile concernant la confusion des couches : son OpenClaw Le rapport 2026.2.2 3 comprenait les deux ENOENT lit les fichiers de mémoire et les échecs de synchronisation séparés de l'observateur/de la recherche. Cela ne prouve pas que le même bug existe dans la version actuelle. OpenClaw. Il est prouvé qu’un incident peut contenir plusieurs couches défaillantes. Reproduire la décision avant de toucher à la production Le classificateur suivant n'utilise aucun contenu de mémoire et code la priorité de la première couche défaillante : J'ai rejoué huit appareils selon cette priorité exacte : une session principale saine, un fichier absent, un espace de travail incorrect, un lien sandbox rejeté, une exclusion de session partagée, une copie d'amorçage tronquée, un index sale et un échec de canari d'index frais. Tous les huit ont produit le classement attendu. Cette expérience expose le principal résultat opérationnel : six états non sains peuvent être décrits par une personne comme « la mémoire manque », mais chacun nécessite une réponse différente. Utilisez cette matrice de réparation après classification : Classification La plus petite action raisonnable Vérification WRONG WORKSPACE Corrigez le chemin d'accès à l'agent/au profil sélectionné ou effectuez une migration révisée Une nouvelle session principale résout l'ID d'espace de travail opaque prévu MISSING ON DISK Semez ou créez le fichier organisé facultatif uniquement si nécessaire Rapports d'une nouvelle séance present , pas seulement une commande d'écriture réussie UNSUPPORTED FILE TYPE Remplacez l'alias par un fichier régulier approuvé dans l'espace de travail Les sessions Sandbox et hôtes s'accordent sur l'éligibilité SCOPE EXCLUDED Préserver la limite de confidentialité La session principale privée le charge ; la session partagée ne fonctionne pas BOOTSTRAP LOAD FAILURE Inspecter les autorisations, la vue d'exécution et la préparation du bootstrap /context detail signale une copie injectée différente de zéro BOOTSTRAP TRUNCATED Organisez ou ajustez délibérément les budgets rapides Le canari sensible à l'action requis reste dans la partie injectée SEARCH STALE Reconstruisez ou attendez l'index en fonction du backend actif La fraîcheur de l'index et la récupération des canaris sont toutes deux réussies RETRIEVAL MISS Inspecter la couverture source et la configuration de récupération Le même canari délimité revient par ID opaque Ne vous arrêtez pas à « la commande a réussi ». Le résultat est un reçu de nouvelle session indiquant l'espace de travail prévu, le fichier éligible, la portée correcte, l'état d'amorçage non manquant et, uniquement lorsqu'une recherche est requise, un index actuel et une récupération Canary. Une limite demeure : ce reçu prouve le transport et la disponibilité, et non la vérité sémantique. Il ne peut pas établir qu'une décision mémorisée est correcte, actuelle ou toujours autorisée. La mémoire sensible aux actions a toujours besoin d’un propriétaire, d’une portée, d’une expiration et d’une limite d’approbation. Où Sidewisp convient C’est le genre de contrat de preuves qu’une couche de santé d’un agent IA devrait présenter : première couche défaillante, impact, fraîcheur, confiance, plus petite action sûre et vérification post action. Il ne devrait pas être téléchargé MEMORY.md , révéler les chemins privés ou appeler une réindexation d'une récupération avant le retour du comportement de mémoire attendu. Sidewisp est actuellement en préversion privée. Son moteur de suivi de production et OpenClaw l'adaptateur ne sont pas fournis dans le référentiel actuel du site Web, donc Sidewisp n’inspecte ni ne répare actuellement cette condition. L'orientation du produit est d'ajouter une couche de santé autour des environnements d'exécution existants et de conserver l'autorité humaine sur la récupération. Tu peux rejoignez la liste d'attente de l'aperçu privé si cette limite correspond à la façon dont vous exploitez les agents. Sources primaires Présentation de la mémoire OpenClaw rôles de fichiers, chargement au démarrage, notes quotidiennes indexées et troncature d'amorçage. Espace de travail de l'agent OpenClaw résolution de l'espace de travail, éligibilité aux graines du bac à sable, marqueurs manquants, budgets rapides et portée de la session privée. Problème OpenClaw 9307 — preuves historiques de l'incident 2026.2.2 3, conservées uniquement avec les limites de cette version.