Repository navigation
Memory leak: process grows to 50+ GB virtual memory over hours/days, crashes Windows #581
Description
Description
codebase-memory-mcp v0.8.1 has a severe memory leak when running as a persistent MCP server (stdio mode). Over the course of hours to ~2 days, the process grows to consume 50+ GB of virtual memory, eventually exceeding the system commit limit and crashing the entire Windows machine.
Environment
- OS: Windows 10, 64-bit (build 10.0.26100)
- codebase-memory-mcp version: v0.8.1 (installed via the official Windows .zip release, 269 MB binary)
- RAM: 32 GB physical
- Page file: system-managed
- Agent: Hermes Agent (launches codebase-memory-mcp as a subprocess via MCP stdio config)
- Single project indexed:
C:/Users/zhaid/.pi/agent(~55k nodes, ~113k edges, ~97 MB on disk) - Config:
auto_index=false,auto_index_limit=50000
Evidence
Windows Resource-Exhaustion-Detector (Event ID 2004) logged twice before the crash:
00:23:54 — 8 minutes before crash:
| Process | Virtual Memory (Commit Charge) |
|---|---|
codebase-memory-mcp.exe (PID 52508) |
46.4 GB |
python.exe (Hermes companion) |
59.4 GB |
00:28:53 — 3 minutes before crash — still growing:
| Process | Virtual Memory |
|---|---|
codebase-memory-mcp.exe (PID 52508) |
54.5 GB (+8 GB in 5 min) |
python.exe (Hermes companion) |
59.3 GB |
Combined commit of ~114 GB exceeded the system commit limit (~100 GB = 32 GB RAM + page file), triggering:
Volsnapevent 6: "The shadow copy of volume C: could not create a new page stack. The system may be low on virtual memory."OmenCommandCenterBackground.execrashed withSystem.OutOfMemoryExceptionEverything.execrashed with stack overflow (0xc00000fd)dwm.exe(Desktop Window Manager) crashed 3 timesAUDIODG.EXE(audio) crashed- Eventually Kernel-Power 41: system rebooted uncleanly
Recurrence
This has happened at least 3 times since installation (June 12):
- Jun 13: same pattern — the process consumed ~107 GB
- Jun 15: ~99 GB
- Jun 23: ~114 GB (the crash described above)
Comparison vs normal state
Right now after a fresh restart:
codebase-memory-mcp.exe PID=22416 WS=12.3 MB
Working set is 12 MB. The commit charge grows to 50+ GB over time, which is clearly a memory leak in a long-running data structure.
Suspected cause
The knowledge graph data structure (nodes, edges, PageRank scores, etc.) is being retained in process memory without eviction as the index accumulates queries and incremental updates. The on-disk index is only ~97 MB, indicating the in-memory representation is leaking by multiple orders of magnitude.
Steps to reproduce
- Run
codebase-memory-mcpin stdio MCP server mode (as Hermes/Claude Code Agent would) - Let it run for several hours to 2 days while the agent queries it
- Monitor virtual memory usage — it will climb steadily and never decrease
- Eventually the system runs out of commit charge and crashes
Note: auto_index=false does not prevent the leak — the growth happens on query/read operations, not just indexing.
Request
Please investigate the in-memory graph cache and query result retention. Consider:
- Adding an LRU eviction policy for cached query results
- Streaming graph data instead of keeping the full index in RAM
- A configurable max-memory limit that triggers compaction/eviction
Activity
DeusData commentedon Jun 23, 2026
Hey, thx for noticing. It's probably a gap in our soak test suite. Thx also for the contribution. Will check
test(repro): make the board robust to RED-test early-return leaks
test(repro): memory-budget #363 + bounded RSS-soak #581
test(soak): real multi-hour #581 soak (query-leak mode) + fix soak ti…
ci(soak): run #581 soak on ALL platforms incl. Windows
test(windows): add red regressions for hook augmenter and UI drive pi…
DeusData commentedon Jun 28, 2026
This issue now has a first-class, durable reproduction in the cumulative bug-reproduction suite landing in #667 — a test that pins the exact failing behaviour, so it's tracked and guarded against silent regression. Where #667 also lands the root-cause fix, that's called out in the PR; otherwise the reproduction makes the eventual fix straightforward and verifiable.
The reproduction goes live once #667 merges. (Posted from the release branch's QA pass.)
test(repro): honest-RED #581, honest safety-net #431 (false-guard audit)
test(repro): harden assert_no_resolvable_edge against vacuous pass
test(repro): mark #581 as a whitelisted known-red TODO
Merge pull request #673 from DeusData/qa/bug-repro-suite
Merge pull request #675 from DeusData/fix/581-leak-mitigation
15 remaining items
diag: report whether the allocator owns this build's allocations
fix(daemon): pool connection threads instead of one per connection
fix(store): install the SQLite page-cache slab before SQLite initialises
feat(diagnostics): allocation-site profiler for the #581 analysis har…
fix(windows): release the allocator thread-heap at thread exit
revert(daemon): drop the connection thread pool
revert(guards): drop the unverified launcher-guard edits
revert(windows): drop the TLS thread-heap release
revert(diagnostics): take the allocation profiler out of the build
Merge pull request #1275 from DeusData/fix/restore-thread-heap-release
fix(store): drop the SQLite page-cache slab that faults on arm64
Reapply "fix(windows): release thread heaps from a TLS detach callback"
fix: close the memory-error paths the clang-analyzer lane surfaced
fix: close the memory-error paths the clang-analyzer lane surfaced
fix(mem): route ordinary malloc through mimalloc on Linux (DeusData#1360