Generated banner for memorix
Generated logo for memorix

memorix

Memory server

First committed by AVIDS2

Published in AVIDS2/memorix. Publisher page

926 GitHub stars

What it is

Local-first shared memory layer for AI coding agents across MCP clients, Git history, reasoning context, and project sessions.
— the description by AVIDS2

Summary from the brain’s metadata

Local-first shared memory layer for AI coding agents across MCP clients, Git history, reasoning context, and project sessions. One project memory system for Claude Code, Codex, CodeBuddy Code, Cursor, Windsurf, Copilot, Gemini CLI, OpenCode, Grok Build, OpenClaw, Hermes Agent, Oh-my-Pi, Pi, Kiro, Antigravity, Trae, DeepSeek Harness, WorkBuddy, and any MCP-capable agent.

How it works

Memory model: Hybrid

AutoGineer overview, from the brain’s own files

Memory model: Hybrid. Folders: .github (agent config, 3 files); .windsurf (agent config, 2 files); assets (attachments, 32 files); docs (docs, 65 files); examples (examples, 4 files); packages (source code, 836 files); scripts (scripts, 18 files); src (source code, 382 files). The agent writes CLAUDE.md.

Folders
FolderRoleFiles
.githubagent-config3
.windsurfagent-config2
assetsattachments32
docsdocs65
examplesexamples4
packagessource-code836
scriptsscripts18
srcsource-code382
teststests376
.codegraphfolder1
.opencodefolder1
.traefolder1
articlesfolder5
pluginsfolder64
stubsfolder1

The agent writes

Requirements

Apps: Docker

Runtimes: Node.js >=22.18.0, Bun

Databases: LanceDB, PostgreSQL, SQLite

API keys (by name): ANTHROPIC_API_KEY, API_ROUTE_API_KEY, ATLASCLOUD_API_KEY, CHEAPER_INFERENCE_API_KEY, GROQ_API_KEY, MEMORIX_API_KEY, MEMORIX_EMBEDDING_API_KEY, MEMORIX_HTTP_AUTH_TOKEN, MEMORIX_LLM_API_KEY, MEMORIX_RERANK_API_KEY, MINIMAX_API_KEY, MINIMAX_CN_API_KEY, OPENAI_API_KEY, OPENROUTER_API_KEY, REQUESTY_API_KEY, RUNCRATE_API_KEY

Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Google Antigravity, Kiro, OpenCode, Amp, Roo Code, Cline, JetBrains Junie, Devin (ex-Windsurf)

Set it up

  1. This brain runs code automatically: 20 hooks (claude-code, codex). Review plugins/claude/memorix/hooks/hooks.json, plugins/codebuddy/memorix/hooks/hooks.json, plugins/codex/memorix/hooks/hooks.json, plugins/copilot/memorix/hooks/hooks.json before opening the folder in Claude Code. No step below turns a hook on for you.

    • plugins/claude/memorix/hooks/hooks.json: memorix hook
    • plugins/claude/memorix/hooks/hooks.json: memorix hook
    • plugins/claude/memorix/hooks/hooks.json: memorix hook
    • plugins/claude/memorix/hooks/hooks.json: memorix hook
    • plugins/claude/memorix/hooks/hooks.json: memorix hook
    • plugins/codebuddy/memorix/hooks/hooks.json: memorix hook --agent codebuddy
    • plugins/codebuddy/memorix/hooks/hooks.json: memorix hook --agent codebuddy
    • plugins/codebuddy/memorix/hooks/hooks.json: memorix hook --agent codebuddy
    • plugins/codebuddy/memorix/hooks/hooks.json: memorix hook --agent codebuddy
    • plugins/codebuddy/memorix/hooks/hooks.json: memorix hook --agent codebuddy
    • plugins/codex/memorix/hooks/hooks.json: memorix hook --agent codex
    • plugins/codex/memorix/hooks/hooks.json: memorix hook --agent codex
    • plugins/codex/memorix/hooks/hooks.json: memorix hook --agent codex
    • plugins/codex/memorix/hooks/hooks.json: memorix hook --agent codex
    • plugins/codex/memorix/hooks/hooks.json: memorix hook --agent codex
    • plugins/copilot/memorix/hooks/hooks.json: memorix hook --agent copilot
    • plugins/copilot/memorix/hooks/hooks.json: memorix hook --agent copilot
    • plugins/copilot/memorix/hooks/hooks.json: memorix hook --agent copilot
    • plugins/copilot/memorix/hooks/hooks.json: memorix hook --agent copilot
    • plugins/copilot/memorix/hooks/hooks.json: memorix hook --agent copilot
  2. Not scanned by AutoGineerAutoGineer could not scan everything it runs. https://www.npmjs.com/package/memorix
  3. First committed by AVIDS2. Published in AVIDS2/memorix. Licence: Apache License 2.0.

Usage

AutoGineer’s guidance for this type of brain

Add the server to your AI tool’s MCP configuration (see Set it up); your agent then stores and recalls memories through its tools.

Documentation by AVIDS2

<p align="center"> <img src="https://raw.githubusercontent.com/AVIDS2/memorix/main/assets/readme-hero.svg" alt="Memorix" width="720"> </p>

<h1 align="center">Memorix</h1>

<p align="center"> <strong>Local-first shared memory layer for AI coding agents.</strong><br> One project memory system for Claude Code, Codex, CodeBuddy Code, Cursor, Windsurf, Copilot, Gemini CLI, OpenCode, Grok Build, OpenClaw, Hermes Agent, Oh-my-Pi, Pi, Kiro, Antigravity, Trae, DeepSeek Harness, WorkBuddy, and any MCP-capable agent. </p>

<p align="center"> <a href="https://www.npmjs.com/package/memorix"><img src="https://img.shields.io/npm/v/memorix.svg?style=for-the-badge&logo=npm&color=cb3837" alt="npm"></a> <a href="https://www.npmjs.com/package/memorix"><img src="https://img.shields.io/npm/dm/memorix.svg?style=for-the-badge&logo=npm&label=monthly%20downloads&color=7c3aed" alt="monthly downloads"></a> <a href="https://github.com/AVIDS2/memorix/actions/workflows/ci.yml"><img src="https://img.shields.io/github/actions/workflow/status/AVIDS2/memorix/ci.yml?style=for-the-badge&label=CI&logo=github" alt="CI"></a> <a href="LICENSE"><img src="https://img.shields.io/badge/license-Apache%202.0-2563eb?style=for-the-badge" alt="license"></a> <a href="https://github.com/AVIDS2/memorix"><img src="https://img.shields.io/github/stars/AVIDS2/memorix?style=for-the-badge&logo=github&color=facc15" alt="stars"></a> </p>

<p align="center"> <a href="https://registry.modelcontextprotocol.io/?q=io.github.AVIDS2%2Fmemorix">Listed in the official MCP Registry</a> <br> <a href="https://mcptoplist.com/server/io.github.AVIDS2%2Fmemorix"><img src="https://mcptoplist.com/badge/io.github.AVIDS2%2Fmemorix.svg" alt="View Memorix on MCP Toplist"></a> </p>

<p align="center"> <strong>Shared Project Memory</strong> | <strong>MCP</strong> | <strong>Git Memory</strong> | <strong>Reasoning Memory</strong> | <strong>Plugins</strong> | <strong>Orchestration</strong> </p>

<p align="center"> <a href="https://mem.rglens.com">Website</a> | <a href="README.zh-CN.md">Chinese</a> | <a href="#install">Install</a> | <a href="#capabilities">Capabilities</a> | <a href="#works-with-your-agent">Agents</a> | <a href="#quick-start">Quick Start</a> | <a href="#memory-model">Memory Model</a> | <a href="#memcode-bundled-terminal-agent">memcode</a> | <a href="ACTIVE_WORK.md">Active Work</a> | <a href="#docs">Docs</a> </p>


Maintainer status and the current public work boundary live in ACTIVE_WORK.md. It is the repository's single living work tracker.

<h2 id="what-memorix-is"><picture><source media="(prefers-color-scheme: dark)" srcset="assets/tags/light/section-overview.svg"><img src="assets/tags/section-overview.svg" alt="Memorix" height="32" /></picture></h2>

Memorix gives the AI coding agents you already use a shared, searchable project memory that survives new chats, IDE switches, terminal sessions, and handoffs. The memory lives under the Git project, not inside one chat window or one tool.

Use Claude Code today, Codex tomorrow, and Cursor in the afternoon. The agent can change; the project memory stays the same.

Use Memorix when you keep re-explaining the same project to a new agent session: the last session already figured something out, another IDE cannot see it, or a design decision is buried in a chat you cannot find anymore.

ProblemWhat Memorix adds
The next session forgets what the last session learnedProject-scoped memory, session summaries, timelines, and detail retrieval
Different agents know different thingsOne local memory pool available through MCP, hooks, CLI, SDK, and the bundled terminal agent
Git records what changed, but agents cannot recall it wellGit Memory turns commits into searchable engineering facts
Architecture decisions disappear into old chatsReasoning Memory stores why choices were made, with alternatives and trade-offs
Static rule files driftGotchas, fixes, and project skills evolve from real work
Parallel agent work gets messymemorix orchestrate coordinates task context, handoffs, locks, verification, and review loops

Memorix is local-first. SQLite is the canonical store. Small projects use the in-process Orama path; larger projects use a persistent SQLite FTS5 candidate index and, when available, an optional local LanceDB semantic shadow index. Both indexes are rebuildable and are never a limit on how many durable memories you can keep. LLM-backed formation and embedding remain optional.

Capabilities

Memorix is more than a memory store. It also installs agent integrations, keeps useful work events, turns commits into project facts, exposes a local control plane, and can coordinate multi-agent work when a task needs it.

