EchoVault Memory

io.github.go-portsPublished by GitHub account go-portsv0.3.3Updated Oct 24, 2026

Local-first memory for coding agents; stores decisions, bugs, and context across sessions.

The publisher's own server: Memory.fit

VerifiedSTDIODesktop onlyKnowledge & MemoryDeveloper Tools

Overview

AI-generated overview

A local-first memory server for coding agents that saves, searches and reloads decisions, bugs and context across sessions, stored as Markdown on your machine.

What you can do
Save memories with titles, rationale, impact, tags and categories, plus structured detail templates or detail files, and delete them by ID or prefix later on. Search memories with hybrid keyword and optional semantic vector search, and fetch full details for a result. Load prior context at session start, list memories for the current project and list session files. Keep one shared vault across Claude Code, Cursor, Codex and OpenCode, and manage the memory home and embedding configuration from the command line.
When to use it
Worth adding when you want a coding agent to carry decisions, bug history and project context from one session to the next without a cloud service. Useful if you already work across several agents and want them to share one memory vault you can browse as Markdown.
Requirements
Runs as a local process over stdio; the Go build is a single static binary, and building from source needs a C compiler because it links SQLite libraries. Initialize a vault and install the agent config first. The MEMORY_HOME environment variable sets the storage directory and should point at persistent storage. Semantic search optionally needs Ollama locally or an OpenAI or OpenRouter API key in the config file.
Before you install
The server writes memory files and a SQLite index to disk, and agents are instructed to save and retrieve automatically, so project details may be persisted without prompting; review or delete stored memories as needed. Secret redaction is pattern-based and may miss credentials, so avoid saving sensitive material. Configuring OpenAI or OpenRouter sends embedding requests to those servers; use Ollama for fully local operation.

Installation

In SourceWeft

  1. Open EchoVault Memory in the dashboard and add it to a workspace.
  2. Enable the server for the chats that should use its tools.

Desktop only via STDIO. STDIO servers start a local process, so they need the SourceWeft desktop host.

Other MCP clients

Follow the launch instructions in the repository.

README

[EchoVault]

EchoVault — Go

Local memory for coding agents. Your agent remembers decisions, bugs, and context across sessions — no cloud, no API keys, no cost.

Install · Features · How it works · Commands


This is the Go port of EchoVault. It is a single static binary with no Python runtime dependency. The vault format and MCP interface are fully compatible with the Python version — you can switch between them without losing any memories.

Features

Works with 4 agents — Claude Code, Cursor, Codex, OpenCode. One command sets up MCP config for your agent.

MCP native — Runs as an MCP server exposing memory_save, memory_search, and memory_context as tools. Agents call them directly — no shell hooks needed.

Local-first — Everything stays on your machine. Memories are stored as Markdown in ~/.memory/vault/, readable in Obsidian or any editor.

Zero idle cost — No background processes, no daemon, no RAM overhead. The MCP server only runs when the agent starts it.

Hybrid search — FTS5 keyword search works out of the box. Add Ollama or OpenAI for semantic vector search.

Secret redaction — 3-layer redaction strips API keys, passwords, and credentials before anything hits disk. Supports explicit <redacted> tags, pattern detection, and custom .memoryignore rules.

Cross-agent — Memories saved by Claude Code are searchable in Cursor, Codex, and OpenCode. One vault, many agents.

Obsidian-compatible — Session files are valid Markdown with YAML frontmatter. Point Obsidian at ~/.memory/vault/ and browse your agent's memory visually.

Install

Pre-built binary

Download the latest release for your platform from the releases page and place the binary somewhere on your $PATH.

Build from source

bash
git clone https://github.com/go-ports/echovault.gitcd echovaultmake build          # produces ./bin/memorysudo cp bin/memory /usr/local/bin/

CGO required. The binary links against go-sqlite3 and sqlite-vec, so a C compiler (gcc/clang) must be present. On macOS: xcode-select --install. On Debian/Ubuntu: apt install build-essential.

First run

bash
memory initmemory setup claude-code   # or: cursor, codex, opencode

That's it. memory setup installs the MCP server config automatically.

By default the config is installed globally. To install for a specific project:

bash
cd ~/my-projectmemory setup claude-code --project   # writes .mcp.json in project rootmemory setup opencode --project      # writes opencode.json in project rootmemory setup codex --project         # writes .codex/config.toml + AGENTS.md

Configure embeddings (optional)

Embeddings enable semantic search. Without them, you still get fast keyword search via FTS5.

Generate a starter config:

bash
memory config init

This creates ~/.memory/config.yaml with sensible defaults:

yaml
embedding:  provider: ollama              # ollama | openai | openrouter  model: nomic-embed-text
context:  semantic: auto                # auto | always | never  topup_recent: true

