OpenClaw Reset Memory: Prove the Scope Before Wiping State

OpenClaw reset memory is not one operation. A chat /new or /reset , a memory index rebuild, and the destructive openclaw reset CLI act on different layers. If the problem is a stale conversation, a full CLI reset is the wrong default: the documented full scope removes the state directory, shared SQLite database, and workspace directories—including the Markdown files that hold durable memory. The safe default is: 1. identify the first failed layer; 2. choose the narrowest action that can repair it; 3. inspect the destructive plan with a dry run; 4. create and verify a backup that covers every layer you intend to preserve; 5. obtain explicit approval; 6. verify configuration, memory files, search readiness, and the intended outcome after recovery. A dry run is evidence about the plan. It is not a backup, and command completion is not proof that wanted memory survived. Decide which “reset” you actually mean OpenClaw’s memory documentation says durable memory lives in plain Markdown files in the agent workspace. USER.md holds stable profile directives, MEMORY.md holds curated durable facts and decisions, and memory/YYYY MM DD.md files hold working notes. Search tools index those sources, but the index is not the source of truth. That creates at least four different symptoms that people compress into “reset memory”: Symptom First layer to inspect Reasonable first action The current conversation has drifted Session context Save durable decisions, then start a new session Search misses a known Markdown fact Memory index or provider Check memory status and rebuild the index MEMORY.md or daily notes are wrong Workspace Markdown Correct or restore the affected file, then reindex Local config, credentials, sessions, or state are irreparably inconsistent Installation state Plan the narrowest documented CLI reset scope These actions are not interchangeable. Starting a fresh session should not erase durable Markdown. Rebuilding a derived index should not require deleting the workspace. Editing a bad memory entry should not delete credentials. The destructive CLI belongs at the end of diagnosis, not the beginning. The official openclaw reset reference currently defines three scopes: Scope Documented removal boundary Gateway stopped first config Config file only No config+creds+sessions Config, OAuth/credentials directory, and per agent session directories Yes full State directory, shared SQLite database, and workspace directories Yes The right scope follows the diagnosed layer. A session symptom does not justify full . A malformed config does not justify deleting credentials and sessions. If the operator cannot name the broken layer, the state is uncertain and destructive work should wait. Before even considering the CLI, collect content free evidence: This receipt does not store prompts, memory contents, secrets, or absolute private paths. It records the decision boundary. Read the dry run, not just its exit code The CLI exposes dry run . Use it with the exact scope under consideration: This command is non destructive, but the output still needs interpretation. Record the planned gateway stop, every resolved removal target, any refusal, and the onboarding step expected afterward. A zero exit code alone is too weak. I ran the equivalent full scope dry run against OpenClaw 2026.7.1 2 on 2026 07 30. It recommended creating a backup, planned to stop the gateway, then reported that the state and workspace paths were unsafe to remove on that installation. That observation is host specific; it does not mean all full resets fail. It proves a more useful point: dry run success and target resolution are separate facts . Use a small plan record: The correct classification is reset plan blocked , not ready to reset . Do not work around a safety refusal by manually deleting broad directories. Diagnose why the target was rejected or choose a narrower supported action. The same rule applies when the dry run reveals more than expected. If an operator wanted to clear session state but the plan includes the workspace, stop. A destructive plan that reaches an unapproved layer is overscoped even if it is technically executable. Verify the recovery artifact before deleting state The reset documentation says to run openclaw backup create first. The stronger operating rule is to create and verify the archive: Choose a private destination with enough space, suitable permissions, encryption, and retention controls. OpenClaw archives can contain config, auth profiles, channel or provider credentials, sessions, plugin state, databases, and workspaces. Treat them with the same sensitivity as the live state. The official openclaw backup reference documents several important boundaries: the archive contains a manifest with resolved sources and layout; existing archives are not overwritten; output paths inside backed up source trees are rejected; verification checks declared payloads and archive path safety; canonical SQLite databases receive shape, integrity, and role checks; volatile transcript, log, socket, PID, and temporary files can be skipped; plugin owned schemas may remain opaque when their owner defined capabilities are unavailable. That final limitation matters. A verified archive is much stronger than “a file exists,” but it is not a universal proof that every plugin can be restored on every target host. Preview coverage before writing the archive: On the same observed installation, the JSON listed the state directory as the archive asset and marked the nested workspace as covered rather than listing it as a second asset. Counting assets would have produced the wrong conclusion. Inspect sourcePath , archivePath , coveredBy , and skip reasons instead. For a reset that may remove workspaces, require all of these before approval: the backup command completed; archive verification passed; the manifest covers the intended state and workspace; skipped volatile files are acceptable for the recovery objective; the archive is outside the deletion boundary; the operator can identify the restore procedure; the backup destination is protected. Gate the reset with nine inconvenient cases The accompanying content free fixture tests the decision rather than performing any reset. Its classifier applies this precedence: 1. reject an unknown scope; 2. reject a scope broader than the diagnosed layer; 3. require a completed dry run; 4. require every intended target to resolve; 5. require a verified backup; 6. require workspace coverage for a full reset; 7. wait for explicit approval; 8. after execution, verify config and memory; 9. verify the intended task outcome. The nine fixture results were: All nine matched their expected state, and a separate assertion proved that an unknown destructive scope fails closed. The distinction between the last three states prevents false success. ready to reset means the plan, backup, scope, and authority gates passed. It does not mean the reset already happened. memory unverified means execution completed but one or more post reset checks are missing. Only verified reset requires the intended outcome too. A practical post reset receipt can stay content free: File presence alone is insufficient. Check the expected durable files, then test index readiness and retrieve a deliberately non sensitive canary. Finally, run one bounded task whose result can be checked at its destination. A fluent reply does not prove that restored memory influenced the intended work correctly. Know what this gate cannot prove The fixture validates fields and precedence. It does not execute OpenClaw, inspect private memory contents, restore an archive on a second host, or discover undocumented external effects. A real recovery drill should periodically restore into an isolated destination and test the exact runtime and plugins that matter. It also does not turn every memory complaint into an incident. A fresh session can legitimately lack unsaved conversational context. A search result can be empty because the fact was never written. An index can be rebuilding. These are different from durable memory deletion, and uncertainty should remain visible until the first failed layer is known. The operating rule is simple: preserve source memory before repairing derived state, prefer the smallest supported boundary, and demand evidence after the action. Never upgrade “the command returned” into “the agent recovered.” Sidewisp is currently in private preview. Its production OpenClaw adapter and recovery executor are not generally shipped. The method here is an inspectable operating pattern, not a claim that Sidewisp currently backs up, resets, or restores live OpenClaw installations. Sidewisp’s product direction keeps diagnosis, human authority, and verified outcomes separate so a destructive action cannot clear an issue merely because it ran.