CPU memory usage is too high

Version

0.8.1 0.9.0

Platform

Windows (x64)

Install channel

go install

Binary variant

ui

What happened, and what did you expect?

自动索引打开就会导致cpu和内存飙高，cpu:12th Gen Intel(R) Core(TM) i5-1240P 内存：24G

Reproduction

codebase-memory-mcp config set auto_index true

Logs

Diagnostics trajectory (memory / performance / leak issues)

Project scale (if relevant)

No response

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.

Thanks for the report! To move this forward we need a bit more so we can reproduce it ourselves:

the codebase-memory-mcp --version you're on
the exact steps or command you ran
a public repo (or a small dummy snippet) that shows the problem — please don't paste proprietary code

Once that's here we'll pick it straight back up. Heads-up: issues left awaiting-reporter are automatically closed after a few weeks of silence, but a comment reopens the door anytime.

Thanks for the report. I have triaged this as a high-priority 0.9.1-rc resource-usage bug. To separate watcher churn from indexing cost, please add the project file count and main languages, the process CPU/RSS trajectory for a few minutes after enabling auto_index, and the relevant local log lines around each reindex. Marking awaiting-reporter for those diagnostics; the issue remains in 0.9.1-rc.

As per the readme, auto-index option does:

Auto-Index

Enable automatic indexing on MCP session start:

codebase-memory-mcp config set auto_index true

When enabled, new projects are indexed automatically on first connection. Previously-indexed projects are registered with the background watcher for ongoing git-based change detection. Configurable file limit: config set auto_index_limit 50000.

Can it be possible that the user may have opened a folder with more contents than a project (e.g. Downloads) and that triggered the full indexing of the folder contents?

Yes, this is possible, and a code review confirms a concrete guard gap. Current main derives the session root from the MCP server process working directory. If a client starts it from a broad folder such as Downloads, auto-index can select that entire directory. The file-limit check currently counts tracked files with git ls-files; on a non-Git directory that can report zero, allowing the broad directory to bypass the intended auto_index_limit before the full pipeline starts.

That is a stability bug independently of whether it explains the original report, and it belongs in the 0.9.1-rc work tracked here. The original reporter's diagnostics are still useful to confirm whether this was their trigger and whether watcher or worker behavior contributed as well.

auto index + auto watch, is same. v0.9.0, windows. it will cause high cpu usage when codex editing files.

This issue has been waiting on more information for 21 days (a version, exact steps, or a public repro), so it's now marked stale. It will not be closed automatically — a maintainer reviews stale issues by hand. Adding a comment with the details clears the label and puts it straight back in the queue. We're happy to pick it back up the moment we can reproduce it.

Same, my Laptop just crashed so I had to force power it off.
Before crash, I saw memory usage up to 10000mb+ (i7-11850H + 16GB)
Before that, my agent was trying to explore Codebase Memory's features, in a big Java project.
Using codebase-memory-mcp 0.9.0

Also getting this, memory explodes to consuming all available RAM. Cant kill the process and causes OS to lock up. Had to uninstall because its become unusable.

Thank you for the two fresh confirmations. I have removed awaiting-reporter: the issue is active again and is not parked on the original reporter. The reports of more than 10 GB RSS and full OS lockup keep this in the high-priority stability queue. Both recent confirmations are still on v0.9.0, so a v0.10.8 reproduction with project file count, main languages, and a short CPU/RSS trajectory would remain useful, but the issue stays active regardless.

re-installed with v0.10.8. still seeing high CPU consumption. It no longer takes up all available RAM and cause OS to lock up; however it does take up all available CPU and causes a sever OS stutter.

Let me know how I can provide additional debug info to help chase this.

fix: preserve CPU headroom during background indexing

Thank you for retesting 0.10.8 and separating the improved RAM behavior from the remaining CPU stutter. This remains on the maintainer side. If available from ordinary use, please share approximate indexed file count, main languages, whether indexing was active, and a short timestamped CPU/RSS sample identifying daemon versus worker processes. Redact paths and project names as needed. Please do not deliberately reproduce an OS lockup; I cannot yet say which process or indexing phase accounts for the CPU.

fix: preserve CPU headroom during background indexing

see verbose log from a C++ project using version 0.11.0. performance appears to be slightly better with recent version. CPU max hits 99% at times with 75% being consumed by the cbm process. let me know if you need further diagnostics

