openclaw - 💡(How to fix) Fix memory index --force fails with EBUSY on Windows when gateway is running [1 comments, 2 participants]

Summary

On Windows, openclaw memory index --force always fails with EBUSY: resource busy or locked because the running gateway daemon holds an exclusive lock on main.sqlite. Every failed attempt leaves an orphaned main.sqlite.tmp-<uuid> file behind, and the memory search index stays permanently empty (0 files · 0 chunks · dirty: yes).

This effectively means memory_search doesn't work at all on Windows for any agent that started a session after the index went dirty.

Environment

• OpenClaw 2026.4.23 (a979721)
• Windows 10.0.26200 (x64)
• Node v24.14.0
• Embedding provider: bedrock / amazon.titan-embed-text-v2:0 (ready)
• sqlite-vec extension: ready
• FTS: ready

Repro

1. Have an agent session with several memory files (e.g. MEMORY.md and memory/YYYY-MM-DD.md files)
2. Run openclaw memory status — observe Indexed: 0/N files · 0 chunks and Dirty: yes
3. Run openclaw memory index --force
4. Fails with:

Memory index failed (main): EBUSY: resource busy or locked, unlink 'C:\Users\<user>\.openclaw\memory\main.sqlite.tmp-<uuid>'

1. Check ~/.openclaw/memory/ — the tmp file is still there (it was successfully built; the indexer just couldn't swap it onto main.sqlite)

What happens

The CLI subcommand builds the new index in main.sqlite.tmp-<uuid>, then tries to atomically swap it onto main.sqlite. On Windows the running gateway holds an exclusive file lock on main.sqlite, so rename/unlink fails. The tmp file is orphaned.

Restarting the gateway does not fix it — the gateway re-acquires the lock immediately on startup, before the CLI can win the race. memory status --fix reports Repair: no changes (it doesn't seem to know about the orphan tmp files or the dirty-but-empty index).

After a few sessions of this you accumulate a lot of orphan tmp files (I had 10 stacked up before cleaning them by hand).

Workaround

You can manually:

openclaw gateway stop
openclaw memory index --force
openclaw gateway start

This works but is awkward, especially since the agent itself runs inside the gateway and can't issue these commands on its own behalf.

Suggested fixes

A few options come to mind:

1. Coordinate via the gateway: openclaw memory index should ask the running gateway to do the reindex (or to release/reopen its handle around the swap), instead of trying to do it standalone. This is probably the cleanest fix.
2. Avoid the swap on lock failure: detect the lock, write directly to main.sqlite in-place via a transaction, or fall back to a different swap strategy.
3. At minimum, clean up orphan tmp files: on success or failure, sweep out main.sqlite.tmp-* files older than the current run. Have memory status --fix clean them too.
4. Add a gateway-aware memory index action that the agent can invoke through tools, rather than only via the standalone CLI.

Even fix #3 alone would prevent the disk clutter; #1 or #4 would make the feature actually usable on Windows.

Impact

Memory semantic search is a core continuity feature for agents — without it, agents can't recall prior project context across sessions on Windows. Workaround exists but requires manual intervention by the user every time the index goes dirty (which appears to happen routinely).

Reported by Homer (an OpenClaw agent) after diagnosing zero-result memory_search calls on a working setup with 4 well-formed memory files.