Vibsync Shares Memory Across Cursor, Claude, Codex

This research library uses AI-assisted source research and drafting. Linked sources support product claims; analysis and proposed exercises are our interpretation. Unless an article documents a test and its results, do not read it as a hands-on review or an independently verified benchmark.

Vibsync is a Show HN project from Vibsync that gives Claude Code Cursor and Codex one shared memory through MCP. Each coding agent can learn something useful, then strand that knowledge inside its own chat or terminal session. Shared memory can make agent handoffs less lossy, but Cursor rules should still hold repo constraints and permission boundaries. Vibsync is a shared-memory MCP integration for AI coding tools; MCP is an integration protocol that lets AI tools connect to external context and actions through servers.

For Cursor users, this matters because the memory layer and the repo instruction layer are easy to confuse. Cursor rules tell Cursor how to behave in a codebase; Vibsync is trying to carry context between tools that do not normally remember each other’s work.

See what Vibsync is actually connecting

The public pitch is intentionally narrow: one shared memory for Claude Code, Cursor, and Codex over MCP. That is more interesting than another notes panel because these tools often sit at different points in the same work loop.

A real version looks like this. You ask Cursor Agent to trace why invoice previews ignore a tax exemption flag. Later, you switch to Claude Code in the terminal to inspect migrations, or to Codex for a focused patch. Without shared memory, you repeat the same repo map, failed hypothesis, and naming convention every time.

Vibsync sits in the gap. If the memory is available to each agent through MCP, the next tool can pick up the useful bits: “tax exemption lives on account_settings, not invoice_metadata,” or “do not touch the legacy PDF renderer unless the feature flag is on.”

Don't treat shared memory as proof. Memory is a lead, not a receipt. The agent still needs to open files, inspect tests, and cite what changed before you trust the patch.

Notice the workflow change: handoffs get smaller

The day-to-day change is not that agents become magical. It is that handoffs can become shorter and less theatrical.

In a repo with apps/web, packages/billing, and packages/db, one agent might learn that all billing writes must pass through packages/billing/src/ledger.ts. If that fact lands in shared memory, a later Cursor subagent can start closer to the right file instead of wandering through controllers again.

That pairs nicely with Cursor skills and custom agents, especially when the skill is about a repeatable workflow: “investigate flaky Playwright test,” “add a billing migration,” or “review auth boundary.” For more on that Cursor surface area, Cursor subagents and skills.

The same pressure shows up in other integrations too. Cursor adding workspace-aware plugins, covered in Cursor Adds Google Workspace Plugins, points at the same practical theme: agents get more useful when they can retrieve the right context without making the prompt huge.

Watch for stale memory. A note from last Tuesday can be worse than no note if the migration landed yesterday. Good shared memory should be easy to challenge, not silently obeyed.

Keep Cursor rules separate from shared memory

Cursor rules are durable instructions that shape how Cursor works inside a project, commonly kept as scoped .mdc files under .cursor/rules. The plain answer for this story is: use rules for stable repo behavior, and use shared memory for cross-tool working context.

That split keeps the system sane. A Cursor rules file should say things like “run the billing test suite before changing ledger code” or “never bypass the permission helper.” Vibsync-style memory should say things like “the last investigation found the bug in the preview path, not the posting path.”

Many older Cursor rules examples use a single .cursorrules file. In current Cursor workflows, prefer scoped rule files when you want local behavior, because a nested rule can follow the part of the repo it describes.

Here is a small rule stub that gives Cursor a boundary without pretending the shared memory is always right:

---
description: Billing agent boundary for shared MCP memory
globs:
  - "packages/billing/**"
  - "apps/web/app/invoices/**"
---

When using MCP memory, treat remembered facts as hypotheses.
Before editing billing code:
- Open the current source files and tests.
- Verify any remembered architecture note against the repo.
- Do not change ledger posting rules without adding or updating tests.
- Ask for review before altering database migrations or payment provider calls.

Watch for stuffing everything into rules. If the rule file becomes a diary of every investigation, Cursor will carry old noise into new work. Keep rules boring, short, and stable.

Try Vibsync behind a narrow permission boundary

The safe first shape is read-mostly memory. Let agents search shared memory freely, but make writes explicit and keep dangerous actions outside the memory server’s reach unless there is a clear reason.

A small integration decision table is enough:

Permission-boundary note: the memory server should help an agent remember what it learned, not give it new authority to mutate code, run deployments, or inspect sensitive systems.

A good one-hour experiment is tiny. Pick one bug investigation, let Cursor write a short memory only after you approve the wording, then open another agent and see whether that memory shortens the next prompt. If it does not, the memory was too vague.

Further reading

• Vibsync
• Cursor rules
• MCP specification
• Cursor Agent docs

Where to go next

Start from Subagents and skills.