Reported issues for Codebase Memory

Pod holds 23 of 39 GitHub reports that passed its relevance review. This can include external user reports, maintainer-confirmed bugs, and concrete feature gaps. Treat them as evidence to inspect, not a count of distinct defects.

Back to Codebase Memory.

Most discussed

Memory not released after indexing: 20GB+ RSS for 5MB of indexed data

Summary

After indexing a small project (65 files, 1.3MB, 2509 nodes), codebase-memory-mcp retains 20GB+ RSS on a 32GB Windows machine. Memory grows monotonically and is never released to the OS.

Environment

OS: Windows 11, i7-12700 (20 cores), 32GB RAM
CBM Version: 0.8.1
Project: 65 Markdown files, 1.3MB, 2509 nodes

Root Cause (from source code)

mimalloc abandoned-thread arenas not purged (mem.c missing mi_option_abandoned_thread_purge)
Default worker count uses all 20…

Read the thread · 2026-07-04 · closed · external user · 13 comments

trace_path silently accepts invalid direction values and returns empty results

Summary

trace_path returns an empty result for every function/method I tried — callers or callees, plain or fully-qualified name, any depth — even though the underlying CALLS edges exist and are traversable via query_graph. The tool only ever echoes back {"function":...,"direction":...} with no paths/nodes.

This makes the headline call-graph traversal tool effectively non-functional in v0.8.1, at least on macOS arm64.

Environment

Version: codebase-memory-mcp…

Read the thread · 2026-06-16 · open · external user · 9 comments

[bug] Auto-generated Pi extension (cbmem.ts) missing parameters schema — crashes on startup

Summary

The Pi extension that the installer auto-generates at ~/.pi/agent/extensions/cbmem.ts registers 15 tools with no parameters schema, which makes every new pi session crash on startup with:

Error: Cannot read properties of undefined (reading 'properties')

Environment

Component	Version
codebase-memory-mcp	0.10.8
pi (`@earendil-works/pi-coding-agent`)	0.84.2
OS	Windows 11 (Git Bash via Scoop)
Node	(pi ships with bun runtime)…

Read the thread · 2026-08-23 · closed · external user · 6 comments

Every idle MCP client burns ~0.7 core since 0.9.1-rc.1 (0.9.0: 0%) — N concurrent sessions cost N cores, Windows

Version

codebase-memory-mcp 0.10.8

Platform

Windows (x64)

Install channel

GitHub release archive / install.sh / install.ps1

Binary variant

standard

What happened, and what did you expect?

A codebase-memory-mcp stdio client process consumes 55-86% of one CPU core while completely idle, from the moment it starts, and never settles. Expected: ~0%, which is exactly what 0.9.0 does on the same machine.

This is not agent-specific and needs no MCP traffic to…

Read the thread · 2026-08-20 · closed · external user · 6 comments

macOS: markerless stale socket/anchor pair permanently blocks daemon startup

Version

codebase-memory-mcp 0.10.8

Platform

macOS on Apple Silicon

Install channel

GitHub release archive

Binary variant

standard

What happened, and what did you expect?

When a runtime namespace contains a hard-linked .sock and .anc pair but no .sock.identity or .sock.pending, daemon startup remains permanently blocked.

No process holds the socket and connecting to it returns ECONNREFUSED, but both daemon start and CLI commands fail until the pair is…

Read the thread · 2026-08-20 · closed · external user · 6 comments

