Reference MCP

When you run Claude Code for one project and Codex CLI for another, neither tool knows what the other decided. Reference solves that by acting as a shared memory layer: an MCP server you register in each tool that reads session transcripts and memory files from your local filesystem and makes them searchable by any agent that queries it. The workflow is install-once, configure-once — add it to each tool’s MCP config via uvx or a git clone, and agents can call it whenever they need to recall what a sibling tool resolved in a past session.

The differentiating move here is cross-tool recall without a cloud backend. All reads happen locally, offline, against files already on your machine. There is no sync service, no account, no data leaving your system. For developers who have hard requirements around code privacy or work in air-gapped environments, that architecture is not a compromise — it is the feature.

Where Reference fits cleanly: solo developers running two or three AI coding agents who want shared context without standing up infrastructure. Where it breaks: the search is over raw transcripts and markdown files, not a structured knowledge graph. As session volume grows, recall quality depends on how consistently your tools write session files and how well the agent interprets unstructured history. Teams who need memory shared across machines, or who want to query decisions with precision — ‘what did we decide about the auth layer in sprint three’ — will find transcript scanning insufficient and reach for a purpose-built knowledge store.

Reference is MIT-licensed and self-hosted by definition — there is no hosted version. Installation uses standard Python tooling (uvx or pip from the repo), and the example config file covers the MCP registration pattern for supported tools.