chroma-mcp CPU/memory leak in v10.3.1

[nyflyer]

Description

After installing v10.3.1, the chroma-mcp Python process rapidly consumes excessive CPU and memory, making the system unusable. The root cause is the v10.3.0 architectural change that replaced npx chroma run (Node/WASM) with chroma-mcp via uvx (Python). The v10.3.1 fixes for duplicate daemons and zombie processes didn't address the underlying CPU runaway in the Python chroma-mcp subprocess itself.

Symptoms

• chroma-mcp Python process spikes to 500–700%+ CPU within minutes of Claude Code starting
• Memory consumption reaches 400MB–1GB+
• The worker-service.cjs --daemon process respawns killed processes, making it hard to stop without removing the marketplace first

Steps to Reproduce

1. Install claude-mem v10.3.1 via /plugin
2. Start a Claude Code session
3. Monitor processes: ps aux | grep chroma-mcp
4. Observe CPU/memory climb rapidly

Environment

• OS: Linux 6.17.0-14-generic
• Claude Code version: 2.1.47
• Plugin version: 10.3.1 (also affects 10.3.0)

Workaround

Pinning to v10.2.6 resolves the issue while preserving newer features. Steps:

# Kill runaway processes (remove marketplace first so daemon doesn't respawn)
pkill -9 -f "thedotmack/claude-mem"
pkill -9 -f "worker-service.cjs"
pkill -9 -f "chroma-mcp"
pkill -9 -f "mcp-server.cjs"

# Wipe and re-clone at v10.2.6
rm -rf ~/.claude/plugins/marketplaces/thedotmack
rm -rf ~/.claude/plugins/cache/thedotmack
git clone --branch v10.2.6 https://github.com/thedotmack/claude-mem.git ~/.claude/plugins/marketplaces/thedotmack
git -C ~/.claude/plugins/marketplaces/thedotmack remote set-url origin ""

Then reinstall from the Discover tab in /plugin.

Additional Notes

• v10.2.6 is stable — uses Node-based chroma run, no CPU leak
• v10.3.0 introduced the switch to Python chroma-mcp via uvx — this is where the leak originates
• v10.3.1 attempted to fix duplicate daemons/zombies but the CPU runaway persists

[github-actions]

A GitHub issue reports that the chroma-mcp process in the claude-mem plugin causes excessive CPU and memory usage in versions 10.2.6 and 10.3.1, rendering systems nearly unusable. Symptoms include CPU spikes of 500–700% and memory consumption between 400MB and 1GB, with processes repeatedly respawning even when terminated, complicating efforts to stop the runaway resource consumption. The issue occurs after installing the affected plugin version and starting a Claude Code session. Reverting to version 9.1.1 resolves the issue, with no similar resource leaks observed. The report provides detailed reproduction steps, environmental settings, and a workaround involving the removal of the problematic plugin and reinstallation of the stable version. The root cause appears to have been introduced between versions 9.1.1 and 10.2.6.

[nyflyer]

Did some digging through the v10.2.6 and v10.3.1 source with Claude to try to understand what's happening. Looks like it might be a combination of a few things:

1. Connection Timing vs Backfill Start

In v10.2.6, ChromaServerManager.start() is awaited before backfill begins — so the server is fully ready before any embedding work happens. In v10.3.1, ChromaMcpManager defers connection until the first callTool(), but backfillAllProjects() starts right after init:

// v10.2.6 — server ready before backfill
const ready = await this.chromaServer.start(60000);
ChromaSync.backfillAllProjects();

// v10.3.1 — connection happens on first use during backfill
this.chromaMcpManager = ChromaMcpManager.getInstance();
ChromaSync.backfillAllProjects();

So the first backfill call ends up triggering the Python subprocess startup (uvx environment setup + model loading) while backfill is already in progress.

2. Embedding Workload Difference

v10.2.6 uses WASM embeddings in Node via @transformers/js — lightweight and non-blocking. v10.3.1 routes all embedding through the Python chroma-mcp subprocess, where each chroma_add_documents batch (100 docs) is tokenized and embedded synchronously by all-MiniLM-L6-v2. For projects with a lot of observations, this keeps the Python process CPU-bound for the entire backfill.

3. Reconnect Behavior

The reconnect backoff is fixed at 10 seconds. If the subprocess crashes under load during backfill, the restart cycles can compound the issue. Exponential backoff (1s → 2s → 4s → ... → 60s cap) might help here.

Possible Fixes

1. Await the MCP connection before starting backfill
2. Use exponential backoff for reconnects
3. Smaller backfill batch sizes to spread the embedding load over time

Hope this helps narrow things down! Really appreciate the work on this plugin.

[nyflyer]

Update: After more testing, this might not be an ongoing leak but rather a one-time backfill cost. After doing a clean install of v10.3.1 (full wipe of marketplace + cache), the Python chroma-mcp process spiked CPU and ~980MB RAM during the initial embedding backfill, but it gradually came down over several minutes and search is working normally now.

So to clarify the issue — it's less of a persistent leak and more of an aggressive startup backfill that makes the system unusable for several minutes. If you have a lot of observations, the initial embedding pass through Python chroma-mcp is rough. Once it's done, things settle.

The suggestions from my earlier comment still apply though — awaiting the MCP connection before starting backfill and using smaller batch sizes would make the startup experience much smoother, even if it's ultimately a one-time cost.

Also worth noting: v10.2.6's Node WASM embeddings appear to be broken under bun 1.3.x (getting undefined is not an object on the path module in the bundled worker-service.cjs when it tries to set up the models cache dir), so rolling back to v10.2.6 might not be a viable workaround for everyone. Updating the workaround in the original post to reflect this.

[thedotmack]

Closed: Fixed in recent updates. The chroma-mcp resource management has been overhauled in v10.3.2+ with process lifecycle improvements (PR #1175, #1178).