CapabilityWhat it doesEntry point
Memory AutopilotA bounded task Workset with start files, current memory, source-backed knowledge, workflow starts, cautions, and verification. Compact JSON receipts keep fallback CLI use bounded too.memorix context "..." --brief-json, memorix resume "..." --brief-json, memorix_project_context
Observation MemorySearchable facts, fixes, gotchas, session summaries, and implementation notes scoped to the current Git projectmemorix memory, MCP memory tools
Curated Long-term MemoryDeliberately reviewed episodic, semantic, and procedural memory with source evidence. Only an explicitly portable user item can cross local projectsmemorix memory long-term
Code State and Code MemoryVersioned local code snapshots, source-backed TypeScript/JavaScript symbols and relations, file/symbol links, and freshness checks. Other languages keep the honest Lite fallback; an already-indexed local CodeGraph or SCIP result can add a bounded external outline without taking over the local index.memorix codegraph status|refresh|init|sync, automatic context refresh
Git MemoryCommit-derived engineering facts that answer what changed, where, and why it mattersmemorix ingest commit, git hook
Reasoning MemoryDesign rationale, alternatives, trade-offs, and risks that should survive beyond one chatmemorix reasoning, memory formation
Knowledge WorkspaceReview-gated source-backed claims, Markdown pages, and canonical project workflows; proposals never overwrite reviewed pages silentlymemorix knowledge, memorix knowledge workflow
Agent setupOne setup path for MCP, rules, hooks, skills, plugins, bundles, or extensions depending on the agentmemorix setup --agent <agent>
Agent doctorChecks whether agent MCP config and guidance are current, then repairs Memorix-owned entries when neededmemorix doctor agents, memorix repair agents
Hooks and skillsOptional capture from supported agents, plus reusable project skills promoted from durable knowledgememorix hooks, memorix skills
Dashboard and HTTPA local web UI and shared MCP endpoint for browsing memory, project state, teams, diagnostics, and preview-first cleanup, consolidation, deduplication, and retention actionsmemorix dashboard, memorix background start
Orchestration and team workTask planning, worker handoffs, file locks, messages, verification gates, and review loopsmemorix orchestrate, memorix team, memorix lock
memcodeA bundled terminal coding agent that already reads and writes the same project memorymemorix, memcode
CLI and SDKScriptable access for automation, imports/exports, diagnostics, and custom integrationsmemorix ..., createMemoryClient()
Optional multi-device syncPrivacy-filtered observation events with local SQLite kept canonical; default project scope, optional --scope user for every local project; GitHub JSONL, filesystem, S3, or Postgres relaymemorix sync store status|push|pull

<h2 id="works-with-your-agent"><picture><source media="(prefers-color-scheme: dark)" srcset="assets/tags/light/section-agents.svg"><img src="assets/tags/section-agents.svg" alt="Works with every agent" height="32" /></picture></h2>

Memorix connects through the interfaces each agent already supports: plugin packages, MCP, project rules, hooks, skills, or the bundled terminal agent. memorix setup chooses the right setup for each agent and keeps stdio MCP as the default transport.

<table> <tr> <td align="center" width="12.5%"> <a href="https://claude.com/product/claude-code"><img src="https://github.com/anthropics.png?size=120" alt="Claude Code" width="48" height="48"></a><br> <strong>Claude Code</strong><br> <sub>official plugin + MCP + hooks + skills</sub> </td> <td align="center" width="12.5%"> <a href="https://github.com/openai/codex"><img src="https://github.com/openai.png?size=120" alt="Codex CLI" width="48" height="48"></a><br> <strong>Codex CLI</strong><br> <sub>official plugin + MCP + AGENTS.md</sub> </td> <td align="center" width="12.5%"> <a href="https://github.com/features/copilot"><img src="https://github.githubassets.com/images/modules/site/copilot/copilot.png" alt="GitHub Copilot CLI" width="48" height="48"></a><br> <strong>GitHub Copilot CLI</strong><br> <sub>plugin + MCP + hooks + skills</sub> </td> <td align="center" width="12.5%"> <a href="https://cursor.com"><picture><source media="(prefers-color-scheme: dark)" srcset="https://svgl.app/library/cursor_dark.svg"><img src="https://svgl.app/library/cursor_light.svg" alt="Cursor" width="48" height="48"></picture></a><br> <strong>Cursor</strong><br> <sub>MCP + rules + skills</sub> </td> <td align="center" width="12.5%"> <a href="https://windsurf.com"><picture><source media="(prefers-color-scheme: dark)" srcset="https://svgl.app/library/windsurf-dark.svg"><img src="https://svgl.app/library/windsurf-light.svg" alt="Windsurf" width="48" height="48"></picture></a><br> <strong>Windsurf</strong><br> <sub>MCP + rules + hooks</sub> </td> <td align="center" width="12.5%"> <a href="https://github.com/google-gemini/gemini-cli"><img src="https://github.com/google-gemini.png?size=120" alt="Gemini CLI" width="48" height="48"></a><br> <strong>Gemini CLI</strong><br> <sub>extension + MCP + hooks + skills</sub> </td> </tr> <tr> <td align="center" width="12.5%"> <a href="https://github.com/opencode-ai/opencode"><picture><source media="(prefers-color-scheme: dark)" srcset="https://svgl.app/library/opencode-dark.svg"><img src="https://svgl.app/library/opencode.svg" alt="OpenCode" width="48" height="48"></picture></a><br> <strong>OpenCode</strong><br> <sub>local plugin + MCP + skills + AGENTS.md</sub> </td> <td align="center" width="12.5%"> <a href="https://pi.dev"><img src="https://pi.dev/favicon.svg" alt="pi coding agent" width="48" height="48"></a><br> <strong>pi coding agent</strong><br> <sub>package + extension + skill</sub> </td> <td align="center" width="12.5%"> <a href="https://kiro.dev"><img src="https://kiro.dev/icon.svg" alt="Kiro" width="48" height="48"></a><br> <strong>Kiro</strong><br> <sub>MCP + steering + hooks</sub> </td> <td align="center" width="12.5%"> <a href="https://antigravity.google"><img src="https://antigravity.google/assets/image/antigravity-logo.png" alt="Antigravity" width="48" height="48"></a><br> <strong>Antigravity</strong><br> <sub>plugin + MCP + hooks + skills</sub> </td> <td align="center" width="12.5%"> <a href="https://www.trae.ai"><img src="https://github.com/Trae-AI.png?size=120" alt="Trae" width="48" height="48"></a><br> <strong>Trae</strong><br> <sub>MCP + project rules</sub> </td> <td align="center" width="12.5%"> <img src="https://raw.githubusercontent.com/AVIDS2/memorix/main/assets/logo.png" alt="memcode" width="48" height="48"><br> <strong>memcode</strong><br> <sub>bundled terminal agent</sub> </td> </tr> <tr> <td align="center" width="12.5%"> <a href="https://docs.openclaw.ai"><img src="https://raw.githubusercontent.com/openclaw/openclaw/main/ui/public/favicon.svg" alt="OpenClaw" width="48" height="48"></a><br> <strong>OpenClaw</strong><br> <sub>bundle + MCP + hooks + skills</sub> </td> <td align="center" width="12.5%"> <a href="https://hermes-agent.nousresearch.com"><img src="https://hermes-agent.nousresearch.com/icon.png" alt="Hermes Agent" width="48" height="48"></a><br> <strong>Hermes Agent</strong><br> <sub>plugin + MCP + hooks + skills</sub> </td> <td align="center" width="12.5%"> <a href="https://omp.sh"><img src="https://omp.sh/favicon.png" alt="Oh-my-Pi" width="48" height="48"></a><br> <strong>Oh-my-Pi</strong><br> <sub>package + MCP + hooks + skills</sub> </td> <td align="center" width="12.5%"> <a href="https://github.com/deepseek-ai/deepseek-harness"><img src="https://github.com/deepseek-ai.png?size=120" alt="DeepSeek Harness" width="48" height="48"></a><br> <strong>DeepSeek Harness</strong><br> <sub>MCP patch + AGENTS.md + skills</sub> </td> <td align="center" width="12.5%"> <a href="https://modelcontextprotocol.io"><img src="https://github.com/modelcontextprotocol.png?size=120" alt="Any MCP Client" width="48" height="48"></a><br> <strong>Any MCP Client</strong><br> <sub>stdio or HTTP MCP</sub> </td> <td align="center" width="12.5%"> <a href="https://github.com/xai-org/grok-build"><picture><source media="(prefers-color-scheme: dark)" srcset="https://media.x.ai/v1/website/spacexai-symbol-white-transparent-0c31957f.png"><img src="https://media.x.ai/v1/website/spacexai-symbol-black-transparent-6435cf42.png" alt="Grok Build" width="48" height="48"></picture></a><br> <strong>Grok Build</strong><br> <sub>native hooks + AGENTS.md</sub> </td> </tr> </table>

<p align="center"> <sub>Works with agents that speak MCP, expose hooks/rules, or support plugin/package entries. One local-first memory layer shared across all of them.</sub> </p>

Integration surfaces:

SurfaceWhat it doesMemorix entry
Setup commandInstalls the recommended one-time user-level Memorix integrationmemorix setup --agent <agent> --global
MCPGives an agent compact Memorix tools for project context, search, detail retrieval, storage, and resolutionbundled in setup packages or memorix serve
Usage guidanceTeaches an agent when and how to use Memorix without forcing memory lookup on every promptbundled or generated by memorix setup
HooksOptional capture of prompts, tool events, file edits, session lifecycle events, and native compaction checkpoints where the agent exposes thembundled or generated by memorix setup
Plugin or bundle packageInstalls plugin, compatible-bundle, or package files where the agent supports themClaude Code, Codex, CodeBuddy Code, GitHub Copilot CLI, Antigravity, OpenClaw, Hermes Agent, Oh-my-Pi, Pi
ExtensionInstalls extension files where the agent supports themGemini CLI
Local pluginInstalls local plugin files where the agent loads them directlyOpenCode
MCP/rules configWrites MCP, rules, steering, guidance, or hook config for IDEs and agents that expose those surfacesCursor, Windsurf, Kiro, Trae, DeepSeek Harness, WorkBuddy
SkillsTurns durable project knowledge into reusable task guidancememorix skills and memorix_promote
memcodeOpens the bundled terminal agent that already uses Memorix memorymemorix or memcode

