Memory leak: RSS grows without bound and is not released after indexing (still present on latest release)

[proudCrisa]

Version

Latest published GitHub release (v0.10.8). This report does not include a host-specific --version dump.

Platform

Omitted on purpose. The phenomenon is about process RSS growth of the long-lived MCP server / daemon / index worker, not a single-OS UI glitch.

Install channel

Omitted on purpose.

Binary variant

Omitted on purpose.

What happened, and what did you expect?

Actual

The long-lived codebase-memory-mcp process keeps growing resident memory during indexing and while the MCP server stays up. After an index pass finishes, RSS does not fall back to a small idle baseline. Growth is far larger than the on-disk graph, continues over time, and is severe enough to starve the rest of the machine and make the MCP unusable.

The logged memory budget (budget_mb / memory_budget_bytes) does not stop the growth. It appears to be accounting only: RSS can overshoot it by a large factor, and unused arenas/heap are not returned to the OS.

Expected

• After indexing completes, unused memory is released to the OS.
• The published memory budget actually caps growth (or the run fails with a clear overshoot error) instead of only being printed in logs.
• A long-lived MCP daemon should stay near a stable idle RSS between index passes, not climb until the host is unusable.

Reproduction

This is a long-running resource leak, not a single-file parse failure. No private code, paths, or host details are attached.

1. Run codebase-memory-mcp as an MCP server against a real workspace (background auto-index / watcher is enough to trigger).
2. Let indexing or a later reindex run.
3. Watch process RSS: it climbs far beyond indexed graph size and the logged budget.
4. After the pass, RSS stays high instead of returning to a small idle baseline.
5. Further use / reindex makes it worse until the host is unusable.

Logs

Omitted on purpose (no host-specific logs).

Diagnostics trajectory (memory / performance / leak issues)

Omitted on purpose (no host-specific trajectory).

Project scale (if relevant)

Omitted on purpose. The leak is not explained by graph size: RSS is large relative to the indexed data and does not come down after the pass.

Confirmations

• I searched existing issues. Related open reports include Memory not released after indexing: 20GB+ RSS for 5MB of indexed data #832, Memory leak: process grows to 50+ GB virtual memory over hours/days, crashes Windows #581, CPU memory usage is too high #1084, bug: memory runaway (12.8GB+ RSS) during index_repository on root paths triggers OOM crash #1241, Daily OOM crash-loop: worker RSS far exceeds its own memory budget, then full reindex retriggers on every crash #1864, Full index build allocates ~11.5 GB on a ~14k-file TypeScript monorepo regardless of the configured memory budget (0.10.8) #1997. This is filed because the leak is still unfixed on the latest published release, not because it is believed to be a brand-new unique bug.
• No proprietary code is included.

Related status (public, already on GitHub)

• Maintainer comment on Memory not released after indexing: 20GB+ RSS for 5MB of indexed data #832 (2026-08-14): budget is reported but not enforced; status was not fixed.
• Independent confirmations on v0.10.8 remain open (Memory not released after indexing: 20GB+ RSS for 5MB of indexed data #832 follow-ups, Daily OOM crash-loop: worker RSS far exceeds its own memory budget, then full reindex retriggers on every crash #1864, Full index build allocates ~11.5 GB on a ~14k-file TypeScript monorepo regardless of the configured memory budget (0.10.8) #1997).
• v0.10.8 release notes do not include a leak/RSS fix.

Please treat this as another confirmation that unbounded RSS growth remains a daily-use blocker on the latest release.

[DeusData]

Thank you for confirming that the memory-budget problem is still present on the latest published release.

This is a direct match for #832, which tracks the same unbounded indexing RSS and unenforced budget and now also contains fresh v0.10.8 measurements plus the containment proposal in #2030. Keeping the diagnosis and measurements on one thread will make the eventual fix easier to verify.

I am closing this as a duplicate of #832. Your confirmation remains useful evidence and is reflected in the canonical issue. Thank you for taking the time to report it clearly.

[github-actions]

Thanks for raising this! It looks like a duplicate of an existing issue — the canonical one is linked above. Continuing the discussion there keeps everything in one place. We leave this open for visibility; a maintainer will close it once it's fully covered.