Cursor Origin Memory

Ideas Feature Requests
,
1

Feature request for product/service

– Other –

Describe the request

The biggest problem with code agents is that they don’t recognize the code repository; they forget why they wrote the code they just wrote.

The model should be able to recall previous code blocks and understand what was done and why, using the memory graph and change history. This is where Origin comes into play to map out our code.

5

Hey, thanks for the feature request. The idea of an agent that remembers the context of past changes and understands the why behind the code that’s already there makes sense and fits well.

A couple things that already partly cover this, and that might help you right now:

  • Memories: the agent can save facts and decisions across sessions, so you don’t have to re-explain context every time.
  • Search across past chats: the agent can search previous conversations to pull up context from earlier work.
  • Rules .cursor/rules: for persistent project guidance, so the agent can consistently keep architectural decisions and agreements in context: Rules | Cursor Docs
  • Plus codebase indexing and semantic search help the agent understand the repo while it works.

We don’t have an automatic memory graph on top of change history with Origin integration yet. I’ll leave this as a feature request so it can gather votes from the community. Agent memory is being actively discussed, here are a couple related threads if you want to add your vote or more context:

Let me know if any of the above doesn’t cover your use case. I’d like to understand exactly where it falls short.

6

Thank you for your feedback. If I develop this feature by integrating it with the Cursor SDK, would you help me add it as a Cursor plugin and list it on the marketplace?

7

Cool that you want to build this. Yep, Cursor supports building your own plugins. They bundle rules, skills, agents, commands, MCP servers, and hooks into one bundle that you can install from the Customize page. The structure and manifest are described here: Plugins | Cursor Docs

If you’re building on the SDK, here are good starting points:

For distribution, there are two options: the official Cursor Marketplace via the publish form, where your plugin goes through review before it’s listed, and the community catalog cursor.directory, where you can share plugins and MCP servers for other developers.

Build an MVP using the docs above, and if anything’s unclear during publishing, reply in the thread and I’ll help with the specific steps.