You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
[Windows] list_projects silently drops any .db file ≥ 2 GB — UI shows an empty project list
Summary
On Windows, the graph UI at http://localhost:9749 shows zero projects even
though valid <project>.db files exist in the cache directory. The list_projects
MCP tool — which the UI uses to populate the project list — returns:
In src/mcp/mcp.c, the project-DB scan uses the POSIX-flavored stat() from <sys/stat.h>. On Windows (MinGW / MSVC default), struct stat::st_size is a
32-bit long, capped at 2 GB (LONG_MAX = 2,147,483,647). For any .db file
larger than 2 GB the call fails with errno = EOVERFLOW and the file is
silently skipped, so the projects JSON array ends up empty.
The same stat()-on-a-.db mistake appears in two more places in mcp.c
with their own symptoms — see Affected call sites.
Reproduction
Windows 11, the codebase-memory-mcp-ui build (UI port 9749).
Index a large repository so the resulting .db exceeds 2 GB
Move the > 2 GB .db aside, or replace it with a < 2 GB project. The UI
immediately lists the project — confirming stat() is the only filter that
excludes it.
Why this is a real bug
No 2 GB size limit is stated anywhere in the project, so a .db larger than
2 GB is expected to work — silently dropping it is a bug, not a documented
constraint.
The failure is silent: no log line, no UI hint, no error in the JSON
response. The indexer wrote files to disk, yet the UI claims "No projects
indexed."
The fix is mechanical and the project already established the pattern
elsewhere — it just wasn't applied uniformly.
Affected call sites
All three check a project .db with stat() and break on > 2 GB:
src/mcp/mcp.c handle_list_projects stat(full_path,&st) != 0 → project dropped from UI list
src/mcp/mcp.c maybe_auto_index stat(db_check,&st) == 0 → re-indexed on every server start
src/mcp/mcp.c try_artifact_bootstrap stat(db_buf,&db_st) != 0 → wasted artifact import (overwritten by rebuild)
(build_project_json_entry also read (int64_t)st->st_size, a 32-bit value
on Windows.)
Proposed fix
Replace all three stat() calls with the existing cbm_file_size helper
(foundation/platform.c), which is wide-char + 64-bit clean on Windows
(GetFileAttributesExW) and returns int64_t on both platforms. Full
details and the diff are in the linked PR.
This is a distinct defect from the merged PR #386 (fix(windows): use wide-char API for non-ASCII path support), even though both touch the stat
surface:
fix(windows): use wide-char API for non-ASCII path support #386 fixed path encoding — non-ASCII UTF-8 paths (CJK / Cyrillic /
Turkish) by swapping stat() → _wstat64() + cbm_utf8_to_wide. Its file
list (discover.c, compat_fs.c, platform.c, win_utf8.h) does not
include mcp.c, so list_projects was never migrated.
This bug is the file-size dimension: struct stat::st_size is a 32-bit long on Windows, so a > 2 GB .db makes stat() fail with EOVERFLOW.
That is orthogonal to path encoding — an all-ASCII path to a > 2 GB file
still breaks.
Important: even if #386's wide_stat had been applied here it would not
fix this. wide_stat copies the _stat64 result back into struct stat,
whose st_size is still a 32-bit long on Windows, so the size would
truncate silently (the failure just changes shape). cbm_file_size returns
the size as int64_t, so it never passes through the 32-bit field.
Also not covered by #394 (Windows platform issues, 8 bugs) — none of its
sub-issues address the large-file / st_size-overflow class, so this is a new
entry in that cluster rather than a duplicate of existing work.
Environment
OS: Windows 11 Pro 10.0.26200
Build: codebase-memory-mcp-ui release asset (UI port 9749)
[Windows]
list_projectssilently drops any.dbfile ≥ 2 GB — UI shows an empty project listSummary
On Windows, the graph UI at
http://localhost:9749shows zero projects eventhough valid
<project>.dbfiles exist in the cache directory. Thelist_projectsMCP tool — which the UI uses to populate the project list — returns:
{"projects":[],"hint":"No projects indexed. Call index_repository(repo_path=...) first."}Root cause
In
src/mcp/mcp.c, the project-DB scan uses the POSIX-flavoredstat()from<sys/stat.h>. On Windows (MinGW / MSVC default),struct stat::st_sizeis a32-bit
long, capped at 2 GB (LONG_MAX = 2,147,483,647). For any.dbfilelarger than 2 GB the call fails with
errno = EOVERFLOWand the file issilently skipped, so the
projectsJSON array ends up empty.The same
stat()-on-a-.dbmistake appears in two more places inmcp.cwith their own symptoms — see Affected call sites.
Reproduction
codebase-memory-mcp-uibuild (UI port 9749)..dbexceeds 2 GBhttp://localhost:9749→ empty list..dbaside, or replace it with a < 2 GB project. The UIimmediately lists the project — confirming
stat()is the only filter thatexcludes it.
Why this is a real bug
.dblarger than2 GB is expected to work — silently dropping it is a bug, not a documented
constraint.
response. The indexer wrote files to disk, yet the UI claims "No projects
indexed."
elsewhere — it just wasn't applied uniformly.
Affected call sites
All three check a project
.dbwithstat()and break on > 2 GB:(
build_project_json_entryalso read(int64_t)st->st_size, a 32-bit valueon Windows.)
Proposed fix
Replace all three
stat()calls with the existingcbm_file_sizehelper(
foundation/platform.c), which is wide-char + 64-bit clean on Windows(
GetFileAttributesExW) and returnsint64_ton both platforms. Fulldetails and the diff are in the linked PR.
Relation to prior Windows work (#386 / #394)
This is a distinct defect from the merged PR #386 (
fix(windows): use wide-char API for non-ASCII path support), even though both touch thestatsurface:
Turkish) by swapping
stat()→_wstat64()+cbm_utf8_to_wide. Its filelist (
discover.c,compat_fs.c,platform.c,win_utf8.h) does notinclude
mcp.c, solist_projectswas never migrated.struct stat::st_sizeis a 32-bitlongon Windows, so a > 2 GB.dbmakesstat()fail withEOVERFLOW.That is orthogonal to path encoding — an all-ASCII path to a > 2 GB file
still breaks.
Important: even if #386's
wide_stathad been applied here it would notfix this.
wide_statcopies the_stat64result back intostruct stat,whose
st_sizeis still a 32-bitlongon Windows, so the size wouldtruncate silently (the failure just changes shape).
cbm_file_sizereturnsthe size as
int64_t, so it never passes through the 32-bit field.Also not covered by #394 (Windows platform issues, 8 bugs) — none of its
sub-issues address the large-file /
st_size-overflow class, so this is a newentry in that cluster rather than a duplicate of existing work.
Environment
codebase-memory-mcp-uirelease asset (UI port 9749)C:\Users\<user>\.cache\codebase-memory-mcp\