See Integration Surfaces for the current support matrix and what each generated file means.

Use the same setup command without --global only when you intentionally want repo-local guidance, rules, or hooks in the current Git project.

CLI, MCP, and HTTP are different entry points:

  • memorix CLI is the direct command surface for setup, memory search/store, Git Memory, import/export, dashboard, orchestration, diagnostics, and automation.

  • memorix serve is the stdio MCP bridge used by IDEs and coding agents. Its default tool profile is micro, so agents see only the compact core tool set.

  • memorix background start / memorix serve-http run the HTTP service for a shared endpoint, dashboard, VPS Docker deployment, or multiple clients.

Multi-device store sync is opt-in and separate from HTTP sharing. It never uploads the live SQLite database or WAL files. By default it only relays qualified project-visible observations for the current Git project; personal, agent-targeted, candidate, and ephemeral records stay local. Pass --scope user to include every local project. Set MEMORIX_SYNC_PROVIDER and inspect memorix sync store status --json before the first push.

<h2 id="install"><picture><source media="(prefers-color-scheme: dark)" srcset="assets/tags/light/section-install.svg"><img src="assets/tags/section-install.svg" alt="Install" height="32" /></picture></h2>

Requirements:

  • Node.js >=22.18.0

  • Git, because project identity is derived from the real Git root

Install and initialize:

npm install -g memorix
memorix init --global                   # optional defaults
memorix setup --agent claude --global   # or codex, copilot, cursor, pi, gemini-cli, opencode,
                                       # codebuddy, windsurf, kiro, antigravity, trae, openclaw, hermes, omp

memorix init is optional. It creates or updates TOML configuration:

  • ~/.memorix/config.toml for global defaults

  • <git-root>/memorix.toml for optional project overrides

Legacy memorix.yml, .env, and ~/.memorix/config.json are still read for compatibility, but new setup flows use TOML.

If you want repo-local guidance or hooks for a specific repository, run the same setup command from inside that repo without --global. Codex is the exception: its supported path is the user-level plugin install, so Memorix leaves project .codex configuration alone.

<h2 id="quick-start"><picture><source media="(prefers-color-scheme: dark)" srcset="assets/tags/light/section-quick-start.svg"><img src="assets/tags/section-quick-start.svg" alt="Quick Start" height="32" /></picture></h2>

Connect an existing agent

Use the setup command first. The global form is the normal one-time install:

memorix setup --agent claude --global
memorix setup --agent codex --global
memorix setup --agent copilot --global
memorix setup --agent cursor --global
memorix setup --agent pi --global
memorix setup --agent gemini-cli --global
memorix setup --agent opencode --global
memorix setup --agent windsurf --global
memorix setup --agent kiro --global
memorix setup --agent antigravity --global
memorix setup --agent trae --global
memorix setup --agent openclaw --global
memorix setup --agent hermes --global
memorix setup --agent codebuddy --global
memorix setup --agent omp --global
memorix setup --agent dsh --global
memorix setup --agent workbuddy --global
memorix setup --agent grok --global

What it installs depends on the target agent, but the goal is the same: make Memorix available wherever you open that agent without asking you to wire every repo by hand.

  • Claude Code: installs the Memorix plugin package, adds CLAUDE.md guidance, and enables hook capture when you do not pass --noHooks.

  • Codex: installs one user-level Memorix plugin with bundled stdio MCP, skills, and lifecycle hooks. It does not write project-local .codex config or change your model, approval, or sandbox settings. When Codex asks, review the plugin hook definition once with /hooks; --noHooks skips automatic capture.

  • GitHub Copilot CLI: installs the Copilot plugin package and official Memorix skills.

  • Pi: installs the Pi extension/skills package and native MCP config (Pi 1.0+): ~/.pi/agent/mcp.json with --global, or .pi/mcp.json for project setup.

  • Cursor: writes Cursor MCP/rules/config entries in the chosen scope.

  • Gemini CLI: installs the extension package, GEMINI.md context, hooks, and skills. Antigravity CLI has an official Gemini CLI migration path, but Gemini CLI remains an active standalone target.

  • OpenCode: installs the local plugin file, opencode.json, skills, and AGENTS.md guidance.

  • Windsurf, Kiro, Trae: write the MCP/rules/hooks files the target supports.

  • Antigravity: installs the official plugin package with plugin.json, mcp_config.json, hooks.json, rules, and skills under ~/.gemini/config/plugins/memorix or .agents/plugins/memorix.

  • OpenClaw: installs an OpenClaw-compatible bundle with .mcp.json, official skills, and an OpenClaw HOOK.md/handler.ts hook pack.

  • Hermes Agent: installs into Hermes home (%LOCALAPPDATA%\hermes on native Windows, ~/.hermes elsewhere, or HERMES_HOME), enables the plugin in config.yaml, registers plugin hooks, slash/CLI commands, skills, and writes MCP config.

  • CodeBuddy Code: installs a user-scope local marketplace plugin under ~/.codebuddy/memorix-local with MCP, skills, and hooks. It does not change existing CodeBuddy model, permission, or settings files; CodeBuddy keeps third-party hook approval in its own /hooks flow.

  • Oh-my-Pi: installs an omp.extensions package with extension hook events, a memorix command, official skills, and writes MCP config.

  • DeepSeek Harness: writes a Memorix @deepseek-ai/dsh-mcp-client row into $DSH_HOME/cordis.patch.yml (default ~/.dsh/cordis.patch.yml), appends guidance to the harness AGENTS.md, and installs official skills under $DSH_HOME/skills. The row follows DSH's own shipped Memorix reference, so tools appear as mcp__memorix__*.

  • WorkBuddy: writes a Memorix MCP server row into ~/.workbuddy/mcp.json (or <project>/.workbuddy/mcp.json for project installs) and appends guidance to AGENTS.md. Tools appear as mcp__memorix__*; there is no hooks surface.

  • Grok Build: installs native lifecycle hooks under ~/.grok/hooks/memorix.json and guidance in ~/.grok/AGENTS.md. MCP stays host-owned by default; pass --mcp http to write [mcp_servers.memorix] with url = "http://localhost:3211/mcp". Project-local hooks require Grok /hooks-trust, while global hooks are trusted. Set GROK_HOME to use a custom Grok home.

Need a quieter install? Add --noHooks for targets where setup can control hook capture separately from the host's official package entry. It keeps MCP and guidance, but skips Memorix hook capture.

If you intentionally want repo-local guidance or hooks, run the same command inside that repository without --global.

If your agent only needs a manual MCP entry, use stdio:

{
  "mcpServers": {
    "memorix": {
      "command": "memorix",
      "args": ["serve"]
    }
  }
}

For an npm-based MCP client or registry tester, use the complete command npx -y memorix serve. The serve argument matters: memorix without arguments opens the bundled memcode terminal agent when run by a human, while MCP clients should start the stdio server explicitly.

For a manually managed Claude Code entry, add "alwaysLoad": true inside the memorix server object. This lets Claude Code expose Memorix tools during print-mode startup; memorix doctor agents --agent claude can detect and repair a missing setting.

HTTP is not required for normal setup. Use it only when you intentionally want a shared background service, dashboard, VPS Docker deployment, or multiple clients using the same endpoint. Local development uses the Node service directly and does not require Docker:

memorix background start

Then point the client at:

http://localhost:3211/mcp

In HTTP mode, agents should bind the active repo explicitly with memorix_session_start(projectRoot=...) when the client can provide the workspace path. Git remains the final source of truth for project identity.

Uninstall

Preview what will be removed:

memorix uninstall --dry-run

Stop the background service and remove hooks:

memorix uninstall --background --hooks

Full cleanup:

memorix uninstall --yes --background --hooks --purge-data
npm uninstall -g memorix

memorix uninstall reports MCP config entries for manual cleanup instead of silently editing every MCP file it finds.

Work from the CLI
memorix --cwd /path/to/repo resume "continue release blocker"
memorix checkpoint list
memorix memory search --query "release blocker"
memorix memory --help

# Optional: activate one local agent identity for personal/team records and coordination.
memorix identity join --agent-type codex --name codex-main
memorix memory store --text "private investigation note" --visibility personal
memorix task create --description "verify the release package"

# Deliberate durable memory: create a candidate, then review it before it can enter a Workset.
memorix memory long-term add --kind procedural --scope user --portability portable --title "Release verification preference" --text "Run focused tests and a packed-package smoke before publishing." --applicability "When publishing an npm package."
memorix memory long-term qualify --id <id> --reason "The user explicitly confirmed this preference."
memorix memory long-term approve --id <id> --reason "Reviewed for future local projects."

memorix transfer export --format json --out ./.memorix-export.json
memorix transfer import --file ./.memorix-export.json
memorix reasoning search --query "why sqlite"
memorix git-hook --force
memorix ingest log --count 20
memorix workbench

The CLI is direct and does not depend on an MCP session. It binds to the current Git project, or to the project supplied with --cwd. Without an active identity it reads, writes, and exports project-visible memory only. Use memorix identity join or memorix identity use --agent-id <id> only when you intentionally need personal/team memory or coordinated task actions; memorix identity clear returns the terminal to project scope. --as <active-agent-id> is the one-command alternative for scripts. Both camelCase and kebab-case flags are accepted.

Manage controlled media

Media is opt-in. An explicit local import is copied into Memorix's local data directory, hashed, and kept outside the Git worktree. It becomes normal memory only when you attach it. Memorix never captures every screenshot or tool output. An asset may be up to the configured media limit (100 MiB by default). Automatic vision analysis is deliberately capped at 20 MiB; a larger image is still kept and can be attached, but Memorix records a clear text fallback instead of sending an oversized payload to a model provider.

memorix media import --path ./architecture.png --json
memorix media attach --asset <asset-id> --title "Architecture diagram" --json
memorix media list --kind image --json
memorix media show --asset <asset-id> --json
memorix media remove --asset <asset-id> --force --json

# Controlled derivations: explicit, bounded, and attachable to memory.
memorix media derive-pdf --asset <asset-id> --attach --json
memorix media derive-audio --asset <asset-id> --attach --json

