Reported issues for hypermnesia-mcp
Pod holds 16 of 16 problems reported by people outside the maintainer team. Issues filed by the project's own owners, members and collaborators are excluded entirely — a maintainer's release checklist is not a warning to a prospective user.
Back to hypermnesia-mcp.
Most discussed
Windows: _pip_install's commit destroys existing deps packages while the MCP server is running (rmtree + os.replace vs locked .pyd) — armed on every session start when the ML stack is missing
Environment: Windows 11 Pro (build 26200), Python 3.13.13, cortex plugin 4.13.0 installed through the marketplace. Same box as #91–#95. Found while diagnosing the SessionStart charmap crash (#96).
Setup that arms the bug
The 4.13.0 plugin cache's active deps dir (~\.claude\plugins\cache\cortex-plugins\cortex\4.13.0\deps) came up with the base stack (~200 top-level entries) but without the ML stack (no sentence_transformers / torch / flashrank). Since session_start is t
Read the thread · 2026-07-11 · closed · external user · 4 comments
Windows: session_start hook dies with UnicodeEncodeError ('charmap' can't encode U+27E6 ⟦) — entire SessionStart memory injection lost
Environment: Windows 11 Pro (build 26200), Python 3.13.13, cortex plugin 4.13.0 installed through the marketplace, Western locale (ANSI code page 1252). Same box as #91–#95.
Symptom
Every Claude Code session start shows:
SessionStart:startup hook error
Failed with non-blocking status code: [cortex-launcher] Failed to run mcp_server.hooks.session_start: 'charmap' codec can't encode character '⟦' in position 25: character maps to <undefined>
and — the actual damage — **no me
Read the thread · 2026-07-11 · closed · external user · 4 comments
Windows: first remember can deadlock on the lazy scipy/sklearn import inside a FastMCP worker thread — eager-import at startup fixes it
Environment
Same as #91: Cortex 4.3.0, Windows 11, Python 3.13.13, FastMCP 3.2.4/3.4.4, Claude Code client.
Symptom
Distinct from the _git_root hang (reported separately in #91): before I found that one, the first remember on a fresh server process could wedge a worker thread permanently. faulthandler.dump_traceback_later on the live server showed:
Thread (AnyIO worker thread):
...
deps\scipy\linalg\blas.py:247 <module>
deps\scipy\linalg\_misc.py:3
[Read the thread](https://github.com/cdeust/Cortex/issues/92) · 2026-07-09 · closed · external user · 4 comments
### `remember` hangs indefinitely on Windows: `_git_root`'s subprocess timeout is defeated by `subprocess.run`'s post-kill `communicate()` (pipe handle-inheritance race)
## Environment
- Cortex plugin **4.3.0** (Claude Code marketplace install), PostgreSQL backend (pgvector/pg17, Docker)
- Windows 11 Pro (26200), Python **3.13.13**
- Client: Claude Code desktop; reproduced on FastMCP 3.2.4 **and** 3.4.4 (version-independent)
## Symptom
Calling the `remember` tool over a live MCP connection never returns — the call sits 10–30 minutes until the client's idle timeout aborts it (or the user cancels). Meanwhile:
- `memory_stats` on the **same connection
[Read the thread](https://github.com/cdeust/Cortex/issues/91) · 2026-07-09 · closed · external user · 4 comments
### auto_recall hook queries non-existent 'heat' column instead of 'heat_base'
## Summary
`mcp_server/hooks/auto_recall.py` queries `memories.heat`, but the actual schema column is `heat_base`. As a result, every UserPromptSubmit hook fire fails with:
[cortex-auto-recall] FTS query failed: column "heat" does not exist LINE 2: SELECT id, content, heat, domain, agent_context,... ^
The hook then exits 0 with no injection — silent failure on every user prompt. Per-prompt memory injection is broken.
## Reproducer
[Read the thread](https://github.com/cdeust/Cortex/issues/20) · 2026-05-05 · closed · outside contributor · 2 comments
### Cortex 3.12.0 — `consolidate` field report
The previous report were done on copies of this db. I upgraded my main install to 3.12 and this was the results of running consolidate.
# Cortex 3.12.0 — `consolidate` field report
**Date:** 2026-04-16
**Version:** cortex 3.12.0 (MCP plugin, alloy Postgres backend)
**Store size:** 66,277 memories (25,603 episodic / 40,675 semantic, 3,111 protected)
**Context:** First `consolidate` run after upgrade to 3.12.0; store includes a recent large claude-mem backfill import.
---
## Summary
`consol
[Read the thread](https://github.com/cdeust/Cortex/issues/14) · 2026-04-16 · closed · external user · 6 comments
### Cortex `consolidate` — Performance Report
# Cortex `consolidate` — Performance Report
**Plugin:** `cortex` (v3.9.1, per skill path)
**Date:** 2026-04-15
**Environment:** macOS 25.4.0 (Darwin), Mac M2 Max, 64 GB RAM
## Summary
A full `consolidate({decay, compress, cls, memify})` run on a memory
store of ~66K memories took **35 min 50 s** (2,150,496 ms). Most of
the work appears to be O(N) per-row updates across stages that could
plausibly be batched. One stage scanned but produced nothing, and the
homeostatic stage reported `health_sc
[Read the thread](https://github.com/cdeust/Cortex/issues/13) · 2026-04-15 · closed · external user · 8 comments
### Enhancement: Cache engram slot list in allocate_engram_slot
# Enhancement: Cache engram slot list in allocate_engram_slot
## Problem
`allocate_engram_slot()` is called on every `remember()` invocation. Each call:
1. `init_engram_slots()` — `SELECT COUNT(*)` to check if slots exist
2. `get_all_engram_slots()` — `SELECT *` fetching all 5,000 engram slot rows
3. `find_best_slot()` — CPU scan over the 5,000 slots (cheap)
4. `assign_memory_slot()` — `UPDATE` + `COMMIT`
5. `update_engram_slot()` — `UPDATE` + `COMMIT`
6. `get_memories_in_slot()` — `SELECT *`
[Read the thread](https://github.com/cdeust/Cortex/issues/11) · 2026-04-12 · closed · external user · 3 comments
## Most recent
### checkpoint: every call fails client-side output validation — outputSchema requires 'action' but no return path includes it
**Environment:** Cortex plugin 4.13.1, Windows 11, Claude Code as MCP client (validates structured tool results against the declared `outputSchema`).
## Summary
Every `checkpoint` call fails client-side with:
Output validation error: 'action' is a required property
The declared output schema requires `action`, but **no return path in the handler ever includes it** — so a strict MCP client rejects every response, including successful saves.
## Where
- `mcp_server/handlers/checkpoint
[Read the thread](https://github.com/cdeust/Cortex/issues/99) · 2026-07-12 · closed · external user · 1 comment
### Registered tool signatures drift from handler schemas: remember lacks supersedes_id/write_class, wiki_write lacks memory_ids — promotion loop cannot be closed over MCP
**Environment:** Cortex plugin 4.13.1, Windows 11, Claude Code as MCP client (validates tool calls against the declared input schema; `additionalProperties` violations are rejected client-side).
## Summary
The client-visible input schemas for `remember` and `wiki_write` are derived by FastMCP from the registered wrapper signatures — and those signatures have drifted from the handlers' own schemas and from the instructions your grooming planners emit. Net effect: **the documented lesson-promoti
[Read the thread](https://github.com/cdeust/Cortex/issues/98) · 2026-07-12 · closed · external user · 1 comment
### recall tool fails MCP output validation: schema requires 'memories' but handler returns 'results'
## Summary
Every call to the `recall` MCP tool fails with:
Output validation error: 'memories' is a required property
The declared `outputSchema` for `recall` requires the key `memories`, but the handler returns `results`. Two related schema/handler drifts compound this.
## Reproduction
Cortex 3.17.0, plugin install via cortex-plugins marketplace, PG backend healthy (`memory_stats` returns valid stats with 73K+ memories, `pgvector` enabled).
Any recall call fails:
From an MC
Read the thread · 2026-05-24 · closed · external user · 1 comment
FastMCP: remember/recall/get_telemetry return 'structured_content must be a dict' despite success
Summary
Three MCP tools return a FastMCP runtime error to the client even though the underlying memory operation succeeds and persists correctly:
mcp__cortex__remembermcp__cortex__recallmcp__cortex__get_telemetry
Error message:
structured_content must be a dict or None. Got str: '{...}'. Tools should wrap non-dict values based on their output_schema.
The data inside the error payload is the correct JSON; it's just being returned as a stringified JSON instead of a dict, so
Read the thread · 2026-05-05 · closed · outside contributor · 1 comment
seed_project: delete_memories_by_tag('seeded') is global, ignores domain scope
Summary
mcp_server/handlers/seed_project.py:180 purges memories globally by tag, regardless of the domain argument:
purged = 0
if not dry_run:
purged = _get_store().delete_memories_by_tag("seeded")
This means every call to seed_project wipes all previously-seeded memory rows across every domain — only the most recent seed survives.
Reproducer
Sequentially seed two repos with distinct domains:
seed_project(directory="/path/to/repoA", domain="repo-a")
# stor
[Read the thread](https://github.com/cdeust/Cortex/issues/16) · 2026-05-05 · closed · outside contributor · 2 comments
### backfill_memories misses subagent/teammate sessions due to non-recursive glob in discover_files
## Summary
`backfill_memories` silently skips most session transcripts because `discover_files` in `mcp_server/handlers/backfill_helpers.py:210` uses non-recursive `project_dir.glob("*.jsonl")`. Claude Code persists parent and subagent / teammate sessions across **four** layouts that the walker never descends into when nested.
## Concrete impact
Verified taxonomy on a real corpus with active subagent / teammate use, all 802 `*.jsonl` accounted for:
| layout | path shape | count | walker sees
[Read the thread](https://github.com/cdeust/Cortex/issues/15) · 2026-05-02 · closed · external user · 1 comment
### hooks.json file fix (needed on my system anyway)
# hooks.json uses flat structure instead of required nested `hooks` array
**Affected repos:** `zetetic-team-subagents` (v2.0.0), `Cortex` (v3.9.0)
**Files:** `hooks/hooks.json` (subagents), `.claude/hooks/hooks.json` (Cortex)
**Severity:** Plugin fails to load — all hooks are broken
## Problem
Claude Code's hook schema requires each hook entry to wrap `type`/`command` inside a nested `hooks` array. Both repos use a flat structure that puts `type` and `command` as siblings of `matcher`/`when`,
[Read the thread](https://github.com/cdeust/Cortex/issues/12) · 2026-04-13 · closed · external user · 2 comments
### plugin.json hardcoded DATABASE_URL overrides user's shell environment
Summary
The plugin-bundled MCP server config in [.claude-plugin/plugin.json] hardcodes DATABASE_URL=postgresql://localhost:5432/cortex in the mcpServers.cortex.env block. Claude Code merges this over the user's shell environment when launching the MCP server, so users running Postgres on any non-localhost host (remote DB, separate LXC, Docker network hostname, non-default port, or requiring credentials) hit a silent connection failure — regardless of what they set in ~/.claude/settings.json or t
[Read the thread](https://github.com/cdeust/Cortex/issues/9) · 2026-04-08 · closed · external user · 1 comment
The remaining reports are on [the project's issue tracker](https://github.com/cdeust/Cortex/issues).