NEW Local MCP server for Claude Code, Cursor and more

Agent memory with a recall button.

Every memory knows its sources. Recall a bad source, and everything learned from it goes too.

For AI apps (MCP)
claude mcp add cheesedb -- cheesedb mcp alice
For Go programs
go get github.com/govinargo-labs/cheesedb

Preview v0.2.0. Embedded, Go standard library only, Apache-2.0.

Give your AI app a memory it can recall.

Claude Code, Cursor and any other MCP app can store what they learn together with the sources behind it, and later remove a bad source and everything built on it. No code to write and no server to run: the app starts CheeseDB itself.

Set it up in two commands

go install github.com/govinargo-labs/cheesedb/cmd/cheesedb@latest
cheesedb agent create alice
claude mcp add cheesedb -- cheesedb mcp alice

Other apps (Cursor, Claude Desktop): add {"mcpServers":{"cheesedb":{"command":"cheesedb","args":["mcp","alice"]}}} to the app’s MCP settings. Then tell the model to keep its long-term memory in CheeseDB.

Five tools the model can call

  • add_lotRegister a new outside source: a message, a web page, a tool result.
  • rememberStore something learned, with the ids it came from.
  • recallRemove a source and everything built on it, and erase the text.
  • getRead one lot or memory by id.
  • list_memoriesList what is still alive, newest first.

No tool takes an agent

The agent is fixed when the server starts, so a prompt-injected model cannot reach another agent’s memory through a parameter.

Recall really erases

The text of a recalled source and of what depended on it is removed from disk, and recalled text is never shown back to the model.

Local only

It runs on your machine over standard input and output. No network port, no account, no dependencies.

Know the limits. The model declares the sources and legs itself, so a recall is only as complete as what it wrote. A model that can also run shell commands can skip the tools and read every agent’s files. Read the MCP guide and the threat model.

Press the button.

An agent learned from three sources. The weather tool turns out to be wrong. Pick a source, press Recall, then flip the rule to compare.

What the agent knows

or and A: user saidI live in Pune B: web pagelives in Pune C: weather toolPune: rain M1user lives in Pune M2Pune is rainy M3carry an umbrella

Tap a source to select it.

Rule

Reason