# Legacy image analysis now uses the same controlled asset lifecycle.
memorix ingest image --path ./architecture.png --json

MiniMax image generation is a deliberate CLI operation. Video generation returns a durable job immediately; inspect or cancel that job rather than waiting in an agent request.

# Configure MINIMAX_API_KEY in your user environment or .env, never in Git.
memorix media generate image --prompt "A clean system architecture diagram" --json
# Image-to-image with a reference image (MiniMax image-01 / image-01-live):
memorix media generate image --prompt "Keep the subject, change the background" --image ./reference.png --json
memorix media generate video --prompt "A short product walkthrough" --json
memorix media status --job <media-job-id> --json
memorix media cancel --job <media-job-id> --json

memorix_media is the compact MCP companion in every profile, including micro. It supports import, attach, list, show, PDF/audio derivations, generation, and job status. MCP image and video generation are disabled by default because they may incur provider costs. Set MEMORIX_MCP_MEDIA_GENERATION=1 only after you deliberately want an agent to request billed MiniMax output. The normal OpenRouter text embedding lane is still text-only; media vectors are created only by a provider that explicitly declares support for that modality. Text descriptions and attachments remain a useful ordinary retrieval fallback.

Use the bundled terminal agent
memorix
# or
memcode

This opens memcode, a terminal coding agent that uses the same Memorix project memory as your MCP-connected agents.

<h2 id="memory-model"><picture><source media="(prefers-color-scheme: dark)" srcset="assets/tags/light/section-memory-model.svg"><img src="assets/tags/section-memory-model.svg" alt="Memory Model" height="32" /></picture></h2>

LayerStoresBest for
Observation Memoryfacts, gotchas, fixes, implementation notes"How does this work?"
Reasoning Memoryrationale, alternatives, constraints, risks"Why did we choose this?"
Git Memorycommit-derived engineering facts"What changed and where?"
Code Memoryfiles, symbols, import edges, and memory-to-code freshness"Which current code should I inspect first?"
Curated Long-term Memoryreviewed episodic events, stable facts, or reusable procedures with evidence"What should this agent still know or do later?"
Compact Continuityrecent host-native compact summaries or lifecycle markers"What survived the last context compaction?"

Search is project-scoped by default. scope="global" searches across projects. The search boosts Git Memory for "what changed" questions and reasoning records for "why" questions.

Long-term memory is deliberately not an automatic dump of every note. A source observation, Claim, workflow, session, and code snapshot keep their existing roles. An agent may ask memorix_store to create an additional long-term record; an explicit request auto-qualifies and enters task briefs as a durable anchor, while hook-captured or Git-derived candidates stay pending until qualified. Approval stays an explicit operator review. Use memorix memory long-term approve|archive|supersede to record the evidence-backed lifecycle. Only a manually created or user-confirmed user + portable item may be considered in another local project; project code, Git facts, tests, workflows, sessions, and observations cannot be promoted into portable user memory.

memorix context "..." is the default Memory Autopilot entry. It builds a compact task-lensed brief for agents: bugfix tasks lean toward tests and repros, release tasks lean toward package/changelog/build checks, onboarding tasks lean toward docs and entry points, and stale or unrelated memories stay in warning lanes instead of flooding the prompt. Use --fallback --brief-json when MCP is unavailable and a CLI fallback needs the same bounded brief plus a receipt of what was selected or omitted; --json remains the detailed diagnostic form. A normal new task does not receive an old-session dump. For an explicit continuation, memorix resume "..." adds only the latest useful session summary, up to three readable durable anchors, and at most one recent source-labelled host compact checkpoint. A durable anchor carries a durable:<id> reference, so an agent can expand the full reviewed record through memorix_detail only when needed. Keyword matches stay primary; when no reviewed durable item matches and an embedding provider is configured, Memorix makes one 1.8-second, no-retry semantic fallback for paraphrases or cross-language tasks. A slow or unavailable provider simply leaves the normal keyword-only Workset intact. A checkpoint is lifecycle evidence, not durable memory or a transcript backup. Agents should read the suggested files before trusting stored memory.

<h2 id="runtime-modes"><picture><source media="(prefers-color-scheme: dark)" srcset="assets/tags/light/section-runtime.svg"><img src="assets/tags/section-runtime.svg" alt="Runtime Modes" height="32" /></picture></h2>

You wantRun
Install an agent integration packagememorix setup --agent <agent> --global
Check or repair an agent integrationmemorix doctor agents --agent <agent>, memorix repair agents --agent <agent>
Manually expose stdio MCPmemorix serve
Run shared HTTP MCP plus dashboardmemorix background start
Debug HTTP MCP in the foregroundmemorix serve-http --port 3211
Inspect or manage memory directlymemorix memory, memorix reasoning, memorix session, memorix ingest, memorix media
Manage reviewed long-term memory`memorix memory long-term list
Retire memories from retrievalmemorix purge (current project), memorix purge --all --yes (everything)
Inspect native compaction continuity`memorix checkpoint list
Use the interactive terminal memory control planememorix workbench
Use the bundled terminal agentmemorix or memcode
Run orchestrated subagent workmemorix orchestrate --goal "..."

memorix serve defaults to --mode micro (9 tools) to keep MCP tool schemas small for agents. memorix setup writes --mode lite (21 tools) into the installed MCP config so the normal memory, continuity, and session surface is reachable. Use --mode team (29 tools) for coordination tools, or --mode full (48 tools) for advanced and compatibility tools such as checkpoint inspection.

Shortcuts and aliases: memorix search / remember / recent are direct query shortcuts, bg/bs start the background service, hook runs the hook launcher, and memorix config get|path|migrate inspects or migrates config files.

memorix orchestrate uses the current checkout for single-worker runs. When running multiple workers, it creates task worktrees under .worktrees/ and merges successful task branches back. Use --isolated to force worktree isolation for one worker, --no-worktree to disable it, --allow-dirty to run with uncommitted changes, and --no-auto-merge to preserve task worktrees for manual review.

<h2 id="memcode-bundled-terminal-agent"><picture><source media="(prefers-color-scheme: dark)" srcset="assets/tags/light/section-memcode.svg"><img src="assets/tags/section-memcode.svg" alt="memcode" height="32" /></picture></h2>

memcode is the terminal coding agent bundled with Memorix. It can read, edit, run commands, resume sessions, switch models, and use /memory commands — all backed by the same project memory as your MCP-connected agents.

Use it when you want a terminal agent with memory already wired in.

one Git project -> one shared Memorix memory pool

See docs/MEMCODE.md for the memcode-specific guide.

<h2 id="configuration"><picture><source media="(prefers-color-scheme: dark)" srcset="assets/tags/light/section-configuration.svg"><img src="assets/tags/section-configuration.svg" alt="Configuration" height="32" /></picture></h2>

Minimal ~/.memorix/config.toml:

[agent]
provider = "openai"
model = "gpt-4o"
api_key = "..."

[memory.llm]
provider = "openai"
model = "gpt-4o-mini"
api_key = "..."

[embedding]
provider = "auto"

[memory]
inject = "minimal"
formation = "active"

Use [memory.llm] and [embedding] for Memorix memory quality and retrieval. Use [agent] for the model memcode talks to while coding. Keep credentials in global config or environment variables, and do not commit secrets.

For the optional Atlas Cloud memory preset, run memorix init and choose Atlas Cloud, or set provider = "atlascloud" in [memory.llm]. It uses the OpenAI-compatible https://api.atlascloud.ai/v1 endpoint and reads ATLASCLOUD_API_KEY or the explicit MEMORIX_LLM_API_KEY.

For OpenRouter embeddings, use provider = "api", base_url = "https://openrouter.ai/api/v1", and model = "qwen/qwen3-embedding-8b". Memorix accepts OPENROUTER_API_KEY for that embedding endpoint; MEMORIX_EMBEDDING_API_KEY remains the explicit override.

