Updated July 2026 — this post has been rewritten to reflect Continue.dev's acquisition by Cursor, current setup steps, and what persistent memory does and doesn't change about that transition.

Continue.dev built its reputation on a simple idea: you shouldn't be locked into one model provider to get a good coding assistant. Point it at Claude, GPT, Gemini, or a local model running on Ollama, and the editor experience — Cmd+L chat, inline edit, Agent mode, context providers like @File and @Codebase — stays the same underneath. That architecture is also why Continue.dev is one of the more interesting cases for persistent memory: the project knowledge needs to survive not just session resets, but provider switches.

On June 18, 2026, Cursor announced it had acquired Continue. The standalone product wound down fast — a final v2.0.0 release shipped June 19, the continuedev/continue repository on GitHub went read-only, and Continue's hosted cloud data is scheduled for deletion after July 15, 2026. The extension itself keeps working today under its Apache 2.0 license — existing installs, forks, and pinned builds aren't going anywhere — but there's no active roadmap left, which makes the model-agnostic design more relevant, not less: whether or not Continue.dev ships another release, the question is the same — does your project's accumulated context live inside one tool, or does it survive regardless of what happens to that tool?

Short version: it's a four-line addition to a config file you already have.

# ~/.continue/config.yaml
mcpServers:
  - {name: MemNexus, command: mx, args: [mcp, serve]}

Skip to setup if you just want to wire it up — or keep reading for why this matters more after the acquisition than before.

What resets every session, with or without the acquisition news

Continue.dev's context loss isn't new and isn't specific to the acquisition — it's the same limitation every session-based coding assistant has. Here's what disappears when a chat session ends:

Project decisions with their reasoning. Not just that the customer-data service routes through a local Ollama model, but the compliance rule behind it — PII can't leave the network, even as a prompt to a cloud API — and which services that rule does and doesn't cover.
Debugging history. The afternoon you spent figuring out why .continue/rules/security.md wasn't loading for the customer-data service — the glob pattern only matched .ts files, and the service was .js.
Coding conventions that never made it into a linter config. How your team structures error handling, the validation pattern you settled on, the test layout that isn't documented anywhere.
Everything you re-explained last session. Gone. You'll explain it again tomorrow, possibly to a different model provider than the one you used today.

This is a property of how large language models work — they process a context window and produce output, with nothing written to persistent storage between calls — not something Continue.dev, or any coding agent, can configure away. For a broader look at the mechanics, see The Complete Guide to AI Memory for Developers.

What `.continue/rules/` can do — and where the project's own request for more ended up

Continue.dev's project-level rules system — .continue/rules/*.md files, always-on or triggered by glob pattern or agent request — is the right home for static conventions: preferred frameworks, structural expectations, style rules. If you haven't set these up, they're worth the ten minutes; they cut real re-explanation for anything that doesn't change.

What rules can't do is hold reasoning, timeline, or history. They're maintained by hand, they don't grow on their own, and they have no way to represent "the three things we tried before landing on the current approach" — or the fact that a rule silently stopped applying to a service six weeks ago because its glob pattern never matched that service's file extension.

The Continue.dev community asked for more, and got a clear answer. Issue #4615 — opened in March 2025, labeled kind:enhancement, area:context-providers, and needs-triage — requested a built-in Memory Bank: a structured system for carrying project context, decisions, and progress across sessions. Continue closed it as "not planned" in March 2026, months before the Cursor acquisition and unrelated to it. The team was solving model flexibility, not persistence — a legitimate scope call, not an oversight. With the repository now archived and read-only, that decision won't get revisited from the Continue side. If you want the memory layer this issue asked for, it comes from outside the tool: MCP is the extension point Continue.dev already ships, and it's the one still standing after the acquisition.

Setting up MemNexus with Continue.dev

Model Context Protocol (MCP) is a standard for connecting AI tools to external capabilities. Continue.dev supports it natively, with stdio, SSE, and streamable HTTP transports. MemNexus implements MCP, so once it's connected, Continue.dev can search your memory store in Plan or Agent mode, and save new decisions and findings while working in Agent mode.

npm install -g @memnexus-ai/cli

2. Authenticate

mx auth login

This prompts for your API key interactively so it never lands in shell history, and stores it locally for the CLI and MCP bridge to use.

3. Add MemNexus as an MCP server — by hand

Here's the honest part: mx setup doesn't detect Continue.dev today. It configures seven agents automatically — Claude Code, Claude Desktop, GitHub Copilot, Cursor, Codex CLI, OpenCode, and ChatGPT Desktop — and Continue.dev isn't yet one of them. For Continue.dev, you add the MCP block yourself.

A Continue.dev config.yaml requires three top-level fields — name, version, and schema — plus whatever you've already set up for model providers. If you're already using Continue.dev, you have this file; add the mcpServers block to it:

mcpServers:
  - name: MemNexus
    command: mx
    args:
      - mcp
      - serve

Starting from a blank file instead? Here's a complete, minimal, valid config.yaml:

