auto-memory sync never runs on Windows: resolveAutoMemoryDir() leaves the drive colon in the project key #3303

Summary

resolveAutoMemoryDir() does not replace the drive-letter colon when deriving the project key, so on Windows it returns a path containing : inside a path segment. Windows cannot create that path, ensureMemoryDir() throws ENOENT, and doSync() swallows the error as Sync failed (non-critical).

The result: the auto-memory sync has never worked on Windows, and reports success while doing nothing.

Environment

Root cause

@claude-flow/memory/dist/auto-memory-bridge.js:

const normalized = basePath.split(path.sep).join('/');
const projectKey = normalized.replace(/[\/_]/g, '-');

The comment above it says it mirrors Claude Code's derivation. Claude Code also replaces :; this does not.

For a git root of D:\projects\elearning\v3_26:

• derived: C:\Users\<me>\.claude\projects\D:-projects-elearning-v3-26\memory
• Claude Code's actual directory: C:\Users\<me>\.claude\projects\D--projects-elearning-v3-26\memory

A colon is not legal inside a Windows path segment, so nothing downstream can be created or written.

Reproduction

const m = await import('@claude-flow/memory/dist/auto-memory-bridge.js');
console.log(m.resolveAutoMemoryDir('D:\\projects\\elearning\\v3_26'));
// C:\Users\<me>\.claude\projects\D:-projects-elearning-v3-26\memory

fs.mkdirSync('C:\\Users\\<me>\\.claude\\projects\\D:-projects-elearning-v3-26\\memory', { recursive: true });
// ENOENT: no such file or directory

End to end, before the fix:

$ node .claude/helpers/auto-memory-hook.mjs import
[AutoMemory] Importing auto memory files into bridge...
  (0 entries — the directory it looked in cannot exist)

Why it is easy to miss

doSync() catches and downgrades the failure:

} catch (err) {
  dim(`Sync failed (non-critical): ${err.message}`);
}

so the hook exits 0 and prints nothing alarming. On Windows the feature looks configured and healthy.

Suggested fix

Add : to the character class:

const projectKey = normalized.replace(/[:\/_]/g, '-');

This reproduces Claude Code's key exactly: D:\projects\elearning\v3_26 becomes D--projects-elearning-v3-26 (the drive colon is the first dash, the separator the second).

POSIX paths are unaffected — they contain no colon.

Verification after applying it

• derived path now equals Claude Code's real memory directory byte-for-byte;
• node .claude/helpers/auto-memory-hook.mjs import goes from nothing to ✓ Imported 113 entries (0 skipped).

One note for whoever picks this up

Fixing the path aims curateIndex() at the user's real MEMORY.md for the first time on Windows. In my case that is safe — none of the seven DEFAULT_TOPIC_MAPPING filenames (patterns.md, debugging.md, architecture.md, performance.md, security.md, preferences.md, swarm-results.md) exist in that directory, so the #1556 guard makes curation a no-op, and I confirmed MEMORY.md was byte-identical after a sync with 113 entries loaded.

But it is worth being deliberate about: a Windows user whose memory directory happens to contain any of those filenames will have curateIndex() start rewriting their index on the first run after upgrading, where previously it silently did nothing. That is a behaviour change arriving as a bug fix.