For Requesty, choose Requesty in memorix init or set provider = "requesty" in [memory.llm] (endpoint https://router.requesty.ai/v1, key from REQUESTY_API_KEY or MEMORIX_LLM_API_KEY). Requesty embeddings use provider = "api", base_url = "https://router.requesty.ai/v1", and model = "openai/text-embedding-3-small" with REQUESTY_API_KEY.

For API Route, choose API Route in memorix init or set provider = "apiroute" in [memory.llm]. The preset uses https://global.api-route.com/v1 and deepseek-v4.1-flash, with your own API_ROUTE_API_KEY or MEMORIX_LLM_API_KEY. It is opt-in memory LLM processing; embeddings and memcode's model registry are configured separately. See configuration.

For Cheaper Inference, choose Cheaper Inference in memorix init or set provider = "cheaperinference" in [memory.llm]. The preset uses https://api.cheaperinference.com/v1 and gpt-5.4-mini, with your own CHEAPER_INFERENCE_API_KEY or MEMORIX_LLM_API_KEY. It is opt-in memory LLM processing; embeddings and memcode's model registry are configured separately. See configuration.

For Runcrate, choose Runcrate in memorix init or set provider = "runcrate" in [memory.llm]. The preset uses https://api.runcrate.ai/v1 and the open-weight deepseek-ai/DeepSeek-V4.1-Flash, with your own RUNCRATE_API_KEY or MEMORIX_LLM_API_KEY. It is opt-in memory LLM processing; embeddings and memcode's model registry are configured separately. See configuration.

For controlled MiniMax media generation, set MINIMAX_API_KEY (global) or MINIMAX_CN_API_KEY (China region) in your environment or .env. The media library never stores that key, a signed output URL, or base64 payloads. CLI generation is explicit; MCP generation additionally requires MEMORIX_MCP_MEDIA_GENERATION=1.

<h2 id="docker"><picture><source media="(prefers-color-scheme: dark)" srcset="assets/tags/light/section-docker.svg"><img src="assets/tags/section-docker.svg" alt="Docker" height="32" /></picture></h2>

Docker is a VPS/hosted HTTP deployment option, not a requirement for local development or stdio MCP:

docker compose up --build -d

Then open:

  • dashboard: http://localhost:3211

  • MCP: http://localhost:3211/mcp

  • health: http://localhost:3211/health

The container must be able to access the repository path passed as projectRoot for project-scoped Git and config behavior.

<h2 id="sdk"><picture><source media="(prefers-color-scheme: dark)" srcset="assets/tags/light/section-sdk.svg"><img src="assets/tags/section-sdk.svg" alt="SDK" height="32" /></picture></h2>

Use Memorix directly from TypeScript:

import { createMemoryClient } from 'memorix/sdk';

const client = await createMemoryClient({ projectRoot: '/path/to/repo' });

await client.store({
  entityName: 'auth-module',
  type: 'decision',
  title: 'Use JWT for API auth',
  narrative: 'Chose JWT because the API is stateless and used by multiple clients.',
});

const results = await client.search({ query: 'auth decision' });
await client.close();

<h2 id="docs"><picture><source media="(prefers-color-scheme: dark)" srcset="assets/tags/light/section-docs.svg"><img src="assets/tags/section-docs.svg" alt="Docs" height="32" /></picture></h2>

Start hereUse when
Docs MapYou want the shortest route to the right guide
Setup GuideInstalling, using memorix setup, choosing stdio vs HTTP
Integration SurfacesPlugin packages, MCP, project rules, hooks, and skills support
ConfigurationTOML config, model lanes, compatibility files
API ReferenceMCP tools and CLI commands
Git MemoryCommit ingestion and searchable engineering truth
DockerContainerized HTTP service
memcodeUsing the bundled terminal agent
Agent PlaybookAI-facing execution guide for install, binding, hooks, and troubleshooting
DevelopmentContributing, testing, release checks
ChangelogWhat changed in each release

LLM-friendly summaries: llms.txt and llms-full.txt.

<h2 id="development"><picture><source media="(prefers-color-scheme: dark)" srcset="assets/tags/light/section-development.svg"><img src="assets/tags/section-development.svg" alt="Development" height="32" /></picture></h2>

git clone https://github.com/AVIDS2/memorix.git
cd memorix
npm install
npm run lint
npm test
npm run build

Community

Desktop and shell integrations built on Memorix:

  • omarchy-memorix — a native Omarchy shell bar widget: pool stats, live global search, per-project breakdown, recent memories, and a workbench launcher. Read-only over ~/.memorix/data; no daemons, no telemetry.

Built something on top of Memorix? Open a PR to list it here.

<h2 id="acknowledgements"><picture><source media="(prefers-color-scheme: dark)" srcset="assets/tags/light/section-acknowledgements.svg"><img src="assets/tags/section-acknowledgements.svg" alt="Acknowledgements" height="32" /></picture></h2>

Memorix draws from the MCP ecosystem and prior memory projects such as mcp-memory-service, MemCP, claude-mem, and Mem0. memcode is based on the Pi coding-agent codebase and adapts its terminal-agent model for the Memorix ecosystem.

<h2 id="license"><picture><source media="(prefers-color-scheme: dark)" srcset="assets/tags/light/section-license.svg"><img src="assets/tags/section-license.svg" alt="License" height="32" /></picture></h2>

Apache 2.0

<h2 id="star-history">Star History</h2>

<a href="https://github.com/AVIDS2/memorix/stargazers"> <picture> <source media="(prefers-color-scheme: dark)" srcset="https://mem.rglens.com/metrics/star-history-dark.svg"> <source media="(prefers-color-scheme: light)" srcset="https://mem.rglens.com/metrics/star-history-light.svg"> <img alt="Memorix Star History" src="https://mem.rglens.com/metrics/star-history-light.svg" width="100%"> </picture> </a>

<sub>Updated automatically from GitHub's privacy-safe star history API. No generated PRs.</sub>

docs/ARCHITECTURE.md

Memorix Architecture

Memorix is an open-source cross-agent memory layer for coding agents via MCP.

Architecture audit: 2026-11-05

The current implementation is feature-rich but boundary-fragile. The largest runtime files are src/server.ts (~5.5k lines), src/store/orama-store.ts (~1.7k), src/memory/observations.ts (~1.6k), and src/cli/commands/setup.ts (~1.9k). Around 139 direct environment/config reads are spread across src/, and multiple hosts assemble the same project context independently. This explains why fixes repeatedly appear in several layers and why derived-index failures can look like successful empty state.

The project is not suffering from one bad model or one bad dependency. It has a missing kernel boundary: canonical records, derived views, retrieval policy, runtime hosts, and maintenance jobs are implemented as cooperating conventions rather than enforceable interfaces. New features therefore cross too many mutable singletons and can regress lazy mode, search ranking, retention, or cross-process behavior without a compiler error.

The target architecture below is the refactor contract for 1.11. It preserves SQLite local-first semantics and avoids a wholesale storage rewrite.

0. Current Architecture Audit and Refactor Target

0.1 What is going wrong
  1. Canonical and derived state are mixed in control flow. SQLite is the documented source of truth, but Orama, Lance, CodeGraph, cache hydration, and in-memory observation state each have their own readiness and repair paths. A lazy corpus can be empty in memory while still being healthy in SQLite, yet older callers interpret the empty array as "no missing work".

  2. The write pipeline has too many owners. Observation persistence, embedding scheduling, CodeGraph binding, evidence projection, claims, and maintenance enqueueing all happen from memory/observations.ts. A provider or index failure can therefore affect unrelated write behavior and is hard to test as an isolated contract.

  3. Retrieval policy is distributed. server.ts, orama-store.ts, CodeGraph context assembly, compact formatting, and profile registration each shape what the agent sees. There is no single retrieval plan object that records candidate sources, freshness, cost, abstention, and final selection.

  4. Background jobs report lifecycle, not truth. A job can reach completed while doing zero useful work in a lazy or unavailable state. Maintenance needs progress counters and explicit degraded/retry outcomes.

  5. Runtime hosts duplicate binding and policy. stdio, HTTP, hooks, CLI, and Dashboard call adjacent functions with different defaults. The codegraph refresh policy and project binding must be resolved once and passed down.

  6. The current graph is a derived cache without a full retention owner. Snapshot manifests and stale symbols were allowed to grow until #371. The same failure pattern already appeared in Lance metadata in #365.

0.2 Target layers
Host adapters
  stdio MCP | HTTP MCP | CLI | hooks | dashboard | SDK
        |
Runtime facade
  ProjectBinding + ResolvedConfig + SessionScope + RetrievalRequest
        |
Memory kernel
  WritePipeline | RetrievalFacade | MaintenanceCoordinator | EvidencePolicy
        |
Canonical record plane
  SQLite records, scopes, provenance, lifecycle, optional append-only events
        |
Derived view plane
  FTS | Orama | Lance | CodeGraph | receipts | caches

Host adapters may depend on the runtime facade. The runtime facade may depend on the memory kernel. Derived views may read canonical records and publish health, generation, and rebuild operations, but they may never decide that canonical storage is empty or successful. The kernel owns policy; views own mechanics.

0.3 Non-negotiable contracts
  • Canonical truth: all durable records have a stable ID, project/scope, provenance, lifecycle state, created/updated time, and source revision. An index row is never the only copy of a fact.

  • Derived view contract: every view implements status, refresh, rebuild, compact, and close; status distinguishes ready, stale, degraded, rebuilding, and unavailable. No derived failure returns a fake empty result without a receipt.

  • Write contract: the canonical write commits first. Derived work is an idempotent outbox/maintenance action with attempted, succeeded, failed, and remaining counts. A completed job with zero attempted work is not a successful backfill.

  • Retrieval contract: one RetrievalPlan carries query intent, project binding, allowed sources, freshness policy, token budget, and abstention rules. One RetrievalReceipt records candidates, selected IDs, omitted IDs, source generations, elapsed time, and degraded reasons.

  • Freshness contract: current truth and historical belief are separate. Changing a fact supersedes or invalidates the old version; it does not erase the audit record. Future temporal memory work should use valid-time and transaction-time fields rather than another overwrite-only vector row.

  • Context contract: retrieval is progressive disclosure. Index/abstract first, overview next, full detail only on demand. A search tool must never return a large raw corpus as its default answer.

  • Config contract: providers, refresh policy, thresholds, and credentials are resolved once into an immutable runtime config. Business modules do not read process.env directly.

  • Maintenance contract: retention, compaction, backfill, and graph refresh are resumable, observable, bounded, and safe when another process is active.

0.4 Refactor sequence

P0 - contract extraction, current patch line: complete the missing safety fixes, preserve local SQLite, and add regression tests for lazy vectors, CJK search, affinity ordering, CodeGraph growth, shell-free browser launch, and provider isolation.

P1 - 1.11 kernel extraction: introduce src/core/ contracts for ProjectBinding, ResolvedRuntimeConfig, RetrievalPlan, RetrievalReceipt, DerivedView, and MaintenanceResult. Move host code behind these interfaces; do not move data tables yet. Add architecture tests for allowed dependency directions and one store-to-search-to-detail integration fixture.

The first P1 slice is implemented: RuntimeContext captures a verified project and immutable per-request config; CodeGraph uses it. Lance has a concrete DerivedView adapter used by vector writes. Other hosts and derived views still need migration. A dependency test now rejects host, persistence, and adapter imports from src/core/. MaintenanceResult is defined in the kernel; its progress counts are validated before a runner persists them. Maintenance progress is durable in SQLite. The MCP server captures a RuntimeContext after project binding and refreshes it on runtime activation and project switch; CodeGraph host operations consume that immutable configuration snapshot.

SQLite FTS5, Orama, and CodeGraph now have concrete DerivedView adapters alongside Lance. Their lifecycle reports missing, stale, unavailable, and ready states instead of making each host infer index health from an empty result.

P2 - 1.11 durable write pipeline: add a small canonical write service and an idempotent derived-work outbox. Observation capture, Git ingest, and explicit MCP store calls use the same pipeline. Keep formation and provider calls outside canonical SQLite transactions.

The first P2 slice is implemented for vector work: observation writes register the deduplicated backfill job inside the SQLite transaction, foreground success leaves project-level work for the worker to verify, and maintenance rows persist real progress counters. The same transaction now also registers qualification and claim derivation for inserted observations and topic-key updates. Topic-key updates commit SQLite before refreshing Orama; a failed canonical write or linked-record callback leaves the prior search result in place. Other derived projections now use an observation-project outbox item. The foreground path tries CodeGraph and evidence immediately and acknowledges the item only when both succeed; a crash or failure leaves the item for an isolated idempotent retry.

The outbox also records writes that arrive during a running deduplicated job. The worker either performs a follow-up pass after completion, or preserves the new work through retry exhaustion and lease recovery. Recurring jobs process a new event before returning to their long schedule; provider retry cooldowns remain in force. The new SQLite flag defaults to false for pre-1.11 rows.

Automatic cleanup jobs re-check the resolved behavior configuration when they execute. Disabling memory.autoCleanup therefore neutralizes already queued retention, consolidation, and long-term maintenance work without affecting explicit user-requested cleanup actions.

P3 - 1.11 retrieval/context plane: move ranking, freshness, provenance, admission, and progressive disclosure into RetrievalFacade. Keep Orama, Lance, FTS, and CodeGraph adapters replaceable. Add a retrieval evaluation matrix based on real issue-resolution tasks, with recall, precision, latency, token cost, and abstention correctness.

The first P3 slice is implemented: a host-independent facade normalizes the retrieval plan and returns entries with the diagnostics and derived-view status from that same execution. Compact search, SDK, TUI search, TUI chat, and index probes no longer read a project-wide last-search value after another request can overwrite it. The facade applies feedback from the active canonical data directory and records feedback omissions separately from embedding fallback. The existing 20-case offline task matrix passes with a fresh 40k local-store gate; ranking and admission policy still live in their current modules, and the matrix is not an unseen live-task benchmark.

Workset assembly follows the same rule: it uses derived-view status supplied by the current context build and does not read a process-global last-search view. The remaining P3 work is to move more ranking/admission decisions behind the facade and add unseen issue-resolution evaluations.

P4 - 1.12 ecosystem boundary: generate host capability manifests from one registry, validate setup/doctor/repair/uninstall from the same manifest, and keep provider and agent integrations outside the kernel. Add package smoke, provenance, SBOM, and support-matrix checks to release gates.

2.0 remains conditional. A larger version is justified only if remote canonical storage, tenant authorization, or public MCP contracts require a breaking change. File size, accumulated integrations, or a desire to "start clean" are not reasons to rewrite the product.

0.5 Research basis

The refactor follows current agent-memory evidence rather than adding another database for fashion:

  • PROJECTMEM uses typed append-only events and deterministic projections for auditable coding-agent memory.

  • Stratum separates structural, historical, and experiential repository memory and treats retrieval as a page-safe, costed operation.

  • OpenViking uses hierarchical L0/L1/L2 context loading so agents inspect summaries before full detail.

  • Mem0 makes consolidation an explicit ADD/UPDATE/DELETE/NOOP decision rather than appending every observation.

  • Zep/Graphiti demonstrates why temporal validity and transaction history matter when facts change.

  • Recent releases from claude-mem v15.7.0, Hindsight v1.1.0, and Graphiti v0.31.2 emphasize background-job coalescing, environment isolation, redaction, retention, decision-model concurrency, and security defaults. These are operational contracts, not optional polish.

It combines three source-of-truth memory layers and a curated long-term memory layer:

  • Observation Memory for what changed and how things work

  • Reasoning Memory for why choices were made

  • Git Memory for engineering truth derived from commits

  • Long-term Memory for explicitly curated episodic, semantic, and procedural knowledge that should outlive a single project session

Observation, reasoning, and Git records remain the canonical evidence. Long-term memory references that evidence and has its own lifecycle; it is not a second copy of every conversation or a global dump shared between unrelated projects.

These layers are exposed through MCP tools, CLI workflows, and an HTTP service.


1. System Shape

Memorix is better understood as a container-style architecture with multiple ingress surfaces, shared runtimes, several memory substrates, and parallel processing/retrieval branches.

flowchart LR
    subgraph Clients["Clients and Surfaces"]
        A1["IDEs / coding agents"]
        A2["CLI / TUI"]
        A3["Dashboard / browser"]
        A4["Git hooks / ingest"]
    end

    subgraph Runtime["Runtime Services"]
        B1["stdio MCP runtime"]
        B2["HTTP MCP service"]
        B3["project binding + config provenance"]
    end

    subgraph Core["Memory Core"]
        C1["Observation store"]
        C2["Reasoning store"]
        C3["Git memory store"]
        C4["Session / team registry"]
        C5["Curated long-term memory"]
    end

    subgraph Intelligence["Intelligence and Quality"]
        D1["Formation + enrichment"]
        D2["Embedding + search index"]
        D3["Graph + relations"]
        D4["Dedup + retention + archive"]
    end

    subgraph Experience["Retrieval and Experience"]
        E1["Search / detail / timeline"]
        E2["Dashboard / team / health"]
        E3["Session handoff / agent recall"]
    end

    A1 --> B1
    A1 --> B2
    A2 --> B1
    A2 --> B2
    A3 --> B2
    A4 --> B1

    B1 --> B3
    B2 --> B3

    B3 --> C1
    B3 --> C2
    B3 --> C3
    B3 --> C4
    B3 --> C5

    C1 --> D1
    C1 --> D2
    C1 --> D3
    C1 --> D4
    C2 --> D1
    C2 --> D3
    C3 --> D2
    C4 --> D3
    C5 --> D4
    C5 --> E1

    D1 --> E1
    D2 --> E1
    D3 --> E2
    D4 --> E3
    C4 --> E3
CodeGraph Evidence Plane

CodeGraph is a separate evidence plane alongside memory, not a second copy of the source tree and not a replacement for the human knowledge graph. The local path is layered: Code State records hashes and snapshots, Lite provides bounded structural fallback facts, and the TypeScript Compiler API provides source-backed symbols and relations where it can prove them. Each fact carries its source and is refreshed by changed-file dependency closure. Agent-facing context is a small receipt with freshness and uncertainty, rather than a raw graph dump. Optional external CodeGraph or SCIP output is validated and normalized for one request only; it does not overwrite the local canonical index.

Access and Runtime Layer

This layer provides the entry points that agents and users actually talk to.

Main pieces:

  • src/server.ts

  • src/index.ts

  • src/cli/index.ts

  • src/cli/commands/serve.ts

  • src/cli/commands/serve-http.ts

Responsibilities:

  • register MCP tools

  • start stdio or HTTP transport

  • manage project switching

  • load config and dotenv state

  • expose the dashboard and HTTP APIs

Memory Core

This layer stores, indexes, and serves persistent memory.

Main pieces:

  • src/memory/observations.ts

  • src/store/orama-store.ts

  • src/memory/session.ts

  • src/memory/retention.ts

  • src/memory/graph.ts

  • src/memory/consolidation.ts

  • src/memory/long-term.ts

  • src/memory/long-term-store.ts

Responsibilities:

  • assign observation IDs

  • persist project-scoped memory

  • maintain the search index

  • manage session state

  • retention, archive, and deduplication

  • knowledge graph entities and relations

  • curate long-lived episodes, facts, and procedures with source evidence, qualification, approval, archival, and supersession

Persistence Contract

SQLite is the canonical local record for observations, sessions, mini-skills, knowledge, coordination, and CodeGraph metadata. Search indexes and in-memory structures are derived views and may be rebuilt; they must never decide that a failed database is an empty project.

All SQLite-backed stores share the same startup semantics:

  1. A missing SQLite runtime is reported as an explicit degraded backend.

  2. Cross-process SQLITE_BUSY contention is retried with bounded backoff.

  3. Persistent runtime failures are thrown and surfaced to the operator.

  4. Degraded business reads and writes fail clearly instead of returning empty data or a fake success.

  5. A connection that fails during schema/index initialization is closed before a retry, so a failed startup cannot retain a file lock.

WAL improves reader/writer overlap but still permits one writer per database file. Long maintenance work is therefore isolated and paged, while write transactions stay short. Multi-agent installations should prefer one local HTTP control plane as the database owner; stdio remains useful for a single agent or a deliberately isolated project store.

Intelligence and Quality Layer

This layer improves memory quality and retrieval quality.

Main pieces:

  • src/memory/formation/

  • src/search/intent-detector.ts

  • src/compact/engine.ts

  • src/llm/quality.ts

  • src/embedding/provider.ts

Responsibilities:

  • formation pipeline

  • fact extraction and evaluation

  • source-aware retrieval

  • compact formatting and token budgeting

  • optional embedding-backed semantic search

  • optional LLM-assisted quality improvements

Platform and Ecosystem Layer

This is the layer that makes Memorix more than a simple MCP memory server.

Main pieces:

  • src/hooks/

  • src/git/

  • src/workspace/

  • src/rules/

  • src/team/

  • src/skills/

  • src/dashboard/

Responsibilities:

  • IDE hook capture

  • Git Memory ingestion

  • workspace and rule sync across agents

  • orchestration coordination state

  • mini-skills and memory-driven workflows

  • dashboard and HTTP service APIs


2. Core Memory Layers

Observation Memory

Observation memory captures operational and architectural facts such as:

  • what-changed

  • problem-solution

  • decision

  • trade-off

  • gotcha

  • how-it-works

This is the main general-purpose memory layer.

Reasoning Memory

Reasoning memory stores the thinking behind non-trivial decisions:

  • why a choice was made

  • alternatives considered

  • constraints

  • expected outcomes

  • known risks

This layer is useful when a future agent asks:

  • why did we do this?

  • what trade-off did we accept?

Git Memory

Git Memory turns commits into structured memory with source provenance:

  • source='git'

  • commitHash

  • changed files

  • inferred observation type

  • extracted concepts

This creates an engineering truth layer that complements human- or agent-authored observations.

Curated Long-term Memory

Long-term memory holds a deliberately small set of records that remain useful after a project session ends:

  • episodic: a completed, reusable episode

  • semantic: a stable fact or principle

  • procedural: a repeatable workflow

It is separate from ordinary observations so the two jobs do not get confused:

  • an observation records what happened in context;

  • a long-term record says that the fact or procedure has earned durable reuse.

Each record is source-bound, auditable, and moves through candidate -> qualified -> approved -> archived/superseded. Candidates are never injected into an agent context. A record can be portable only when it is user-owned and based on explicit manual or user evidence; project, team, Git, session, code, and claim evidence never crosses that boundary.


3. Main Data Flows

The core operational model is not a single straight line. Memorix has multiple write paths that converge into shared memory substrates, then fan out again into indexing, quality, and retrieval surfaces.

flowchart TB
    W1["Manual store / MCP tools"]
    W2["Git commit / git-hook / ingest"]
    W3["IDE hook event"]
    W4["Session start / team activity"]

    W1 --> R["Runtime validation + project binding"]
    W2 --> R
    W3 --> R
    W4 --> R

    R --> S1["Observation persistence"]
    R --> S2["Reasoning persistence"]
    R --> S3["Git memory extraction"]
    R --> S4["Session + team state"]

    S1 --> P1["Formation / enrichment"]
    S1 --> P2["Embedding / BM25 index"]
    S1 --> P3["Graph relation update"]
    S1 --> P4["Dedup / retention"]
    S2 --> P1
    S2 --> P3
    S3 --> P2
    S4 --> P3

    P1 --> Q1["Search results"]
    P2 --> Q1
    P3 --> Q2["Dashboard / graph / team"]
    P4 --> Q3["Handoff / archive / cleanup"]
    S4 --> Q3
Explicit store flow
  • memorix_store / memorix_store_reasoning

  • runtime validation and project binding

  • persistence into observation/reasoning memory

  • async quality/indexing branches

  • retrieval through search/detail/timeline or dashboard surfaces

Git Memory flow
  • git commit

  • post-commit hook or manual memorix ingest commit --auto

  • git extractor + noise filter

  • persistence as Git Memory with provenance

  • indexing and retrieval through normal search surfaces

Hook capture flow
  • IDE hook event

  • normalize and significance detection

  • optional memory write

  • session-aware context update

Retrieval flow
  • memorix_search -> project-scoped search by default -> BM25 or hybrid retrieval -> source-aware ranking -> compact formatting

  • memorix_detail -> full observation lookup with project-aware refs for global hits

  • memorix_timeline -> chronological context around an anchor observation


4. Retrieval Model

Memorix does not treat all memory equally.

Default scope
  • memorix_search defaults to the current project

  • scope="global" searches across projects

  • global hits can be opened with project-aware refs in memorix_detail

Source-aware retrieval

Retrieval weights memory differently depending on intent:

  • "what changed" style queries boost Git Memory

  • "why" style queries boost reasoning and decision memory

  • "problem" style queries can boost both operational fixes and Git Memory

Progressive disclosure

Memorix retrieval is layered:

  • compact search results

  • timeline context

  • full detail only when explicitly requested

This keeps normal retrieval efficient while still allowing deep inspection.


5. Project Identity Model

Project identity is central to Memorix.

Main idea:

  • memory is project-scoped by default

  • project IDs come from Git identity

  • aliases and identity health are tracked explicitly

This prevents unrelated repositories, IDE install folders, or system directories from polluting the same memory namespace.

Useful runtime tools and surfaces:

  • memorix status

  • dashboard identity health page

  • global search with project-aware refs


6. Configuration Model

Memorix uses TOML as the primary user-facing configuration model:

  • global defaults in ~/.memorix/config.toml

  • project overrides in <git-root>/memorix.toml

Legacy YAML, .env, and JSON files remain compatibility inputs for existing users.

Resolution order:

Behavior settings and model lanes
  1. explicit CLI flags

  2. environment variables

  3. project <git-root>/memorix.toml

  4. global ~/.memorix/config.toml

  5. legacy compatibility files

  6. defaults

Secrets
  1. shell or host-provided environment variables

  2. project .env

  3. user ~/.memorix/.env

The primary lanes are [agent] for memcode, [memory.llm] for formation/summaries/LLM-rerank fallback, [rerank] for optional HTTP rerank against a compatible /rerank API, and [embedding] for semantic search. The dashboard and memorix status expose config provenance so the active value source is visible.


7. Runtime Modes

memorix serve

Starts the stdio MCP server.

Use this for:

  • Cursor

  • Claude Code

  • Codex

  • Windsurf

  • other stdio MCP clients

memorix background start

Starts the recommended long-lived HTTP service and dashboard in the background.

Use this when you want:

  • an HTTP MCP endpoint

  • one shared Memorix process for multiple agents

  • Team features

  • the browser dashboard

Companion commands:

  • memorix background status

  • memorix background logs

  • memorix background stop

memorix serve-http --port 3211

Starts the same HTTP MCP server and dashboard in the foreground.

Use this when you want:

  • foreground logs

  • manual supervision

  • a custom port

  • custom launch control

Main URLs:

  • MCP endpoint: http://localhost:3211/mcp

  • dashboard: http://localhost:3211

memorix dashboard

Standalone dashboard mode.

Useful for local inspection and debugging, but the main product mode is the dashboard embedded in the HTTP service.


8. Session and HTTP Coordination

The HTTP service is not just a transport wrapper. It is the coordination layer that keeps multiple agents, multiple projects, and multiple UX surfaces from drifting apart.

flowchart LR
    A1["Agent / IDE session"] --> B1["HTTP MCP initialize"]
    B1 --> B2["memorix_session_start(projectRoot)"]
    B2 --> C1["Project binding"]
    C1 --> C2["Session context"]
    C1 --> C3["Config provenance"]
    C1 --> C4["Team / task registry"]

    C2 --> D1["Recent Handoff"]
    C2 --> D2["Key Project Memories"]
    C2 --> D3["Recent Session History"]

    C3 --> E1["doctor / status"]
    C3 --> E2["dashboard config + health"]

    C4 --> F1["team status"]
    C4 --> F2["tasks / messages / locks"]
    C4 --> F3["dashboard team view"]

This is the layer that gives Memorix its cross-agent behavior:

  • explicit projectRoot binding for HTTP sessions

  • Git-backed project identity

  • shared team/task/message state

  • session handoff context that survives across clients and runs

  • dashboard and CLI surfaces reading the same underlying runtime state


9. Dashboard

The dashboard is no longer just an observation browser.

It provides an operational view for:

  • memory source breakdown

  • Git Memory visibility

  • config provenance

  • identity health

  • sessions

  • retention state

  • preview-first cleanup, consolidation, intelligent deduplication, and retention archival

  • read-only Coordination Status derived from the project-scoped SQLite TeamStore; the page is a projection, not a task execution surface

TeamStore is the real persistent coordination layer for agents, tasks, messages, locks, handoffs, and poll state. Dashboard coordination reads use that same SQLite state and return an explicit degraded/error status when it cannot be read; they must not substitute a normal-looking empty snapshot.

Dashboard maintenance is not a separate business-logic implementation. CLI, MCP, background jobs, and Dashboard routes share the same cleanup, consolidation, deduplication, and retention functions. Mutation routes issue a project-bound signed preview token and reject execution when the candidate set changed after preview.

This is part of Memorix's shift from a single MCP server to a broader local memory platform.


10. Design Goals

Memorix is designed around a few guiding ideas:

  • Local-first: memory should stay on the developer machine by default

  • Project-safe: default recall should respect project boundaries

  • Cross-agent: different tools should share one memory base

  • Layered truth: Git Memory, observation memory, and reasoning memory each serve different jobs

  • Quality over volume: retention, formation, compaction, and noise filtering matter as much as raw storage


512 files · 453 not served here

Advantages

  • Local-first: the memory stays in files or a database on your own machine (a rule-derived fact from the brain’s files, evidence: README.md)
  • Works with 14 MCP clients (a rule-derived fact from the brain’s files, evidence: README.md)
  • Open licence (Apache-2.0) (a rule-derived fact from the brain’s files)

Limitations

  • Needs an API key (ANTHROPIC_API_KEY, API_ROUTE_API_KEY, ATLASCLOUD_API_KEY) (a rule-derived fact from the brain’s files, evidence: README.md)
  • Needs a database (LanceDB, PostgreSQL, SQLite) (a rule-derived fact from the brain’s files, evidence: README.md)
  • Runs code automatically: review what it runs before you open it (a rule-derived fact from the brain’s files)
  • No ZIP download: install it from its source (a rule-derived fact from the brain’s files)

Security

Risk level: Low risk

This brain runs

Agent instructions that run or fetch something (23)

  • CLAUDE.md: CLI fallback: only after MCP is confirmed unavailable, run `memorix context --task "<current task>"` from the shell instead of skipping memory or hand-writing tool calls
  • plugins/claude/memorix/SKILL.md: Run `memorix context --task "<task>" --fallback --brief-json` only after MCP is unavailable, disabled, or not discoverable, and pass the user's real task text.
  • plugins/claude/memorix/skills/memorix-git-memory/SKILL.md: | Situation | Prefer | CLI fallback | |---|---|---| | Search what changed | `memorix_search` with a change-focused query | `memorix memory search --query "what changed <topic>"` | | Inspect a git-backed memory | `memorix_detail` | `memorix memory detail --id <id>` | | Ingest current co …[+257 chars]
  • plugins/claude/memorix/skills/memorix-memory/SKILL.md: Run `memorix context --task "<task>" --fallback --brief-json` from the shell only after MCP is unavailable, disabled, or not discoverable, and pass the user's real task text.
  • plugins/claude/memorix/skills/memorix-orchestrate/SKILL.md: | Situation | Prefer | CLI fallback | |---|---|---| | Run managed subagent execution | CLI | `memorix orchestrate --goal "<goal>" --agents claude:1,codex:1` | | Register coordination identity | `team_manage` action `join` | `memorix team join --agentType <agent>` | | Create or inspect …[+385 chars]
  • plugins/claude/memorix/skills/memorix-troubleshooting/SKILL.md: | Symptom | Check | CLI fallback | |---|---|---| | MCP tools missing | host MCP config and restart | `memorix setup --agent <agent>` | | Unsure project is bound | project status | `memorix status` and `git status` | | HTTP MCP stale or unbound | background health and explicit session bi …[+33 chars]
  • plugins/codebuddy/memorix/skills/memorix-git-memory/SKILL.md: | Situation | Prefer | CLI fallback | |---|---|---| | Search what changed | `memorix_search` with a change-focused query | `memorix memory search --query "what changed <topic>"` | | Inspect a git-backed memory | `memorix_detail` | `memorix memory detail --id <id>` | | Ingest current co …[+257 chars]
  • plugins/codebuddy/memorix/skills/memorix-memory/SKILL.md: Run `memorix context --task "<task>" --fallback --brief-json` from the shell only after MCP is unavailable, disabled, or not discoverable, and pass the user's real task text.
  • plugins/codebuddy/memorix/skills/memorix-orchestrate/SKILL.md: | Situation | Prefer | CLI fallback | |---|---|---| | Run managed subagent execution | CLI | `memorix orchestrate --goal "<goal>" --agents claude:1,codex:1` | | Register coordination identity | `team_manage` action `join` | `memorix team join --agentType <agent>` | | Create or inspect …[+385 chars]
  • plugins/codebuddy/memorix/skills/memorix-troubleshooting/SKILL.md: | Symptom | Check | CLI fallback | |---|---|---| | MCP tools missing | host MCP config and restart | `memorix setup --agent <agent>` | | Unsure project is bound | project status | `memorix status` and `git status` | | HTTP MCP stale or unbound | background health and explicit session bi …[+33 chars]
  • plugins/codex/memorix/skills/memorix-git-memory/SKILL.md: | Situation | Prefer | CLI fallback | |---|---|---| | Search what changed | `memorix_search` with a change-focused query | `memorix memory search --query "what changed <topic>"` | | Inspect a git-backed memory | `memorix_detail` | `memorix memory detail --id <id>` | | Ingest current co …[+257 chars]
  • plugins/codex/memorix/skills/memorix-memory/SKILL.md: Run `memorix context --task "<task>" --fallback --brief-json` only after MCP is unavailable, disabled, or not discoverable, and pass the user's real task text.
  • plugins/codex/memorix/skills/memorix-orchestrate/SKILL.md: | Situation | Prefer | CLI fallback | |---|---|---| | Run managed subagent execution | CLI | `memorix orchestrate --goal "<goal>" --agents claude:1,codex:1` | | Register coordination identity | `team_manage` action `join` | `memorix team join --agentType <agent>` | | Create or inspect …[+385 chars]
  • plugins/codex/memorix/skills/memorix-troubleshooting/SKILL.md: | Symptom | Check | CLI fallback | |---|---|---| | MCP tools missing | host MCP config and restart | `memorix setup --agent <agent>` | | Unsure project is bound | project status | `memorix status` and `git status` | | HTTP MCP stale or unbound | background health and explicit session bi …[+33 chars]
  • plugins/copilot/memorix/skills/memorix-git-memory/SKILL.md: | Situation | Prefer | CLI fallback | |---|---|---| | Search what changed | `memorix_search` with a change-focused query | `memorix memory search --query "what changed <topic>"` | | Inspect a git-backed memory | `memorix_detail` | `memorix memory detail --id <id>` | | Ingest current co …[+257 chars]
  • plugins/copilot/memorix/skills/memorix-memory/SKILL.md: Run `memorix context --task "<task>" --fallback --brief-json` only after MCP is unavailable, disabled, or not discoverable, and pass the user's real task text.
  • plugins/copilot/memorix/skills/memorix-orchestrate/SKILL.md: | Situation | Prefer | CLI fallback | |---|---|---| | Run managed subagent execution | CLI | `memorix orchestrate --goal "<goal>" --agents claude:1,codex:1` | | Register coordination identity | `team_manage` action `join` | `memorix team join --agentType <agent>` | | Create or inspect …[+385 chars]
  • plugins/copilot/memorix/skills/memorix-troubleshooting/SKILL.md: | Symptom | Check | CLI fallback | |---|---|---| | MCP tools missing | host MCP config and restart | `memorix setup --agent <agent>` | | Unsure project is bound | project status | `memorix status` and `git status` | | HTTP MCP stale or unbound | background health and explicit session bi …[+33 chars]
  • plugins/cursor/memorix/skills/memorix-git-memory/SKILL.md: | Situation | Prefer | CLI fallback | |---|---|---| | Search what changed | `memorix_search` with a change-focused query | `memorix memory search --query "what changed <topic>"` | | Inspect a git-backed memory | `memorix_detail` | `memorix memory detail --id <id>` | | Ingest current co …[+257 chars]
  • plugins/cursor/memorix/skills/memorix-memory/SKILL.md: Run `memorix context --task "<task>" --fallback --brief-json` only after MCP is unavailable, disabled, or not discoverable, and pass the user's real task text.
  • plugins/cursor/memorix/skills/memorix-orchestrate/SKILL.md: | Situation | Prefer | CLI fallback | |---|---|---| | Run managed subagent execution | CLI | `memorix orchestrate --goal "<goal>" --agents claude:1,codex:1` | | Register coordination identity | `team_manage` action `join` | `memorix team join --agentType <agent>` | | Create or inspect …[+385 chars]
  • plugins/cursor/memorix/skills/memorix-troubleshooting/SKILL.md: | Symptom | Check | CLI fallback | |---|---|---| | MCP tools missing | host MCP config and restart | `memorix setup --agent <agent>` | | Unsure project is bound | project status | `memorix status` and `git status` | | HTTP MCP stale or unbound | background health and explicit session bi …[+33 chars]
  • plugins/gemini/memorix/GEMINI.md: Run `memorix context --task "<task>" --fallback --brief-json` only after MCP is unavailable, disabled, or not discoverable, and pass the user's real task text.

MCP servers (7)

  • README.md (memorix): memorix serve
  • plugins/claude/memorix/.mcp.json (memorix): memorix serve --mode lite
  • plugins/codebuddy/memorix/.mcp.json (memorix): memorix serve --mode lite
  • plugins/codex/memorix/.mcp.json (memorix): memorix serve --mode lite
  • plugins/copilot/memorix/.mcp.json (memorix): memorix serve --mode lite
  • plugins/gemini/memorix/gemini-extension.json (memorix): memorix serve --mode lite
  • plugins/openclaw/memorix/.mcp.json (memorix): memorix serve --mode lite

Hooks (20)

  • plugins/claude/memorix/hooks/hooks.json (SessionStart): memorix hook
  • plugins/claude/memorix/hooks/hooks.json (PostToolUse): memorix hook
  • plugins/claude/memorix/hooks/hooks.json (UserPromptSubmit): memorix hook
  • plugins/claude/memorix/hooks/hooks.json (PreCompact): memorix hook
  • plugins/claude/memorix/hooks/hooks.json (Stop): memorix hook
  • plugins/codebuddy/memorix/hooks/hooks.json (SessionStart): memorix hook --agent codebuddy
  • plugins/codebuddy/memorix/hooks/hooks.json (UserPromptSubmit): memorix hook --agent codebuddy
  • plugins/codebuddy/memorix/hooks/hooks.json (PostToolUse): memorix hook --agent codebuddy
  • plugins/codebuddy/memorix/hooks/hooks.json (PreCompact): memorix hook --agent codebuddy
  • plugins/codebuddy/memorix/hooks/hooks.json (Stop): memorix hook --agent codebuddy
  • plugins/codex/memorix/hooks/hooks.json (SessionStart): memorix hook --agent codex
  • plugins/codex/memorix/hooks/hooks.json (PostToolUse): memorix hook --agent codex
  • plugins/codex/memorix/hooks/hooks.json (UserPromptSubmit): memorix hook --agent codex
  • plugins/codex/memorix/hooks/hooks.json (PreCompact): memorix hook --agent codex
  • plugins/codex/memorix/hooks/hooks.json (Stop): memorix hook --agent codex
  • plugins/copilot/memorix/hooks/hooks.json (sessionStart): memorix hook --agent copilot
  • plugins/copilot/memorix/hooks/hooks.json (sessionEnd): memorix hook --agent copilot
  • plugins/copilot/memorix/hooks/hooks.json (userPromptSubmitted): memorix hook --agent copilot
  • plugins/copilot/memorix/hooks/hooks.json (postToolUse): memorix hook --agent copilot
  • plugins/copilot/memorix/hooks/hooks.json (preCompact): memorix hook --agent copilot

Binaries (5)

  • packages/memcode/examples/extensions/doom-overlay/doom/build/doom.wasm: ships native binaries
  • packages/tui/native/darwin/prebuilds/darwin-arm64/darwin-modifiers.node: ships native binaries
  • packages/tui/native/darwin/prebuilds/darwin-x64/darwin-modifiers.node: ships native binaries
  • packages/tui/native/win32/prebuilds/win32-arm64/win32-console-mode.node: ships native binaries
  • packages/tui/native/win32/prebuilds/win32-x64/win32-console-mode.node: ships native binaries
  • Low risk: scripts-present (scripts/benchmark-retrieval.mjs)
  • Low risk: scripts-present (scripts/large-store-gate.mjs)

Attribution and licence

First committed by
GitHub avatar of AVIDS2AVIDS2
Declared authors
  • AVIDS2 (declared in package.json)
Publisher
Le_Ho (Community)
Source
AVIDS2/memorix · commit 6745280
Licence
Apache License 2.0 (files served here)
  • ATTRIBUTION.md (written by AutoGineer)
Synced
Contributors
AVIDS2, noirgif, Tom-Ma-Ming, octo-patch, DennyHo0917

AutoGineer is not affiliated with or endorsed by AVIDS2.

Install from source

453 of its files are not served here, so there is no ZIP. AVIDS2/memorix at 6745280