Preparing one-shot local CBM command...
level=warn msg=mem.allocator.preloading_completed still_preloading=false detail=allocator_was_still_preloading,_so_arena_creation_and_purging_were_disabled;_process_init_completed_explicitly
Running index_repository locally...
hint: this command started a temporary CBM daemon. `codebase-memory-mcp daemon start` keeps one warm and removes this startup cost from every CLI command.
Completed index_repository (58204 ms)
{
  "project": "D-Projects-Directional",
  "excluded": {
    "dirs": [
      ".cache",
      ".git",
      ".playwright-cli",
      ".vscode",
      "build"
    ],
    "count": 40,
    "truncated": true
  },
  "not_indexed_files_count": 165,
  "not_indexed_files": {
    "files": [
      {
        "path": ".polyscope.ini",
        "reason": "gitignore"
      },
      {
        "path": "AGENTS.md",
        "reason": "gitignore"
      },
      {
        "path": "imgui.ini",
        "reason": "gitignore"
      },
      {
        "path": "p.patch",
        "reason": "gitignore"
      },
      {
        "path": "python/directional/_directional.cp313-win_amd64.pyd",
        "reason": "gitignore"
      }
    ],
    "count": 165,
    "truncated": true,
    "note": "Excluded by design (gitignore/.cbmignore/skip-lists); examples only — full list in 'logfile'."
  },
  "skipped_count": 0,
  "logfile": "C:/Users/Akash/.cache/codebase-memory-mcp/logs/D-Projects-Directional-1790187275.log",
  "parse_partial_count": 1116,
  "parse_partial": {
    "files": [
      {
        "path": "external/eigen/Eigen/src/AccelerateSupport/AccelerateSupport.h",
        "error_ranges": "179-179,182-182,185-185,188-188,191-191,194-194,197-197,201-201,205-205,208-208,232-232,292-295,308-308,317-317,322-322,347-347,374-374,420-420"
      },
      {
        "path": "external/eigen/Eigen/src/Cholesky/BunchKaufman.h",
        "error_ranges": "82-82,327-327,548-548,551-551,576-576,579-579,706-706,713-713,876-876"
      },
      {
        "path": "external/eigen/Eigen/src/Cholesky/LDLT.h",
        "error_ranges": "71-71,336-336,451-451,458-458"
      },
      {
        "path": "external/eigen/Eigen/src/Cholesky/LLT.h",
        "error_ranges": "78-78,337-337,353-353,358-358"
      },
      {
        "path": "external/eigen/Eigen/src/Cholesky/LLT_LAPACKE.h",
        "error_ranges": "75-75,113-114,115-115,116-116"
      }
    ],
    "count": 1116,
    "truncated": true,
    "note": "Indexed, but constructs in these line ranges may be missing (best-effort signal); examples only — full list via index_status or 'logfile'."
  },
  "parse_unusable_count": 58,
  "parse_unusable": {
    "files": [
      {
        "path": "external/eigen/Eigen/src/Core/AssignEvaluator.h",
        "whole_file": true,
        "range_end": 1102
      },
      {
        "path": "external/eigen/Eigen/src/Core/CwiseNullaryOp.h",
        "whole_file": true,
        "range_end": 969
      },
      {
        "path": "external/eigen/Eigen/src/Core/Ref.h",
        "whole_file": true,
        "range_end": 383
      },
      {
        "path": "external/eigen/Eigen/src/Core/Transpose.h",
        "whole_file": true,
        "range_end": 427
      },
      {
        "path": "external/eigen/Eigen/src/Core/TriangularMatrix.h",
        "whole_file": true,
        "range_end": 1082
      }
    ],
    "count": 58,
    "truncated": true,
    "note": "Indexed, but the parse failed across nearly the whole file, so line ranges are not useful here — read the source directly."
  },
  "nodes": 96322,
  "edges": 541792,
  "expected_nodes": 96322,
  "expected_edges": 541792,
  "adr_present": false,
  "adr_hint": "Project indexed. Consider creating an Architecture Decision Record: explore the codebase with get_architecture(aspects=['all']), then use manage_adr(mode='update') to persist architectural insights across sessions.",
  "artifact_present": false,
  "status": "indexed",
  "format_migration": true
}

@akashskypatel

Thank you, @akashskypatel, for the v0.11.0 follow-up and the detailed output. This gives us a concrete completed C++ indexing run to investigate: about 58 seconds, 96,322 nodes and 541,792 edges, alongside your report of continued CPU pressure. It does not establish which phase caused the peak, and completion does not mean the stutter is fixed. This remains open and maintainer-owned, without awaiting-reporter. We have your diagnostics now; please do not deliberately reproduce a lockup or send private source code. Thank you again for separating the improved memory behavior from the CPU problem that remains.

fix: preserve CPU headroom during background indexing

fix(daemon): let an explicit index join a running automatic job

@mvanhorn

Fixed on main in 29aa748 (PR #2022 by @mvanhorn): automatic background indexing (session auto-index and watcher re-index) now leaves CPU headroom instead of using every core, while an explicit index_repository keeps full speed. Thank you for the report, @qingjiao-chan.

Navigation Menu

Repository navigation

CPU memory usage is too high #1084

Version

Platform

Install channel

Binary variant

What happened, and what did you expect?

Reproduction

Logs

Diagnostics trajectory (memory / performance / leak issues)

Project scale (if relevant)

Confirmations

Auto-Index

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

CPU memory usage is too high #1084

Description

Version

Platform

Install channel

Binary variant

What happened, and what did you expect?

Reproduction

Logs

Diagnostics trajectory (memory / performance / leak issues)

Project scale (if relevant)

Confirmations

Activity

github-actions commented on Jul 14, 2026

DeusData commented on Jul 14, 2026

dnuno89 commented on Jul 15, 2026

Auto-Index

DeusData commented on Jul 15, 2026

Muscipular commented on Jul 29, 2026

github-actions commented on Aug 20, 2026

sxcooler commented on Aug 26, 2026

akashskypatel commented on Aug 31, 2026

DeusData commented on Sep 1, 2026

akashskypatel commented on Sep 2, 2026

DeusData commented on Sep 19, 2026

akashskypatel commented on Sep 23, 2026

DeusData commented on Oct 1, 2026

DeusData commented on Nov 1, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions