MemoryRouter
All posts

Persistent Memory for Zed: One Context Server, Every Thread

John Rood··5 min read

Tuesday's refactor got settled in the Agent Panel. The upload worker stays single-writer because the downstream store rejects concurrent writes, and you walked Zed through the constraint until it held. Good thread. Closed.

Wednesday starts a fresh thread, and the first question you get is one you answered yesterday. Zed is fast enough that you open new threads constantly, which is exactly why last week's reasoning keeps falling out of reach. The threads are clean by design, and that is also the cost: every one of them starts from zero.

One entry in settings.json

Zed calls MCP servers context servers, and remote ones connect straight from settings. No package to install, no local process to run:

{
  "context_servers": {
    "memoryrouter": {
      "url": "https://mcp.memoryrouter.ai/mcp"
    }
  }
}

There is no Authorization header in that entry, so Zed runs the standard MCP OAuth flow the first time you use the server. You sign in through the browser and choose which vault the connection is bound to while you authorize it. Nothing secret lands in a settings file, and the connection can be revoked from your MemoryRouter dashboard later.

Open Settings > AI > MCP Servers and the dot next to memoryrouter should go green. Green means the server is connected, not that recall has been proven, so the test below matters more than the dot. Once it is on, the memory tools show up in the Agent Panel tool list: search_memories for recall, store_memory for durable saves, and date_search_memories for questions shaped like "what did we settle last month." The MCP reference documents the full tool set and the four OAuth scopes behind it, and the Zed page walks through the same setup end to end.

Zed decides when the tools get called

Memory here is model-directed. Zed reaches for search_memories the same way it decides to read a file: sometimes on its own, sometimes only when asked. Zed's own documentation notes that mentioning a server by name helps the model pick its tools. Put "check memoryrouter for how we handle retries" in the prompt and the odds move your way.

Approval stays in the loop, too. Tool calls run through Zed's normal permission settings, so you watch the store_memory call and its result land in the conversation. If a reply says it remembered something but no store call ran, nothing was saved. Watch the tool result, not the promise.

If you would rather not leave it to model judgment, Zed agent profiles can turn the built-in tools off and leave only the context server's tools on. That makes the memory tools the default instead of an option the model weighs each turn.

Three agent paths, three configuration boundaries

Everything above configures the Zed Agent, which is what most people mean when they say "Zed." But the editor runs two other kinds of agents, and each one reads its configuration from somewhere else:

  • External agents you launch through Zed, such as Claude Code or Codex over ACP, receive Zed's configured context servers and can also read their own native MCP config. Their model and auth settings stay their own.
  • Terminal threads run native CLIs and TUIs that read their own MCP configuration. The entry above does not reach them.

If your work moves between the Agent Panel and a CLI in the built-in terminal, connect the tool you actually use from that tool's own guide. Zed's MCP documentation lays out these paths in its agent support table, and the mismatch is worth knowing before you blame the vault.

One adjacent distinction: the coding tools guide also documents an OpenAI-compatible provider path for the built-in agent. That lever routes the agent's model requests. The context server adds tools the agent can call. Pick the one you can verify.

Prove it with a disposable decision

Run this with a made-up fact before real project history goes near the vault.

  1. In a connected thread: "Store this in MemoryRouter: the demo exporter uses a 40-second flush window because the CI runner throttles bursts." Watch for the store call and its result.
  2. Open a fresh thread. Attach nothing, paste nothing. Ask: "Check memory: why does the demo exporter use a 40-second flush window?" A working path shows search_memories running and both pieces coming back, the window and the reason.
  3. The control: ask the same question on a profile without the server enabled and it comes back empty. That gap is what you just closed.

Once it passes, the same vault follows you. A fact saved from Zed is retrievable from ChatGPT, Claude, Cursor, or Claude Code when each is connected to that vault, and the other direction works the same way.

What this does not do

  • It does not import old threads or your Zed history. The connection changes what future conversations can reach; bringing history in is a separate workflow.
  • It does not replace project rules, previous-thread references, or code search. If attaching the last thread already covers you, that native move costs nothing.
  • It is not local. Editing stays on your machine; the memories live in your MemoryRouter vault, outside the editor.
  • It is not a scoping mechanism. One connection is bound to one vault and the tools accept no project or vault parameter, so if two projects must never share context, that is two vaults and two connections.

The point of keeping memory in a vault instead of a settings file is that the editor stops being the boundary. Zed stays the fast surface you chose, and the reasoning stops resetting when a thread ends.

Create your MemoryRouter account, add the entry to settings.json, and run the fresh-thread test before real decisions go in.

All posts