Windows v0.8.1: stale graph + Permission denied on delete_project after orphan cbm process (reconfirm #277)

Summary

Just confirming that the symptoms from #277 ("New files not indexed on Windows") are still present in v0.8.1 on Windows 11. The same workaround from that issue (kill orphan codebase-memory-mcp.exe processes, delete the .db* files, reindex) is still the only thing that reliably gets the graph back in sync. New files added after the first index simply don't show up until a full reset.

Related: #520 ("watcher misses file creation") is also still open.

Environment…

Read the thread · 2026-07-06 · closed · external user · 6 comments

Full index build allocates ~11.5 GB on a ~14k-file TypeScript monorepo regardless of the configured memory budget (0.10.8)

Version

codebase-memory-mcp 0.10.8 (aarch64 static build)

Platform

Linux (arm64)

Install channel

GitHub release archive / install.sh / install.ps1

Binary variant

standard

What happened, and what did you expect?

A full index_repository of a single TypeScript monorepo (13,969 files) peaks at about 11.0 to 11.9 GB RSS on a 16 GB host, and the configured memory budget does not bound it. The default ram_fraction budget on this box is 3,916 MB and an explicit…

Read the thread · 2026-09-01 · closed · outside contributor · 5 comments

Idle MCP frontend still burns ~19% of a core on v0.10.8 (Windows) — looks like a regression of #1764

Version

v0.10.8

Platform

Windows (x64)

Install channel

GitHub release archive / install.sh / install.ps1

Binary variant

standard

What happened, and what did you expect?

I'm on v0.10.8 (latest release) on Windows, and I'm seeing the same idle-CPU behavior that #1764 was supposed to fix. Reporting here in case the fix regressed or doesn't cover this path.

Isolated reproduction (no MCP client involved)

To rule out my editor/agent, I started a single frontend process…

Read the thread · 2026-09-07 · open · external user · 4 comments

Most recent

`/api/layout` does not expose edge `confidence`

Severity: medium.

CALLS edges carry confidence, strategy, candidates, via via query_graph, but the layout endpoint returns only {source, target, type} — 0 of ~208 000 edges carry confidence. The graph UI therefore cannot distinguish an LSP-resolved call from a suffix_match guess, and neither can any HTTP consumer.

Ask: include confidence and strategy on layout edges, ideally with a min_confidence query parameter.

Observed on v0.10.8 (build…

Read the thread · 2026-09-09 · open · external user · 0 comments

Dead-code status ignores framework-driven entry points

Severity: high — the feature is unusable as shipped.

359 nodes get status: "dead"; 247 (69%) are reachable only dynamically:

ASGI/WSGI middleware __call__ for classes listed in a settings module
__init__ of classes instantiated via a registry or DI
alembic upgrade/downgrade, Django management-command handle
pytest fixtures, @receiver / @shared_task decorated functions

Ask: a configurable liveness list (dunder methods, decorator patterns, declarative…

Read the thread · 2026-09-09 · open · external user · 0 comments

Name-only resolution is emitted as `CALLS` rather than `CALL_REFERENCE`

Severity: high.

41% of CALLS (20 549 of 49 544) carry confidence < 0.5, via unique_name (0.38) and suffix_match (0.01–0.28). These are name guesses, yet they share an edge type with LSP-resolved calls, so any consumer that does not filter gets noise.

Measured precision of the unfiltered intra-service CALLS layer: 52% (26/50). With confidence >= 0.9: 92% (46/50).

Visible in the top-called list: filter resolves into a test module, "".join and os.path.join both…

Read the thread · 2026-09-09 · open · external user · 0 comments

`CALLS` edges are created across separate service roots in a monorepo

Severity: high — poisons impact analysis and "who calls X".

In a monorepo where each top-level directory is a separate process (apps/service_a = Django, apps/service_b = an independent FastAPI app), the indexer emits ~5 700 CALLS edges between them. In-process calls between separate processes cannot exist.

A random sample of 50 such edges was 100% false at every confidence level, including the top band:

| confidence | strategy | callee in source…

Read the thread · 2026-09-09 · open · external user · 0 comments

find a bug?

Version

codebase-memory-mcp 0.10.5

Platform

macOS (Apple Silicon)

Install channel

GitHub release archive / install.sh / install.ps1

Binary variant

standard

What happened, and what did you expect?

PHP builtin functions (sprintf, str_replace, exit) are being resolved to unrelated browser-side JavaScript functions in minified libraries, producing fabricated cross-language CALLS edges that violate runtime boundaries:

sprintf(...) in PHP server code…

Read the thread · 2026-09-09 · open · external user · 1 comment

BCL/external calls fabricate CALLS edges to unrelated internal classes (phantom callers; e.g. int.TryParse → internal TryParse)

Version

codebase-memory-mcp 0.10.8

Platform

Linux (x64)

Install channel

AUR

Binary variant

standard

What happened, and what did you expect?

Calls to BCL / external static members (int.TryParse, Options.Create, chained expressions) are being resolved to unrelated internal classes in the indexed project, producing fabricated CALLS edges:

int.TryParse(input, out _) → CALLS edge to our internal TsidNode.TryParse
Options.Create(new object()) →…

Read the thread · 2026-09-09 · open · external user · 0 comments

C#: CALLS edge attaches to wrong same-name class variant (shared namespace root) — using-directive scoping ignored; trace_path inbound returns callers_total: 0

Version

codebase-memory-mcp 0.10.8

Platform

Linux (x64)

Install channel

AUR

Binary variant

standard

What happened, and what did you expect?

When two projects contain classes with the same simple name in namespaces that share a common root (Contoso.Platform.Identity.UserIdentityInfo vs Contoso.Platform.BackOffice.Identity.UserIdentityInfo), a call from BackOffice code — with an explicit using Contoso.Platform.BackOffice.Identity; — gets its CALLS edge…

Read the thread · 2026-09-09 · open · external user · 1 comment

13 of 15 tools annotated destructiveHint:true / readOnlyHint:false, but most are pure read/query operations

Title: 13 of 15 tools annotated destructiveHint:true / readOnlyHint:false, but most are pure read/query operations

Body:

Querying tools/list on v0.10.8 (darwin-arm64 release binary), the tool annotations look like they were stamped with one shared default rather than set per-tool. Every tool except list_projects (correctly readOnlyHint: true) and ingest_traces gets the identical {"readOnlyHint": false, "destructiveHint": true, "idempotentHint": true, "openWorldHint": false},…

Read the thread · 2026-09-08 · open · external user · 0 comments

`daemon start` silently overrides persisted `ui_enabled=false` and re-enables the graph UI listener

Summary

On 0.10.8 (macOS arm64, official binary at ~/.local/bin), an explicit codebase-memory-mcp daemon start re-enables the graph UI even when ui_enabled was just persisted to false, and writes ui_enabled=true back into the config. The auto-spawn path (daemon started on demand by the MCP front-end) respects the persisted setting, so the two start paths disagree.

Repro

$ codebase-memory-mcp daemon stop
$ codebase-memory-mcp config set ui_enabled false
  ui_enabled =…

[Read the thread](https://github.com/DeusData/codebase-memory-mcp/issues/2114) · 2026-09-08 · open · external user · 1 comment

### Orphaned socket with no .sock.identity sidecar wedges every client permanently; no daemon log, misleading 30s timeout

## Summary

If the rendezvous socket in `/tmp/cbm-daemon-<uid>` is left behind *without* its `.sock.identity` sidecar, every client is permanently wedged. No daemon ever starts again, the client returns `CBM daemon could not start within 30000 ms`, and `cbm-daemon.log` gets nothing at all — not even a `daemon.start_failed`. It never self-heals. Mine sat broken for five days across a dozen sessions before I dug into it.

This is a cousin of #1828 (same misleading timeout, same…

[Read the thread](https://github.com/DeusData/codebase-memory-mcp/issues/2107) · 2026-09-08 · open · external user · 0 comments

### Unable to uninstall on mac

### Version

codebase-memory-mcp 0.10.8

### Platform

macOS (Apple Silicon)

### Install channel

GitHub release archive / install.sh / install.ps1

### Binary variant

standard

### What happened, and what did you expect?

❯ codebase-memory-mcp uninstall -y
codebase-memory-mcp uninstall

Stopping active CBM sessions and operations for uninstall...
Claude Code: removed 0 skill(s)
  Claude Code agent: removed owned profile /Users/crazytomatooo/.claude/agents/codebase-memory-scout.md
  Claude…

[Read the thread](https://github.com/DeusData/codebase-memory-mcp/issues/2106) · 2026-09-08 · open · external user · 0 comments

### feat(cli): top-level --format / CBM_CLI_FORMAT default for tools (follow-up from #1867)

# Split out of #1867 per @DeusData's request

Split out from #1867 (secondary finding there: `search_graph` / `trace_path` / `detect_changes` emit the compact tree by default when stdout is not a TTY), per [the maintainer's invitation](https://github.com/DeusData/codebase-memory-mcp/issues/1867#issuecomment-5575970029) to give it its own discussion.

## Current state (verified on v0.10.8) — better than my original report assumed

- Tools that accept a `format` argument (notably `search_graph` /…

[Read the thread](https://github.com/DeusData/codebase-memory-mcp/issues/2102) · 2026-09-08 · open · external user · 0 comments

### Index repository failed

### Version

codebase-memory-mcp 0.10.8

### Platform

Windows (x64)

### Install channel

GitHub release archive / install.sh / install.ps1

### Binary variant

standard

### What happened, and what did you expect?

<html>
<body>
<!--StartFragment--><p style="white-space: pre-wrap; margin-top: 0.1em; margin-bottom: 0.2em; unicode-bidi: plaintext; color: rgb(204, 204, 204); font-family: -apple-system, BlinkMacSystemFont, &quot;Segoe UI&quot;, Roboto, sans-serif; font-size: 13px; font-style:…

[Read the thread](https://github.com/DeusData/codebase-memory-mcp/issues/2088) · 2026-09-07 · open · external user · 0 comments

### [Feature Request] Introduce an intermediate evidence/state layer for reliable workflow qualification

### What problem does this solve?

This would address a recurring problem in evidence-driven workflows: higher-level agent logic currently has to reconstruct and interpret evidence status across multiple low-level tool calls.

The main risk is that different situations can collapse into the same apparent result:

* lookup failure can look like “no result”;
* stale data can look current;
* uncovered paths can look empty;
* partial evidence can look complete;
* unconfirmed information can be…

[Read the thread](https://github.com/DeusData/codebase-memory-mcp/issues/2080) · 2026-09-06 · closed · external user · 0 comments

### `update` deletes every index and then performs no update (it prints 'run install.sh yourself'); with -y this is unattended data loss

### Version

0.9.0 (the deleting side) → 0.10.8 (the message quoted below)

### Platform

macOS (arm64)

### Summary

`codebase-memory-mcp update` **deletes every index in the cache and then performs no update** — it prints instructions telling you to run `install.sh` yourself. With `-y` this is unattended, guaranteed data loss with zero upgrade delivered.

### What I ran

$ ~/.local/share/mcp-runners/codebase-memory-mcp/0.9.0/payload/codebase-memory-mcp update -y


### What happened

It…

[Read the thread](https://github.com/DeusData/codebase-memory-mcp/issues/2054) · 2026-09-04 · open · external user · 2 comments

The remaining reports are on [the project's issue tracker](https://github.com/DeusData/codebase-memory-mcp/issues).

Reported issues for Codebase Memory

Most discussed

Memory not released after indexing: 20GB+ RSS for 5MB of indexed data

Summary

Environment

Root Cause (from source code)

trace_path silently accepts invalid direction values and returns empty results

Summary

Environment

[bug] Auto-generated Pi extension (cbmem.ts) missing parameters schema — crashes on startup

Summary

Environment

Every idle MCP client burns ~0.7 core since 0.9.1-rc.1 (0.9.0: 0%) — N concurrent sessions cost N cores, Windows

Version

Platform

Install channel

Binary variant

What happened, and what did you expect?

macOS: markerless stale socket/anchor pair permanently blocks daemon startup

Version

Platform

Install channel

Binary variant

What happened, and what did you expect?

Windows v0.8.1: stale graph + Permission denied on delete_project after orphan cbm process (reconfirm #277)

Summary

Environment…

Full index build allocates ~11.5 GB on a ~14k-file TypeScript monorepo regardless of the configured memory budget (0.10.8)

Version

Platform

Install channel

Binary variant

What happened, and what did you expect?

Idle MCP frontend still burns ~19% of a core on v0.10.8 (Windows) — looks like a regression of #1764

Version

Platform

Install channel

Binary variant

What happened, and what did you expect?

Most recent

/api/layout does not expose edge confidence

Dead-code status ignores framework-driven entry points

Name-only resolution is emitted as CALLS rather than CALL_REFERENCE

CALLS edges are created across separate service roots in a monorepo

find a bug?

Version

Platform

Install channel

Binary variant

What happened, and what did you expect?

BCL/external calls fabricate CALLS edges to unrelated internal classes (phantom callers; e.g. int.TryParse → internal TryParse)

Version

Platform

Install channel

Binary variant

What happened, and what did you expect?

C#: CALLS edge attaches to wrong same-name class variant (shared namespace root) — using-directive scoping ignored; trace_path inbound returns callers_total: 0

Version

Platform

Install channel

Binary variant

What happened, and what did you expect?

13 of 15 tools annotated destructiveHint:true / readOnlyHint:false, but most are pure read/query operations

daemon start silently overrides persisted ui_enabled=false and re-enables the graph UI listener

Summary

Repro

`/api/layout` does not expose edge `confidence`

Name-only resolution is emitted as `CALLS` rather than `CALL_REFERENCE`

`CALLS` edges are created across separate service roots in a monorepo

`daemon start` silently overrides persisted `ui_enabled=false` and re-enables the graph UI listener