Vibsync Shares Memory Across Cursor, Claude, Codex

Vibsync is a Show HN project from Vibsync that gives Claude Code, Anthropic’s coding agent, Cursor, Anysphere’s AI code editor, and Codex, OpenAI’s coding agent, one shared memory through MCP. It deals with a plain annoyance: each coding agent can learn something useful, then strand that knowledge inside its own chat or terminal session. The useful takeaway is simple: 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.”

The trap is treating 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, see the related training topic on 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.

The trap is 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 cursor rules .cursor/rules documentation 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 mention a cursor rules file .cursorrules. 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.

The trap is 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.

Try one narrow handoff

Pick one real investigation and let shared memory carry only the confirmed facts to the next agent. Keep the repo boundary in Cursor rules, and make the patch earn trust in the diff.

One methodology lens

One useful way to read this through our methodology is the Plan step: delegate first-pass decomposition and dependency mapping, review the sequencing and assumptions, and keep ownership of scope and priorities. If that split is still fuzzy, the workflow usually is too.

Practical starter checklist

- [ ] Name the Cursor artifact first: a .mdc rule stub, an AGENTS.md boundary, a custom subagent note, or a Cursor review checklist.
- [ ] Write the review checklist before generation starts: scope, owner, tests, rollback.
- [ ] Keep the first step small enough that a reviewer can inspect the receipt without replaying the whole chat.

Common questions

• What should teams know about cursor rules?

  Start by writing down one visible team rule for Cursor, not a loose preference. That is the practical core of cursor rules. That usually means a short repository convention, a review checklist, and one owner who can reject agent output when the evidence is missing.

• Which Cursor artifact should teams standardize first?

  Standardize the smallest artifact that reviewers already touch: a .mdc rule, AGENTS.md note, or review checklist. The point is not documentation volume; it is a shared place where scope, allowed tools, expected tests, and rollback notes are visible before generated code reaches review.

• How do teams know the convention is working?

  The convention is working when reviewers can approve or reject agent output from the artifact and evidence alone. Track whether pull requests name the rule used, include the promised checks, and avoid replaying long sessions just to understand what changed.

Best ways to use this research

• Best for: Cursor teams deciding which rule, subagent, skill, or MCP boundary to standardize next around “Vibsync Shares Memory Across Cursor, Claude, Codex.”
• Best first artifact: turn the named fix into a .mdc rule, AGENTS.md note, subagent receipt, or review checklist before the next automated run.
• Best comparison angle: compare the workflow against the current Cursor review path, connector scope, and team rule file; keep the path that leaves the shortest auditable trail.

Further reading

• Vibsync — source
• Cursor — Rules
• Model Context Protocol — specification
• Cursor docs: agent overview

Where to go next

Take this into the related training topic and test whether a new reviewer can defend the merge without replaying the chat.