Hypermnesia MCP

Memory for AI coding agents that you can hold accountable.

Keep decisions, fixes and project context between sessions, and inspect what was retrieved.

Runs locally by default. No account, no API key, no server to manage.

---

Sovereign is what it is today. Everything runs on your machine: a local SQLite file by default, or PostgreSQL + pgvector if you prefer. No LLM in the retrieval loop, and nothing leaves localhost unless you configure an integration that does. Your project's memory is a file you own and can delete.

Claude Code and Codex share Cortex memory. Both native plugins provide the same memory tools and 11 lifecycle hook modules for automatic capture, recall and project context. Use either agent on a project and keep its memory when you switch. Verified with real Claude and Codex sessions on macOS. The same stdio MCP server also supplies memory tools to Claude Desktop, Claude Cowork and other local MCP hosts.

Eco-responsible is what we are aiming at. Work that never reaches a datacenter is work nobody has to power, and an agent that finds the right context first time re-reads fewer files. We hold that intent to the Green Software Foundation's SCI method, and we publish no CO₂ or energy figure, because we have not measured one. What we do and do not claim ↓

36 implemented, inspectable neuroscience-inspired mechanisms · 57 memory tools · 11 lifecycle hooks · a self-curating per-project wiki — all local, all open-source, MIT.

The committed ablations do not establish that these 36 mechanisms improve retrieval

collectively or individually. Published neuroscience references explain their design;

retrieval benefits require measurements in Cortex. See Verification.

Install

Claude Code — add the marketplace and install the plugin:

claude plugin marketplace add cdeust/Cortex

claude plugin install hypermnesia-mcp claude --init-only