What is in the agent’s files

    The structure line (sources and legs) is never erased, so the history and the hash chain stay intact.

    
              

    Deleting the bad source isn’t enough.

    An agent builds memory from sources it can’t fully trust. When one turns out to be bad, everything the agent learned from it is still in memory, and the agent keeps acting on it.

    Wrong

    A tool returned bad data, and three memories were built on it.

    Malicious

    A web page planted false facts or instructions: memory poisoning and prompt injection.

    Private

    A user asked for their data to be deleted, including what the agent concluded from it.

    Every record has three parts.

    Erase has to remove text without losing history, so each record is split in a way that keeps the history.

    Header
    The record’s id and a hash that seals it to the record before it. Never erased, so the chain stays verifiable.
    Structure
    What kind of record it is and which sources it depends on. Never erased, so recall still works after an erase.
    Content
    The text itself, with a random salt. The only part erase removes.
    CheeseDB internals in three layers. Host: your Go program calls the library directly, or an MCP app talks to cheesedb mcp, which uses the library. cheesedb.Open(dir) opens the store, then OpenAgent(token) returns an agent handle with AddLot, Remember, Recall, Get, Active, Compact and Verify. In memory, rebuilt by replay: the family tree, leg counters and an offset table. On disk: a LOCK file, one folder per agent with agent.key, sealed segment files with seal files, and one active segment. Below, one record split into header, structure and content, linked to its neighbours by the hash chain, with Verify checking the whole chain.
    Select the picture to open it full size. At the top, a Go program calls the library directly, or an MCP app reaches it through cheesedb mcp. In memory, the engine keeps the family tree, leg counters and an offset table, all rebuilt from the log when an agent is opened. On disk, each agent is a folder of append-only segments. In the picture, source C has been recalled, so M2 and M3 are dead and M1 is alive.

    A few lines of Go.

    This is the same story as the demo above.

    s, err := cheesedb.Open("/data/cheesedb")   // a folder you choose, created 0700
    tok, err := s.CreateAgent("alice")          // Alice's token, shown once: keep it safe
    alice, err := s.OpenAgent(tok)              // the only way to reach Alice's data
    defer alice.Close()
    
    a, _ := alice.AddLot("user_message", []byte("I live in Pune"))
    b, _ := alice.AddLot("web_page", []byte("profile: lives in Pune"))
    c, _ := alice.AddLot("weather_tool", []byte("Pune: rain"))
    
    m1, _ := alice.Remember([]byte("user lives in Pune"), cheesedb.Leg{a}, cheesedb.Leg{b}) // from A, or from B
    m2, _ := alice.Remember([]byte("Pune is rainy"), cheesedb.Leg{c})
    m3, _ := alice.Remember([]byte("carry an umbrella"), cheesedb.Leg{m1, m2})             // needs M1 and M2
    
    removed, _ := alice.Recall(c, cheesedb.Fair, cheesedb.Untrusted) // the weather tool was wrong
    // removed == [m2, m3]; m1 survives because it does not depend on C

    Install the command-line tool with go install github.com/govinargo-labs/cheesedb/cmd/cheesedb@latest. It has one command per feature, including cheesedb find, which searches the raw bytes of the files to prove erased text is gone. Needs Go 1.26.5 or newer. Developed on macOS and tested on Linux in CI. Windows isn’t supported yet.

    Faster at recall and reads. Much slower to start.

    The same data on all four engines (including Neo4j, a graph database), with every write flushed to the physical disk before it is acknowledged.

    Recall that removes 10,000 memories

    CheeseDB5.5 ms
    SQLite235 ms
    PostgreSQL1.82 s
    Neo4j67 ms

    Log scale.

    Read one memory by id

    CheeseDB1.6 µs
    SQLite7.0 µs
    PostgreSQL44 µs
    Neo4j179 µs

    Log scale.

    1M memories per agentCheeseDBSQLitePostgreSQLNeo4j
    Recall that removes 10,000 memories5.5 ms235 ms1.82 s67 ms
    Recall that removes 20 memories4.8 ms7.1 ms10.5 ms6.8 ms
    Read one memory by id1.6 µs7.0 µs44 µs179 µs
    Durable write (one memory)4.7 ms5.3 ms6.6 ms6.3 ms
    Startup, ready for the first query667 ms0.1 ms2.7 ms1.0 ms¹
    Disk per memory314 B249 B546 B496 B
    RAM per memory while open205 Bpage cache onlyshared buffers onlyJVM heap and page cache

    Median of 3 runs on an Apple M1 Max (macOS, internal SSD), SQLite 3.53, PostgreSQL 17 and Neo4j Community 2026.10. PostgreSQL and Neo4j ran over TCP on localhost. Writes are close because the disk flush dominates for every engine. SQLite is smaller on disk and starts far faster. ¹ A new connection to a server that is already running; booting the Neo4j server took 6.5 to 8.2 s. The Neo4j model and queries are ours, and an expert may do better. Method and caveats are in BENCHMARKS.md.

    When to use it, and when not to.

    Use CheeseDB when

    • Your agents learn from sources you can’t fully trust.
    • You need to remove a source and everything declared to depend on it, however deep the chain goes.
    • Erased text must really be gone from the files.
    • You want each agent isolated by design, not by a filter in your code.
    • You want to give Claude Code, Cursor or another MCP app a memory it can recall, with no code.
    • You want an embedded Go library with no server and no dependencies.

    Use something else when

    • You need queries or search. CheeseDB looks up by id only, so keep search in your vector store and check each result against CheeseDB.
    • Startup time matters with very long histories: about 0.7 s at 1M memories. Snapshots are planned.
    • An agent’s memory graph won’t fit in RAM: about 205 bytes per memory.
    • You need production guarantees today. This is a preview.

    A real run.

    The same story three ways, with a real LLM: a plain memory list, CheeseDB with Untrusted, and CheeseDB with Erase.

    Output of the cheesedb demo command. An agent learns from three sources, then the weather tool is removed three ways. A table compares whether the model still uses the bad data and whether the bad text is still in the files.
    With a plain list, the model still answers from the bad forecast. With Untrusted, it stops using it, but the text stays in the files. With Erase, the text is gone from the files too.

    Read this before you rely on it.

    Preview v0.2.0: not independently security reviewed.

    • The API and on-disk format may change before v1.0.
    • Tamper-evident, not tamper-proof. Anyone who can write the files can rebuild the hash chain. Keep the head fingerprint that Verify() returns somewhere else and compare it later.
    • Isolation stops mistakes and prompt injection, not the host program. Whoever holds the store or the folder can read every agent’s files.
    • Over MCP the model is not trusted, but it is powerful. It declares the sources and legs itself, and can recall or erase anything in its agent. A model that can run shell commands can bypass the tools and read every agent’s files.
    • Legs are declared by the caller. If a memory was really learned from a source but no leg says so, recalling that source won’t remove it.
    • Only Erase removes text from disk. Untrusted hides memories until you run Compact(). Backups and copies keep their data.
    • Damage near the end of an active log is cut off and reported in Report.DroppedBytes, so check it after opening.

    The full list is in the README and the threat model.

    Why cheese?

    Lot 4821 milk from farm 7

    “Lot” and “recall” are food-safety words. A cheese maker records which lots of milk went into which wheels, so when one lot turns out to be contaminated, they recall exactly the cheese made from it.

    CheeseDB does the same for what an agent remembers. The name also nods to the Swiss cheese model of safety: stack several layers of protection, and harm only happens when the holes in every layer line up.