Bug type

Behavior bug (incorrect output/state without crash)

Summary

On Windows, openclaw memory search can consistently trigger EBUSY: resource busy or locked during memory sync, even when the memory store is otherwise healthy and memory status --deep reports vector/FTS/embeddings all ready.

The failure happens during the atomic reindex / swap path when OpenClaw tries to rename the live memory database:

main.sqlite -> main.sqlite.backup-<uuid>

This appears to be a Windows file-lock issue in the memory atomic reindex / backup rename path, not a user config error.

Steps to reproduce

1. Run OpenClaw on Windows with builtin memory search enabled.
2. Ensure memory search is configured and healthy. In my case:
   • OpenClaw 2026.4.9
   • Windows 11
   • agents.defaults.memorySearch.provider = "openai"
   • model = text-embedding-v4
   • remote OpenAI-compatible embedding endpoint
3. Confirm memory health:

   openclaw memory status --deep --json

   It reports:
   • dirty: false
   • vector.available: true
   • fts.available: true
   • custom.searchMode: "hybrid"
4. Run:

   openclaw memory search --query "用户名字 老巨 助手名字 小小巨 gstack" --json

5. Observe empty results plus lock errors:

   [memory] sync failed (session-start): Error: EBUSY: resource busy or locked, rename 'C:\Users\woshi\.openclaw\memory\main.sqlite' -> 'C:\Users\woshi\.openclaw\memory\main.sqlite.backup-...'
   [memory] sync failed (search): Error: EBUSY: resource busy or locked, rename 'C:\Users\woshi\.openclaw\memory\main.sqlite' -> 'C:\Users\woshi\.openclaw\memory\main.sqlite.backup-...'
   

Expected behavior

openclaw memory search should either:

• search successfully, or
• gracefully retry / recover from transient Windows file locks,

without failing the sync path on fs.rename() of the live sqlite database.

Actual behavior

memory status --deep reports the store as healthy, but memory search still triggers sync/recovery logic that attempts to rename the live DB file and hits EBUSY on Windows.

This also sometimes causes related warnings such as:

chunks written for MEMORY.md without vector embeddings — chunks_vec not updated (sqlite-vec unavailable). Vector recall degraded for this file.

Even though later health checks show vec is available again.

OpenClaw version

2026.4.9

Operating system

Windows 11

Install method

npm global / local gateway

Model

Not model-dependent for reproduction. Main agent model was openai-codex/gpt-5.4.

Provider / routing chain

Memory embeddings were configured through the builtin memory-core path using:

• provider: openai
• model: text-embedding-v4
• remote OpenAI-compatible endpoint

The bug appears independent of the embedding provider itself, because the failure occurs at sqlite file swap / rename time.

Logs, screenshots, and evidence

Observed logs:

[memory] sync failed (session-start): Error: EBUSY: resource busy or locked, rename 'C:\Users\woshi\.openclaw\memory\main.sqlite' -> 'C:\Users\woshi\.openclaw\memory\main.sqlite.backup-630993e5-3b8a-4a97-84bf-7caf27f610ed'
[memory] sync failed (search): Error: EBUSY: resource busy or locked, rename 'C:\Users\woshi\.openclaw\memory\main.sqlite' -> 'C:\Users\woshi\.openclaw\memory\main.sqlite.backup-630993e5-3b8a-4a97-84bf-7caf27f610ed'
[memory] chunks written for MEMORY.md without vector embeddings — chunks_vec not updated (sqlite-vec unavailable). Vector recall degraded for this file.
[memory] chunks written for memory/2026-04-10.md without vector embeddings — chunks_vec not updated (sqlite-vec unavailable). Vector recall degraded for this file.
[memory] sync failed (watch): Error: EBUSY: resource busy or locked, rename 'C:\Users\woshi\.openclaw\memory\main.sqlite' -> 'C:\Users\woshi\.openclaw\memory\main.sqlite.backup-2d1941f4-a398-4d76-a6fd-af80ed77c845'

Doctor / status after repair still showed healthy memory state:

{
  "dirty": false,
  "provider": "openai",
  "model": "text-embedding-v4",
  "fts": { "available": true },
  "vector": { "available": true },
  "custom": { "searchMode": "hybrid" }
}

Running:

openclaw memory status --fix

reported:

Repair: rewrote store

which restored the store, but did not eliminate later EBUSY repros from openclaw memory search.

Restarting the gateway also did not fix the reproduction.

Likely root cause

I inspected main branch code and found the atomic reindex path still does a direct rename-based swap in:

• extensions/memory-core/src/memory/manager-atomic-reindex.ts

Specifically:

• swapMemoryIndexFiles(targetPath, tempPath)
• moveMemoryIndexFiles(sourceBase, targetBase)
• await fs.rename(source, target)

Current main still appears to:

1. rename targetPath to targetPath.backup-<uuid>
2. rename tempPath into place
3. restore on failure

I did not find Windows-specific retry/backoff handling for EBUSY/EPERM/EACCES, nor a copy-based fallback.

This strongly suggests the bug is in the Windows handling of the atomic reindex / backup rename path, not in user config.

Impact and severity

• memory search can fail or return empty results despite healthy memory status
• users may see misleading vec degradation warnings
• the store can be repaired, but the issue is reproducible again from normal search flows
• affects confidence in semantic memory on Windows

Additional information

Related upstream context I found while investigating:

• Issue Bug: CLI memory search returns empty results despite embedding model and vector data being correct #30587: CLI memory search returns empty despite vector data being correct
• Issue [Bug]: openclaw status loads memory plugins locally and can report false vector state #62599: CLI status can initialize memory runtime locally and report misleading state
• Issue [Bug]: Gateway crashes with EBUSY errors when .openclaw is synced via cloud storage #39446: OpenClaw has known EBUSY sensitivity around file operations under lock contention

I think this bug likely needs one or more of:

• Windows retry/backoff around rename in atomic memory swap
• stricter DB/vec handle release before rename
• copy-and-replace fallback when rename fails on Windows
• reducing when CLI memory search triggers local sync/reindex paths