How to give Claude persistent memory across sessions

Claude has no memory between conversations. The fix is to keep the memory outside the conversation: put your context in a store Claude can reach over MCP, connect once, and every new session reads it before it answers you. Writes go back to the same place, so what today’s session learns is there tomorrow.

That’s the whole idea. The rest of this is how to actually do it.

Why the built-in options run out

Claude’s own memory feature keeps things it notices across your chats. It’s convenient and it’s fine for preferences. But it lives inside one vendor’s product, you can’t open it and read it as a file, and it doesn’t come with you to Claude Code, Cursor, or the next tool you try in six months.

ChatGPT’s memory has the same shape and the same ceiling, which is why a portable alternative is worth setting up once rather than per vendor.

The other common approach is a context doc you paste in. That works right up until it doesn’t — the doc drifts out of date, it lives on one laptop, and you’re the one doing the copying every time.

A context layer is the version that holds. One store, structured, plain markdown, reachable by any MCP client. You curate it instead of a model scraping it. What’s worth keeping for your AI covers what belongs in one; this post is about wiring it up.

Connect the layer

vtriv’s MCP endpoint is https://mcp.vtriv.com/mcp. It speaks Streamable HTTP with OAuth 2.1, so the client discovers auth on its own and opens a browser sign-in — no API keys to paste into a config file.

Claude Code:

claude mcp add --transport http vtriv https://mcp.vtriv.com/mcp

Claude Desktop or claude.ai: Settings → Connectors → Add custom connector, then that URL. Cursor: Settings → MCP → Add server, type streamableHttp, same URL. Codex CLI: codex mcp add vtriv --url https://mcp.vtriv.com/mcp.

One connection covers everything you have — profile, skills, knowledge, and every project. You don’t wire up a server per repo.

Write the thing Claude should always know

Start with your profile. It’s a single markdown document that stays in scope for every session, which makes it the highest-leverage thing in the layer. Ask Claude to write it:

Save a profile for me: I’m a backend engineer working mostly in Go and Postgres. I prefer standard library over frameworks, table-driven tests, and short commit messages in imperative mood. I don’t want code comments explaining obvious lines.

Claude calls vtriv_create_document and it’s stored. Next session, in any client, it’s already there. You stop opening chats by re-introducing yourself.

Then knowledge — the durable material your work leans on. vtriv_write takes a path in a markdown tree, so a design decision goes to something like topic/auth-design.md and stays findable. Leave the path off entirely and it lands in inbox/, searchable immediately, filed later or never. Capture is supposed to be free; filing is the part you can defer.

Skills are the third piece: packaged how-tos Claude loads when a task calls for them. The way you like a release cut, your house style for an API, the checklist for a migration. Write it once, and every assistant that connects can pull it.

Watch it come back

The payoff shows up on the next session, and it’s worth doing deliberately once so you can see it happen.

Open a fresh conversation and ask Claude to call vtriv_context. That one call returns who you are, what skills exist, and what you’re working on right now. It’s the orientation read — the thing that replaces your paste.

Then ask about something specific. vtriv_search runs hybrid semantic and keyword search across knowledge, projects, tasks, notes, and skills in one pass. If you want everything relevant to a topic assembled rather than a list of hits, vtriv_pack fetches and bundles it inside a token budget, each section labeled with the source it came from. That’s usually the better call when you’re starting real work: one tool call, working context, no fetch loop.

The test is simple. Ask the new session a question that only last week’s session could answer. If it answers, the memory is real.

Memory that also carries work

Here’s the part that surprised us in daily use: once your assistant can read the layer, the natural next step is handing it work through the same layer.

Projects in vtriv carry tasks. A task assigned to claude is a work queue an agent can pull with vtriv_tasks. Comments on a task are an async conversation with whoever — or whatever — picks it up. We run an agent fleet against this every day; the tasks that produced this blog post were filed in vtriv, picked up from vtriv, and reported back to vtriv.

That’s the difference between memory and a context layer. Memory is what your AI knows. A layer is what it knows plus what you’ve asked it to do.

A few things that make it stick

Keep it lean. A layer full of chat transcripts and every half-formed thought searches badly, and the assistant grabs the wrong document. Save what you’d groan at re-explaining; skip what you’d never look up again.

Write it as prose, not bullets-of-keywords. It’s read by a language model, and models read prose better than they read outlines.

Let the assistant maintain it. The point of write access is that you’re not the only one keeping it current. Ask it to note a decision at the end of a session and the note is there when you need it, in a place you can open and edit yourself.

Don’t wait until it’s complete. A profile and three knowledge docs already beat starting from zero, which is the cost of starting over you’re paying now.

The free tier holds 50 documents, 25 skills, and unlimited projects and tasks — enough to find out whether this changes how you work. Get started.