name: local-config
version: 0.0.1
schema: v1
mcpServers:
  - name: MemNexus
    command: mx
    args:
      - mcp
      - serve

This goes in ~/.continue/config.yaml. Continue.dev's project-level scoping works through a separate mechanism (.continuerc.json) that has had documented compatibility gaps with YAML configs — for MCP servers specifically, stick with the global file until you've confirmed project scoping behaves as expected in your version.

If mx isn't on your system PATH — a fresh container, for example — point Continue.dev at npx instead:

mcpServers:
  - name: MemNexus
    command: npx
    args:
      - "-y"
      - "@memnexus-ai/cli"
      - "mcp"
      - "serve"

mx mcp serve reads the API key you just stored with mx auth login — no key goes into config.yaml itself. Save the file and restart Continue.dev (or reload the window) to pick up the new server. If you want to cross-check any of this against the source, Continue's own config reference documents the full schema.

Optionally, add a rule so Continue.dev knows to use it without being asked. Create .continue/rules/memnexus.md:

Search MemNexus for relevant project context at the start of every
session. Save meaningful decisions, root causes, and conventions
before the session ends.

4. Know which mode you're in

Tool access is split by mode, and it's worth knowing the exact split before you go looking for a memory tool that isn't there. Chat mode loads no tools at all. Plan mode loads read-only tools — including MCP tools — so memory search works in Plan mode. Saving a new memory is a write action — Agent mode is the safe place to do it. If you live in Plan mode for most of your work, you can still search freely; switch to Agent when you want something saved.

5. Create your first memory

In Agent mode, tell it something worth remembering:

"Save a memory: the customer-data service routes through a local Ollama model instead of Claude or GPT, because compliance ruled that PII can't leave the network — even inside a prompt to a cloud API. This applies to any service handling customer PII, not just this one."

MemNexus stores it with semantic indexing — topics, entities, and facts are extracted automatically.

6. Search for it in a new session

Close the conversation. Open a new one — with a different model provider if you want to prove the point, in Plan mode if you just want to confirm search works there too. Ask:

"Search my memories for why the customer-data service uses a local model."

Continue.dev queries your MemNexus store over MCP and surfaces the original reasoning, even though this session has never seen it before.

7. Browse it in the portal

Your memories are also browsable in the MemNexus customer portal — search, filter by topic, and see the knowledge graph connecting your project's decisions and entities as it grows.

What actually persists across a provider switch

You explain the local-model routing rule to Claude in Continue.dev on Monday morning, while scoping a new service. On Monday afternoon, you switch Continue.dev's provider to the local Ollama model to actually build that service — the one the rule requires. Ask that local model why it's the one running this code, and it has the answer — not because the local model remembers anything (it never saw Monday morning's conversation), but because MemNexus stored the memory once and any model connected over MCP can query it.

That's the difference between memory tied to a session and memory tied to a project:

Decisions with reasoning, not just conclusions — the compliance rule behind the local-model routing, not just the fact that it's routed.

Debugging history — the afternoon spent tracing why .continue/rules/security.md wasn't loading becomes a memory. When a new service hits the same silent-rule-mismatch symptom, in a different session, on a different model, it surfaces.

Conventions that outlive any one config file — which services require local-only models, which rules apply where, the things that bit you once.

Three weeks into a project, you've explained the local-model routing rule to Claude, traced a second rules-glob mismatch with GPT-4, and had the local model itself review a PII-handling change for a client engagement that required air-gapped work. Normally that's three re-explanations of the same project to three different models. With one memory store behind all three, it's one.

What this doesn't fix

Worth being direct about the edges here:

Setup is manual, for now. Continue.dev isn't one of the seven mx setup targets, so you're editing config.yaml by hand instead of running one command.

Saving is safest in Agent mode. Search works in Plan mode too — Continue's read-only tool set includes MCP tools, so a memory search call works there. Saving a new memory is a write action — Agent mode is the safe place to do it. If you plan first and only occasionally drop into Agent, remember to switch before asking it to save anything.

MemNexus doesn't know what you never told it. It grounds answers in what you've saved and what it's indexed — it doesn't retroactively pick up code it hasn't read or decisions you never mentioned. Garbage in, same as any memory system.

It doesn't change Continue.dev's own roadmap. Persistent memory keeps your project context intact regardless of which tool or model you're using today. It doesn't reverse the acquisition or restore active development to the standalone product — that's a separate question from whether your memory survives it.

None of that changes what's in your control: the MCP wiring above works today, on whatever version of Continue.dev you're running, and it'll keep working after July 15.

Using a different AI coding tool?

The same MCP-based approach works across the coding agent ecosystem:

If you want your project memory to outlast any single tool's roadmap, sign up free — wiring this up is a few minutes of manual config, not a demo.

For a detailed look at how MemNexus compares to built-in memory features, see our comparison pages.

Continue.dev Memory: How to Make Continue Remember Your Project Across Any Model