Mempalace mine multiple processes hanging on claude folder

[kryptek]

What happened?

hunter2         22658  98.3  0.5 442773008 303856 s000  R     1:11PM 358:31.52 /Users/hunter2/.pyenv/versions/3.12.7/bin/python3 -m mempalace mine /Users/hunter2/.claude/projects/-Users-hunter2-repos-hunter2
hunter2         46719  58.5  0.3 442568096 178688 s000  R+    7:08PM   0:03.05 /Users/hunter2/.pyenv/versions/3.12.7/bin/python3 -m mempalace mine /Users/hunter2/.claude/projects/-Users-hunter2-repos-hunter2 --mode convos --wing sessions```

**What did you expect?**

I do not expect mempalace to be running for 6 hours on my machine. What is this thing doing? The folder size it's trying to mine is 350MB. 

**How to reproduce:**

1. Just using claude code; it seems the MCP is spawning these processes.
2.
3.

**Environment:**
- OS: MacOS Tahoe 26.4.1
- Python version: 3.12.7
- MemPal version: (check `python mempal.py --version` or git SHA) 3.3.3

[jphein]

@kryptek — thanks for the report. Same root cause as #1202; @Seph396's analysis there has the diagnostic shape, and the fix is in #976 (merged to develop 2026-04-25, deferred to v3.3.4).

A 6-hour, 98% CPU mine on a 350 MB folder is the orphan-mine pattern. Once HNSW corrupts under concurrent writes, subsequent add calls retry indefinitely against an index that can't accept them — hence the runaway CPU. mempalace status and mempalace repair will likely both segfault until the palace is wiped + re-mined (recovery path in #1202 / #1092).

If corruption is acute enough that you don't want to wait for v3.3.4, you can install from develop directly:

pip install git+https://github.com/MemPalace/mempalace.git@develop

That branch has both mine_global_lock() (prevents the fan-out spawn) and the hnsw:num_threads=1 retrofit (prevents the underlying parallel-insert race).