Summary

openclaw memory status --deep reports Dirty: yes immediately after a successful openclaw memory status --deep --index (which reports Dirty: no) even when no memory files change. This looks like a CLI/status semantics issue: dirty appears to be an in-memory flag that is re-initialized to true in a fresh process.

Environment

• OpenClaw: 2026.2.3-1 (macOS arm64)
• Memory backend: builtin
• MemorySearch provider: openai (text-embedding-3-small), sqlite-vec enabled
• Workspace: ~/ .openclaw/clawd

Steps to Reproduce

1. Run:

   openclaw memory status --deep --index --json

   Observe dirty: false (and indexing completes).
2. Immediately run:

   openclaw memory status --deep --json

   Observe dirty: true.
3. Confirm no memory files changed (optional): stat/ls -lt on MEMORY.md and memory/*.md.

Expected

After a successful sync/index with no file changes, memory status should report not-dirty (or at least should not default back to dirty in a new invocation).

Actual

A subsequent memory status invocation reports dirty again.

Evidence / Root cause hint

In the distributed build, MemoryIndexManager sets dirty on construction:

• File: /opt/homebrew/lib/node_modules/openclaw/dist/manager-rDmdE7O9.js
• Around line ~1397:

  this.dirty = this.sources.has("memory");

This makes every fresh process start with dirty=true whenever the memory source is enabled, which makes openclaw memory status output misleading.

Suggested fix

• Persist a proper dirty state (e.g., compare file hashes/mtimes vs DB meta) for status, or
• Rename output to clarify semantics (e.g., processDirty vs fsDirty), or
• Initialize dirty from a persisted meta flag instead of sources.has("memory").