# 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](/mcp/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](https://github.com/cdeust/Cortex/issues/97) · 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](https://github.com/cdeust/Cortex/issues/96) · 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](https://github.com/cdeust/Cortex/issues/46) · 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__remember`
- `mcp__cortex__recall`
- `mcp__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](https://github.com/cdeust/Cortex/issues/17) · 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:

```python
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).