AnchorDB MCP server

AnchorDB

Code memory for AI coding agents. AnchorDB is an MCP server that stores notes attached to specific code — a file, a line range, a symbol — and keeps them attached as that code moves. The context an agent builds up in one session is still there in the next one.

Point Claude Code, Cursor, or any Model Context Protocol host at it, and an agent can read why a workaround exists before editing it, and leave notes for whoever comes next. Everything stays local: one SQLite file, your git repositories, no network calls, no account.

curl -fsSL https://raw.githubusercontent.com/jolovicdev/anchor-db/master/install.sh | sh
claude mcp add anchordb -- anchordb-mcp --db ~/.anchordb/anchor.db

No account, no API key, and nothing to run in the background. git is the only requirement; prebuilt binaries cover Linux, macOS, and Windows, and there is a container image and a Go install path too.

Three ways in, over the same data:

Why

Chat history is a bad place to keep what you learn about a codebase. It scrolls away, it is not attached to anything, and the next session starts blank.

A comment in the source is better, but you cannot leave one everywhere, and much of what matters does not belong in the file: a reproduction for a bug you did not fix, why the obvious refactor is wrong, what broke the last time someone touched this retry loop, where you stopped.

AnchorDB keeps those notes beside the code instead of inside it, and follows the code when it moves. A note pinned to a function is still on that function after you rename it, reorder the file, or move it to another package.

Use cases

• Coding agents that should read context before editing a file or symbol
• Agent handoffs, where one run leaves precise notes for the next
• Long debugging sessions, keeping repros and findings attached to the code
• Review notes on risky paths — billing, auth, migrations, retry logic
• Any codebase where the reason for a decision outlives the person who made it

How It Works

AnchorDB stores anchors.

Each anchor contains:

• repo metadata
• a note body and kind
• a file path
• a line and column range
• selected text plus surrounding context
• an optional symbol path

When files change, AnchorDB re-resolves anchors using the saved span, text context, and symbol information. Tree-sitter improves symbol extraction and relocation, but the system still works without it.

Resolution tries strategies from most to least certain and stops at the first that holds up:

taken against, so git diff says exactly where those lines went. This is deterministic where text matching can only guess, and it is the difference between finding the right copy of a duplicated block and finding the first one. The mapping is always verified against the stored text before it is applied, so it degrades safely rather than mis-anchoring.

1. Exact span — the recorded lines still hold the recorded text.
2. Git line mapping — each anchor records the commit its line numbers were

survived.

1. Symbol match — the same symbol path, scored on how much of its body

ranked by surrounding context.

1. Text and context match — the recorded text found elsewhere in the file,

An anchor that none of these can place is marked stale and keeps its last known position. Because the diff is available, a stale anchor can say whether its code was rewritten in place or deleted outright. Resolution is per-path and failures are isolated, so one unresolvable file never stops the rest of a repo from syncing.

Anchors written before this existed have no recorded base commit; they simply skip the git step and fall back to text matching.

Triage

Shortened. The full README is on GitHub.