What each section does:

  • embedding — How memories get turned into vectors for semantic search. ollama runs locally; openai and openrouter call cloud APIs. nomic-embed-text is a good local model for Ollama.
  • context — Controls how memories are retrieved at session start. auto uses vector search when embeddings are available, falls back to keywords. topup_recent also includes recent memories so the agent has fresh context.

For cloud providers, add api_key under the provider section. API keys are redacted in memory config output.

Configure memory location

By default, EchoVault stores data in ~/.memory.

You can change that in two ways:

  • MEMORY_HOME=/path/to/memory (highest priority, per-shell/per-process)
  • memory config set-home /path/to/memory (persistent default)

Useful commands:

bash
memory config set-home /path/to/memorymemory config clear-homememory config

memory config shows both memory_home and memory_home_source (env, config, or default).

The --memory-home global flag overrides everything for a single invocation:

bash
memory --memory-home /tmp/test-vault search "authentication"

Usage

Once set up, your agent uses memory via MCP tools:

  • Session start — agent calls memory_context to load prior decisions and context
  • During work — agent calls memory_search to find relevant memories
  • Session end — agent calls memory_save to persist decisions, bugs, and learnings

The MCP tool descriptions instruct agents to save and retrieve automatically. No manual prompting needed in most cases.

You can also use the CLI directly:

bash
memory save --title "Switched to JWT auth" \  --what "Replaced session cookies with JWT" \  --why "Needed stateless auth for API" \  --impact "All endpoints now require Bearer token" \  --tags "auth,jwt" --category "decision" \  --details "Context:Options considered:- Keep session cookies- Move to JWTDecision:Tradeoffs:Follow-up:"
memory search "authentication"memory details <id>memory context --project

For long details, use --details-file notes.md. To scaffold structured details automatically, use --details-template.

How it works

~/.memory/├── vault/                    # Obsidian-compatible Markdown│   └── my-project/│       └── 2026-02-01-session.md├── index.db                  # SQLite: FTS5 + sqlite-vec└── config.yaml               # Embedding provider config
  • Markdown vault — one file per session per project, with YAML frontmatter
  • SQLite index — FTS5 for keywords, sqlite-vec for semantic vectors
  • Compact pointers — search returns ~50-token summaries; full details fetched on demand
  • 3-layer redaction — explicit tags, pattern matching, and .memoryignore rules

Supported agents

AgentSetup commandWhat gets installed
Claude Codememory setup claude-codeMCP server in .mcp.json (project) or ~/.claude.json (global)
Cursormemory setup cursorMCP server in .cursor/mcp.json
Codexmemory setup codexMCP server in .codex/config.toml + AGENTS.md fallback
OpenCodememory setup opencodeMCP server in opencode.json (project) or ~/.config/opencode/opencode.json (global)

All agents share the same memory vault at your effective memory_home path (default ~/.memory/). A memory saved by Claude Code is searchable from Cursor, Codex, or OpenCode.

Commands

CommandDescription
memory initCreate vault at effective memory home
memory setup <agent>Install MCP server config for an agent
memory uninstall <agent>Remove MCP server config for an agent
memory save ...Save a memory (--details-file and --details-template supported)
memory search "query"Hybrid FTS + semantic search
memory details <id>Full details for a memory
memory delete <id>Delete a memory by ID or prefix
memory context --projectList memories for current project
memory sessionsList session files
memory configShow effective config
memory config initGenerate a starter config.yaml
memory config set-home <path>Persist default memory location
memory config clear-homeRemove persisted memory location
memory reindexRebuild vectors after changing provider
memory mcpStart the MCP server (stdio transport)

Global flags

FlagDescription
--memory-home <path>Override memory home for this invocation
--helpShow help for any command

Uninstall

bash
memory uninstall claude-code   # or: cursor, codex, opencoderm /usr/local/bin/memory

To also remove all stored memories: rm -rf ~/.memory/

Privacy

Everything stays local by default. If you configure OpenAI or OpenRouter for embeddings, those API calls go to their servers. Use Ollama for fully local operation.

License

MIT — see LICENSE.

Source: README.md at commit cc0802b

Tools

0
SourceWeft has not started this package in its sandbox yet, so its tools are not known.

Version history

1
  1. v0.3.3LatestSep 16, 2026

Score

50% of the applicable checks met

How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.

  • Reached in the last 30 days25 pts

    Keep the endpoint answering the MCP handshake; SourceWeft probes it every 30 days.

  • Auth declared10 pts

    Declare the credential headers in the registry entry, or keep the endpoint answering the probe so its auth can be classified.

  • Tools listed15 pts

    Answer tools/list without a credential, or ship a package that starts in a sandbox without one.

  • DescriptionRequired15 pts
  • Logo10 pts
  • Documentation15 pts
  • License10 pts

Other Memory integrations