Summary

clawdbot status and clawdbot memory status always show the memory index as "dirty", even when all files are indexed and the gateway's in-process index is clean.

Root Cause

In dist/memory/manager.js (~line 144), the MemoryIndexManager constructor unconditionally sets:

this.dirty = this.sources.has("memory"); // always true when sources include "memory"

The CLI commands (clawdbot status, clawdbot memory status) create a fresh MemoryIndexManager instance in dist/commands/status.scan.js (~line 101). This new instance starts with dirty = true, calls probeVectorAvailability() and status(), then closes — never running a sync that would clear the flag.

So the CLI can never report dirty: no unless --deep --index is used (which forces a sync within that process).

Steps to Reproduce

1. Run clawdbot memory index (full reindex, completes successfully)
2. Run clawdbot status or clawdbot memory status
3. Memory still shows "dirty"

Expected Behavior

Status should reflect the actual index state. If all files are indexed and no changes are pending, dirty should be no.

Possible Fixes

• Query the running gateway's in-process dirty state instead of creating a new manager instance
• Don't default dirty = true on construction; instead compare file mtimes against indexed timestamps
• Run a lightweight dirty check (e.g. hash comparison) in the status path without requiring a full sync

Workaround

clawdbot memory status --deep --index forces a sync and temporarily clears the flag, but only for that CLI invocation.

Environment

• Version: 2026.1.24-3
• OS: Linux 6.14.0-37-generic (x64)
• Node: v22.22.0
• Memory provider: openai (via Ollama, nomic-embed-text)