claude --init-only runs the plugin's Setup hook, which installs Cortex's runtime (base dependencies, semantic search and its embedding model) before your first session. It prints nothing and exits 0 even when the install fails (Claude Code discards a Setup hook's output), so to watch the progress and get a failing exit code, run scripts/init_plugin.py from the installed plugin instead (its path is installPath in claude plugin list --json).

Update the same way, one command, then initialise again:

claude plugin update hypermnesia-mcp

claude --init-only

Claude Desktop — download hypermnesia-mcp.mcpb from Releases and open it, or use Settings → Extensions. The bundle carries the tools but no hooks; the MCPB format has none.

Claude Cowork is detected automatically (CLAUDE_ENVIRONMENT=cowork) and uses the local SQLite store. No PostgreSQL required.

For Codex, install the native plugin for memory tools and automatic hooks:

uv tool install "hypermnesia-mcp[sqlite]"

codex plugin marketplace add cdeust/Cortex codex plugin add hypermnesia-mcp-codex@cortex-codex-plugins

Open /hooks in Codex to review and trust the Cortex hooks, then start a fresh session. Changed hook definitions require renewed trust after an update. The plugin uses the same saved backend selection as Claude Code; both hosts share memory when they use the same configuration root and store. Codex setup details.

Other stdio MCP hosts (Gemini CLI, Cursor, Windsurf, VS Code) launch the same server and get the same tools. See launch commands. WSL, TLS client certificates and corporate proxies are covered in deployment scenarios.

Cortex's dependencies live in the plugin's data directory, one directory per locked dependency set (sets/ ), so an update that does not change the locked dependencies (most releases: 21 of 29 from v4.9.0 to v4.23.5) finds its set installed. A background job removes the sets no installed version references; it makes no network call. When a set is missing (the first session after an install, or after an update that changes the locked dependencies, when claude --init-only did not run first), no hook installs: SessionStart says Cortex is installing its dependencies (about 2 minutes, about 5 with semantic search); memory is available when it is done, the Edit/Write guards let edits through and say that the Cortex gate is inactive until then, and the MCP server installs the set in the background; the next session (or the same one, once done) shows Cortex ready: , memories; . claude --init-only (or python3 scripts/init_plugin.py, which shows progress) installs everything before the first session; only with it does that session start ready. To work without Cortex, offline or not, run claude plugin disable hypermnesia-mcp@cortex-plugins.

On macOS and Linux (glibc 2.36 or later, x86_64 or arm64: Ubuntu 24.04 and 26.04, Debian 12 and later; not Ubuntu 22.04 or RHEL 9), claude --init-only on a fresh install also gives the plugin its own PostgreSQL server with pgvector and pg_trgm: pinned, sha256-checked binaries (about 13 MB on macOS, 40 MB on Linux, where they bundle their libraries; pgvector is compiled by Cortex's CI, with build provenance attested) on 127.0.0.1, with no Homebrew or system PostgreSQL needed. Its data lives in ~/.claude/methodology/managed-pg/, so uninstalling the plugin never deletes your memories. It becomes the store only after it has started and its schema exists; if it cannot start (a Linux distribution with glibc older than 2.36, for example) the SQLite store is used, as it is on Windows, and the session start says why (SQLite fallback: ...). A store already on that server is never switched to SQLite: Setup fails and names the cause. The Codex plugin on the same account attaches to the same server. An existing SQLite store is not moved (ADR-1114).

Otherwise the first use creates a local SQLite store under ~/.claude/methodology/. Models are downloaded once when needed and then run offline. The embedding and reranking model files are both fetched on first use. Optional integrations, remote PostgreSQL, and OTLP telemetry use the network only when explicitly configured. PRIVACY.md lists the exact scope.

An existing PostgreSQL setup is kept: a configured database_url option (or DATABASE_URL), or the backend marker install-plugin.sh --postgres writes, always wins over the plugin's own server and the SQLite default. An install that ran before on the local cortex database with nothing configured keeps it: on its first launch Cortex moves to SQLite only when nothing listens on localhost:5432 and no PG* variable configures PostgreSQL, records the choice, and prints it. A fresh install never connects to a database nothing configured.

Upgrading from an older plugin identity

The plugin was renamed hypermnesia-mcp in v4.15.0, after a community-directory collision with an unrelated cortex plugin. Memories, configuration and storage paths are untouched.

claude plugin uninstall cortex

claude plugin install hypermnesia-mcp

The visualization companion, hypermnesia-mcp-viz , was renamed the same way:

claude plugin uninstall cortex-viz@cortex-plugins

claude plugin marketplace update cortex-plugins claude plugin install hypermnesia-mcp-viz@cortex-plugins

The retained cortex-viz@cortex-plugins entry is a frozen shim that only prints this notice and exposes no server or tools.

Allowlists, hooks, skills and agents must migrate both composed tool names: mcp__plugin_cortex-viz_cortex-viz__open_visualization becomes mcp__plugin_hypermnesia-mcp-viz_hypermnesia-mcp-viz__open_visualization, and mcp__plugin_cortex-viz_cortex-viz__get_methodology_graph becomes mcp__plugin_hypermnesia-mcp-viz_hypermnesia-mcp-viz__get_methodology_graph.

Keep context useful

Across sessions, agents need to remember decisions, bring prior fixes back when a similar problem returns, and show you which sources support a memory so you can correct it. Cortex keeps that context available while making its status visible.

Cortex does this with local quality checks: what is written, whether its references resolve, what happens when a decision changes, and what can fade over time.

What gets in

The remember handler and automatic capture check for exact replays after hardening and redaction. Matching domain, directory, agent topic, source, write class, capture origin, and global/team flags produce reason: "exact_duplicate" with the existing memory id. Forced writes retain this check; explicit supersedes_id corrections retain their atomic supersession path. Benchmark rows are isolated, and memory-replica block replicas keep their path identity. Direct store inserts do not use this handler check. Consolidation supersedes existing exact duplicates within that scope and preserves their rows and protection flags. This differs from the optional normalized-text maintenance pass. Near-duplicate curation uses the thresholds in core/curation.py; deliberate writes bypass the novelty threshold and can be stored separately when curation does not merge them.

// Illustrative project decision:

remember({ content: "Keep session state in Redis so TTL expiry is handled consistently." }) // → { stored: true, action: "stored" }

Deliberate writes can be refused as exact replays; novelty alone does not reject them. Unattended capture must also pass the novelty check, which keeps automatic capture from burying the memories you meant to keep.

Whether it can be checked

Every memory is graded at write time, locally, with no network call. The grade is not a confidence score: it is whether the claims carry references that resolve on this machine.

// → provenance: { grade: "unverifiable",

// reason: "dead_refs: deps/numpy/_core/_multiarray_umath.cpython-313-darwin.so", // hint: "1 of 9 checkable reference(s) could not be resolved" }

That memory named a file that no longer existed, so it was stored and labelled unverifiable instead of being silently presented as verified. Rewritten against paths that resolve, the same memory grades verified. A recalled memory tells you which kind it is; a verified grade still means that the references resolve locally, not that the claim has been independently proven true.

When it turns out wrong

Corrections supersede rather than overwrite. The new memory records what it replaces, the old one is demoted