check_index_coverage: freshness=metadata_changed for every file, immediately after a full re-index (Windows) #1714

Version

codebase-memory-mcp 0.10.6 (also reproduced on 0.10.3)

Platform

Windows (x64) — Windows 11 build 26200, NTFS, system timezone UTC+02:00

Install channel

GitHub release archive / install.sh / install.ps1

Binary variant

standard

What happened, and what did you expect?

check_index_coverage returns freshness: "metadata_changed" with recommended_action: "read_source_and_reindex" for every path, always — including files that were last modified before the index was written, checked seconds after a successful full re-index. status stays no_recorded_issue and coverage is empty. The graph itself is correct and in sync (verified by a create/delete round-trip through the auto-watch daemon and by get_code_snippet output matching source byte-for-byte).

Expected: freshness: "metadata_match" for unchanged files, as seen on other platforms (e.g. the report in #1613 shows metadata_match on macOS).

Impact: on Windows the freshness field carries no signal. An agent following the documented guidance ("read flagged source and qualify claims when metadata is changed") is told to distrust or re-index a graph that is actually current.

Reproduction

1. Code — one file src/greet.ts (dummy snippet) in an empty directory %TEMP%\cbm-freshness-repro, no git init:

export const greet = (name: string): string => `hello, ${name}`;

2. Commands (v0.10.6, run back to back):

codebase-memory-mcp cli --json index_repository '{"repo_path":"C:/Users/<user>/AppData/Local/Temp/cbm-freshness-repro"}'
codebase-memory-mcp cli --json check_index_coverage '{"project":"C-Users-<user>-AppData-Local-Temp-cbm-freshness-repro","paths":["src/greet.ts"]}'

3. Result — index reports status: indexed, nodes: 6, edges: 5; the coverage call ~2 s later returns:

[{
  "requested_path": "src/greet.ts",
  "path": "src/greet.ts",
  "status": "no_recorded_issue",
  "freshness": "metadata_changed",
  "recommended_action": "read_source_and_reindex",
  "coverage": []
}]

The file's mtime (09:53:36Z) is 12 s older than the index generation (09:53:48Z) and the file was not modified between the two commands, so this should be a match. Expected: metadata_match.

Controls tried on a larger repo (124 files / 1,078 nodes / 1,850 edges) — same verdict in every case:

• File age: a 12-day-old file and a freshly created file — both flagged.
• mtime precision: file touched to an exact whole second (...000000000), re-indexed, checked — still flagged.
• Timezone: identical under TZ=UTC and TZ=+02:00 (caveat: Windows binaries may ignore the env var and use the registry zone).
• Index writer: MCP-tool index_repository, the background auto-watch daemon, and the CLI — all leave the same verdict.
• Versions: 0.10.3 and 0.10.6.

Possibly related secondary observation: after the auto-watch daemon has written coverage records once, later manual/CLI full re-indexes no longer advance generation/recorded_at in the coverage metadata (they stayed frozen at the daemon's timestamp across three subsequent full re-indexes from two binary versions), while an MCP-path re-index earlier in the same session did bump them. May share a root cause with the session-scoped auto-watch behavior described in #1660.

Related issues (different symptoms, same family): #841 (watcher considers unchanged directories dirty on Windows — suspects mtime granularity), #1613 (metadata_match works on macOS), #1381 (same tool, corrupted scope echo on Windows).

Logs

No errors on stderr — only the usual allocator startup lines (mem.allocator.preloading_completed ..., mem.init budget_mb=...). The JSON payloads above are the full signal.

Project scale

Dummy repro: 1 file / 6 nodes / 5 edges. Original observation: 124 files / 1,078 nodes / 1,850 edges.

Confirmations

• I searched existing issues and this is not a duplicate.
• My reproduction uses shareable code (a dummy snippet or a public OSS repository), not proprietary code.